Deterministically Checking Security Standards: Policy as Code, CVE Scanning, SBOM

TL;DR

• Deterministic security checks in the cloud-native environment are based on three pillars: Policy as Code, automated CVE scanning, and SBOM management. Together, they enable measurable, reproducible security instead of ad-hoc checks.
• Policy as Code (e.g., with Kyverno) establishes guardrails at the Kubernetes level: Only deployments that comply with clearly defined security and compliance rules are accepted.
• CVE scanning with tools like Trivy and container-native registries like Harbor ensures that known vulnerabilities are detected early and automatically considered in build and deployment pipelines.
• SBOMs are the foundation for transparency in the software supply chain – and with the Cyber Resilience Act from around 2027, they will be mandatory in many cases. Together with NIS-2 and DORA, a binding framework for security automation is emerging.
• ayedo integrates these three pillars into an automated software delivery platform, helping organizations implement deterministic security checks concretely – technically, organizationally, and in the context of compliance requirements.

Why Deterministic Security Checking is Crucial Now

Cloud-native architectures bring enormous flexibility – and drastically increased complexity. Containers, microservices, Infrastructure as Code, and dynamic orchestration with Kubernetes make traditional, manual security checks practically impossible.

At the same time, European regulations are tightening the focus on measurable security:

• The NIS-2 directive (NIS-2) came into force on January 16, 2023, requiring significantly stronger control of the software supply chain.
• The DORA regulation (DORA) also came into force on January 16, 2023, and will be binding in the financial sector from January 17, 2025 – with a clear focus on ICT risk management, business continuity, and resilience.
• The Cyber Resilience Act was adopted in 2024; most obligations will take effect after a transition period of 36 months, likely from 2027. SBOMs and coordinated vulnerability disclosure processes (CVD) will then be mandatory.

Deterministic in this context means: A deployment is either compliant – or it does not occur. Decisions are not made “on the fly” but are automated based on clearly defined rules, data, and thresholds.

Automation is not an end in itself but the only realistic way to achieve consistent, verifiable security standards in complex platforms.

The Three Pillars of Deterministic Security Checking

Three components complement each other to form a comprehensive security and compliance model for cloud-native platforms:

1. Policy as Code: Rules and guardrails that are automatically enforced at the platform level (e.g., Kubernetes Admission Control).
2. CVE Scanning: Continuous analysis of container images and artifacts for known vulnerabilities.
3. SBOM: Complete, machine-readable inventories of all components, dependencies, and versions used.

Each of these pillars solves a different problem:

• Policy as Code prevents insecure configurations and processes.
• CVE scanning ensures that known vulnerabilities are detected and assessed.
• SBOMs provide the data foundation to respond to new threats and regulatory requirements.

Together, they enable security rules to be integrated into the software delivery pipeline – not at the end, but from the beginning.

Policy as Code with Kyverno: Guardrails for Secure Deployments

In Kubernetes environments, admission control decides whether a new object (e.g., a deployment) is accepted. Policy as Code uses this mechanism to define security and compliance requirements as machine-readable rules.

Kyverno is a policy engine specifically developed for Kubernetes. Instead of cryptic, generic rule languages, Kyverno works directly on Kubernetes resources. This simplifies governance in teams already familiar with Kubernetes objects.

Typical guardrails that can be deterministically enforced with Kyverno:

• Prohibition of privileged containers: Only processes without root privileges are allowed, limiting potential damage from container or OS vulnerabilities.
• No latest tags: Only clearly versioned images may be deployed. This is a prerequisite for reproducible deployments, rollbacks, and traceable release processes.
• Mandatory resource requests: CPU and memory requirements must be defined for all containers to ensure capacity planning and QoS.
• Required network policies: Every namespace must have at least one NetworkPolicy to prevent uncontrolled lateral movement in the cluster.

The operating mode is important:

• In enforce mode, Kyverno blocks deployments that violate a policy.
• In audit mode, violations are only logged.

For deterministic checks, you primarily need enforce policies – with clear governance on when a policy can be “blocking” and how exceptions (e.g., temporary waivers) are documented.

This way, you can technically anchor central requirements from NIS-2, DORA, and general compliance frameworks (e.g., ISO 27001): The rule set is no longer managed in PDFs but runs as part of your platform.

CVE Scanning with Trivy and Harbor: Continuous Vulnerability Control

Policy as Code answers the question: “Can this configuration be deployed?”

CVE scanning complements this view with: “Is this artifact – image, package, container – free from known vulnerabilities in an acceptable risk class?”

Tools like Trivy analyze container images, operating system packages, and language-specific dependencies (e.g., npm, Maven, Go Modules) against databases of publicly known vulnerabilities (CVE, NVD, distribution advisories).

A typical setup consists of two levels:

1. CI Pipeline Scanning

   • Every newly built image is scanned immediately after the build.
   • Results are integrated into the build status: The build is “green” only if there are no critical vulnerabilities above a defined threshold – or if there are documented exceptions.

2. Registry Scanning

   • Container registries like Harbor offer integrated vulnerability scanners (including Trivy).
   • Scans are regularly repeated, even for existing images. Important because new CVEs are constantly emerging.
   • Results are stored as metadata on the image and can be evaluated by other systems (e.g., Kyverno).

This creates a continuous security check throughout the lifecycle of an image. Advanced setups use CVE data not just for information but as hard barriers:

• Images with critical CVEs are not marked as “releasable” in the CI.
• The registry marks images with certain findings as “non-deployable.”
• Policies in Kubernetes evaluate this metadata and prevent deployments of compromised images.

This is a central component to measurably meet supply chain security requirements from NIS-2 and the Cyber Resilience Act.

SBOM: Transparency and CRA Obligation from 2027

A Software Bill of Materials (SBOM) is a complete, structured inventory of all components, libraries, and dependencies within a product or service – including versions and origins.

Standards like SPDX or CycloneDX allow SBOMs to be created and processed in a machine-readable format.

Why is this so important?

• Transparency: Without an SBOM, you simply don’t know which components in which version are in your images.
• Response to new CVEs: When a new critical vulnerability is published, SBOMs allow you to automatically identify all affected products and services – instead of manually researching.
• Regulatory Requirements: The Cyber Resilience Act gradually makes SBOMs mandatory, especially for critical products and digital elements.

With a comprehensive SBOM strategy, further requirements can also be addressed:

• NIS-2 demands strengthened supply chain control – SBOMs are a central component here.
• DORA focuses on ICT risks and resilience in financial institutions; SBOMs enable robust risk analyses at the component level.

Practically, this means:

• SBOM creation becomes part of the build pipeline – for every image, automated.
• SBOMs are centrally stored, versioned, and linked with artifacts (images, releases).
• SBOM data is linked with vulnerability information and compliance requirements to derive targeted actions.

Only with automation does SBOM become a strategic tool for security and compliance rather than a “documentation burden.”

Interaction: From Data and Rules to Deterministic Security

The true strength unfolds in the interaction of the three pillars:

1. Build Time (CI)

   • The code is built, SBOMs are generated.
   • Trivy (or similar) scans the image for known vulnerabilities.
   • Results flow into build and release metrics: Only images without critical findings (or with documented exceptions) are marked as “releasable.”

2. Registry Level

   • Images are stored in a registry like Harbor.
   • Recurring scans are conducted; results are versioned.
   • SBOMs are linked with the respective images and are available at any time.

3. Deployment Time (CD / Kubernetes)

   • Kyverno policies check each deployment:
     • Does the configuration meet the security guardrails?
     • Does the referenced image carry metadata indicating critical CVEs?
   • If not, the deployment is deterministically rejected – with a clear, traceable justification.

4. Operational Phase (Runtime)

   • Ongoing workloads continue to be matched with CVE data and SBOMs.
   • New vulnerabilities can be specifically mapped to affected deployments, including prioritization and patch management.

This creates a comprehensive security net that automatically overlays your platform – and at the same time provides a robust data basis for audits within the framework of compliance, NIS-2, DORA, and Cyber Resilience Act.

Practical Example: Kyverno Blocks a Deployment with a Critical CVE

A concrete, practical process might look like this:

1. New Image is Built
   Your team builds a new version of a service image. In the CI pipeline, an SBOM is automatically generated, and the image is scanned with Trivy.

2. CVE is Discovered
   The scanner finds a critical vulnerability (e.g., a remote code execution in the used framework). The result is documented in the CI system and stored as metadata on the image in Harbor.

3. Still a Release Candidate
   Exceptionally, the image – perhaps due to time pressure or lack of alternatives – is initially marked as a release candidate. The build is “yellow,” not “green”: The risks are visible, but a documented exception has been granted.

4. Deployment Attempt
   A team attempts to deploy this image into a production or secure environment.