Sicherheits-Standards deterministisch prüfen: Policy as Code, CVE-Scanning, SBOM

TL;DR

• Deterministische Sicherheitsprüfungen im Cloud-Native-Umfeld basieren auf drei Säulen: Policy as Code, automatisiertes CVE-Scanning und SBOM-Management. Zusammen ermöglichen sie messbare, reproduzierbare Security statt ad-hoc-Checks.
• Policy as Code (z. B. mit Kyverno) etabliert Guardrails auf Kubernetes-Ebene: Nur Deployments, die klar definierte Sicherheits- und Compliance-Regeln einhalten, werden akzeptiert.
• CVE-Scanning mit Tools wie Trivy und container-native Registries wie Harbor sorgt dafür, dass bekannte Schwachstellen frühzeitig erkannt und automatisiert in Build- und Deployment-Pipelines berücksichtigt werden.
• SBOMs sind die Grundlage für Transparenz in der Software Supply Chain – und mit dem Cyber Resilience Act ab etwa 2027 in vielen Fällen Pflicht. Gemeinsam mit NIS‑2 und DORA entsteht ein verbindlicher Rahmen für Security-Automatisierung.
• ayedo verbindet diese drei Säulen in einer integrierten, automatisierten Software Delivery Plattform und hilft Organisationen, deterministische Sicherheitsprüfungen konkret umzusetzen – technisch, organisatorisch und im Kontext von Compliance-Anforderungen.

Warum deterministische Sicherheitsprüfung jetzt entscheidend ist

Cloud-native Architekturen bringen enorme Flexibilität – und eine drastisch gestiegene Komplexität. Container, Microservices, Infrastructure as Code und dynamische Orchestrierung mit Kubernetes machen klassische, manuelle Sicherheitsprüfungen faktisch unmöglich.

Gleichzeitig verschärfen europäische Regulierungen den Fokus auf messbare Sicherheit:

• Die NIS‑2‑Richtlinie (NIS‑2) ist am 16.01.2023 in Kraft getreten und verlangt unter anderem deutlich stärkere Kontrolle der Software Supply Chain.
• Die DORA-Verordnung (DORA) ist ebenfalls am 16.01.2023 in Kraft getreten und gilt ab dem 17.01.2025 verbindlich im Finanzsektor – mit klarem Fokus auf IKT-Risikomanagement, Business Continuity und Resilienz.
• Der Cyber Resilience Act wurde 2024 verabschiedet; die meisten Pflichten werden nach einer Übergangsfrist von 36 Monaten wirksam, also voraussichtlich ab 2027. SBOMs und koordinierte Vulnerability-Disclosure-Prozesse (CVD) gehören dann zum Pflichtprogramm.

Deterministisch bedeutet in diesem Kontext: Ein Deployment ist entweder konform – oder es findet nicht statt. Entscheidungen werden nicht „auf Zuruf“ getroffen, sondern automatisiert anhand klar definierter Regeln, Daten und Schwellenwerte.

Automatisierung ist dabei kein Selbstzweck, sondern der einzige realistische Weg, in komplexen Plattformen zu konsistenten, nachweisbaren Sicherheitsstandards zu kommen.

Die drei Säulen deterministischer Sicherheitsprüfung

Drei Bausteine ergänzen sich zu einem geschlossenen Sicherheits- und Compliance-Modell für Cloud-Native-Plattformen:

1. Policy as Code: Regeln und Guardrails, die auf Plattformebene (z. B. Kubernetes Admission Control) automatisiert durchgesetzt werden.
2. CVE-Scanning: Kontinuierliche Analyse von Container-Images und Artefakten auf bekannte Schwachstellen.
3. SBOM: Vollständige, maschinenlesbare Inventare aller verwendeten Komponenten, Abhängigkeiten und Versionen.

Jede dieser Säulen löst ein anderes Problem:

• Policy as Code verhindert unsichere Konfigurationen und Prozesse.
• CVE-Scanning stellt sicher, dass bekannte Schwachstellen entdeckt und bewertet werden.
• SBOMs liefern die Datengrundlage, um auf neue Bedrohungen und regulatorische Anforderungen zu reagieren.

Gemeinsam ermöglichen sie es, Security-Regeln in die Software Delivery Pipeline zu integrieren – nicht am Ende, sondern von Anfang an.

Policy as Code mit Kyverno: Guardrails für sichere Deployments

In Kubernetes-Umgebungen entscheidet das Admission Control darüber, ob ein neues Objekt (z. B. ein Deployment) akzeptiert wird. Policy as Code nutzt diesen Mechanismus, um Sicherheits- und Compliance-Anforderungen als maschinenlesbare Regeln zu definieren.

Kyverno ist ein Policy-Engine, die speziell für Kubernetes entwickelt wurde. Statt kryptischer, generischer Regelsprachen arbeitet Kyverno direkt auf Kubernetes-Ressourcen. Das erleichtert die Governance in Teams, die bereits mit Kubernetes-Objekten vertraut sind.

Typische Guardrails, die sich mit Kyverno deterministisch durchsetzen lassen:

• Verbot privilegierter Container: Nur Prozesse ohne Root-Rechte sind erlaubt; so wird der potenzielle Schaden aus Container- oder OS-Schwachstellen begrenzt.
• Keine latest-Tags: Nur eindeutig versionierte Images dürfen deployed werden. Das ist Grundvoraussetzung für reproduzierbare Deployments, Rollbacks und nachvollziehbare Release-Prozesse.
• Verpflichtende Resource Requests: CPU- und Memory-Anforderungen müssen für alle Container definiert sein, um Kapazitätsplanung und QoS sicherzustellen.
• Erforderliche Network Policies: Jeder Namespace muss wenigstens eine NetworkPolicy haben, um unkontrollierte laterale Bewegung im Cluster zu verhindern.

Wichtig ist der Betriebsmodus:

• Im Enforce-Modus blockiert Kyverno Deployments, die gegen eine Policy verstoßen.
• Im Audit-Modus werden Verstöße nur protokolliert.

Für deterministische Prüfungen brauchen Sie primär Enforce-Policies – mit klarer Governance, wann eine Policy „blocking“ sein darf und wie Ausnahmen (z. B. temporäre Waiver) dokumentiert werden.

Auf diese Weise können Sie zentrale Anforderungen aus NIS‑2, DORA und allgemeinen Compliance-Rahmen (z. B. ISO 27001) technisch verankern: Das Regelwerk wird nicht mehr in PDFs verwaltet, sondern läuft als Teil Ihrer Plattform.

CVE-Scanning mit Trivy und Harbor: kontinuierliche Schwachstellenkontrolle

Policy as Code beantwortet die Frage: „Darf diese Konfiguration deployed werden?“

CVE-Scanning ergänzt diese Sicht um: „Ist dieses Artefakt – Image, Package, Container – frei von bekannten Schwachstellen in akzeptabler Risikoklasse?“

Tools wie Trivy analysieren Container-Images, Betriebssystem-Pakete und Sprachen-spezifische Dependencies (z. B. npm, Maven, Go Modules) gegen Datenbanken öffentlich bekannter Schwachstellen (CVE, NVD, Distribution Advisories).

Ein typisches Setup besteht aus zwei Ebenen:

1. CI-Pipeline-Scanning

   • Jedes neu gebaute Image wird direkt nach dem Build gescannt.
   • Ergebnisse fließen in den Build-Status ein: Build „grün“ nur, wenn keine kritischen Schwachstellen oberhalb eines definierten Schwellwerts vorhanden sind – oder wenn es dokumentierte Ausnahmen gibt.

2. Registry-Scanning

   • Container-Registries wie Harbor bieten integrierte Vulnerability-Scanner (u. a. Trivy).
   • Scans werden regelmäßig wiederholt, auch für bereits bestehende Images. Wichtig, weil neue CVEs ständig dazukommen.
   • Ergebnisse werden als Metadaten am Image gespeichert und können von anderen Systemen (z. B. Kyverno) ausgewertet werden.

Auf diese Weise entsteht ein kontinuierlicher Sicherheits-Check entlang des Lebenszyklus eines Images. Fortschrittliche Setups nutzen CVE-Daten nicht nur zur Information, sondern als harte Schranken:

• Images mit kritischen CVEs werden im CI gar nicht erst als „releasefähig“ markiert.
• Die Registry markiert Images mit bestimmten Befunden als „nicht deploybar“.
• Policies in Kubernetes werten diese Metadaten aus und unterbinden Deployments kompromittierter Images.

Das ist ein zentraler Baustein, um Anforderungen an Supply Chain Security aus NIS‑2 und dem Cyber Resilience Act messbar zu erfüllen.

SBOM: Transparenz und CRA-Pflicht ab 2027

Eine Software Bill of Materials (SBOM) ist ein vollständiges, strukturierter Inventar aller Komponenten, Bibliotheken und Abhängigkeiten, die in einem Produkt oder Service stecken – inklusive Versionen und Herkunft.

Standards wie SPDX oder CycloneDX erlauben es, SBOMs maschinenlesbar zu erstellen und zu verarbeiten.

Warum ist das so wichtig?

• Transparenz: Ohne SBOM wissen Sie schlicht nicht, welche Komponenten in welcher Version in Ihren Images stecken.
• Reaktion auf neue CVEs: Wenn eine neue kritische Schwachstelle veröffentlicht wird, können Sie mit SBOMs automatisiert alle betroffenen Produkte und Services identifizieren – statt händisch zu recherchieren.
• Regulatorische Anforderungen: Der Cyber Resilience Act macht SBOMs schrittweise zur Pflicht, insbesondere bei kritischen Produkten und digitalen Elementen.

Mit einer durchgängigen SBOM-Strategie lassen sich zudem weitere Anforderungen adressieren:

• NIS‑2 fordert eine gestärkte Kontrolle der Lieferkette – SBOMs sind hier ein zentraler Baustein.
• DORA fokussiert auf IKT-Risiken und Resilienz in Finanzinstitutionen; SBOMs ermöglichen belastbare Risikoanalysen auf Komponentenebene.

Praktisch bedeutet das:

• SBOM-Erstellung wird Teil der Build-Pipeline – für jedes Image, automatisiert.
• SBOMs werden zentral gespeichert, versioniert und mit Artefakten (Images, Releases) verknüpft.
• SBOM-Daten werden mit Vulnerability-Informationen und Compliance-Anforderungen verknüpft, um gezielt Maßnahmen abzuleiten.

Nur in Verbindung mit Automatisierung wird SBOM von einem „Dokumentationsaufwand“ zu einem strategischen Werkzeug für Security und Compliance.

Zusammenspiel: Von Daten und Regeln zu deterministischer Security

Die wahre Stärke entfaltet sich im Zusammenspiel der drei Säulen:

1. Build-Zeit (CI)

   • Der Code wird gebaut, SBOMs werden generiert.
   • Trivy (o. Ä.) scannt das Image auf bekannte Schwachstellen.
   • Ergebnisse fließen in Build- und Release-Metriken ein: Nur Images ohne kritische Findings (oder mit dokumentierten Ausnahmen) werden als „releasefähig“ markiert.

2. Registry-Ebene

   • Images werden in einer Registry wie Harbor gespeichert.
   • Dort laufen wiederkehrende Scans; Ergebnisse werden versioniert.
   • SBOMs werden mit den jeweiligen Images verknüpft und sind jederzeit abrufbar.

3. Deployment-Zeit (CD / Kubernetes)

   • Kyverno-Policies prüfen bei jedem Deployment:
     • Entspricht die Konfiguration den Sicherheits-Gardrails?
     • Trägt das referenzierte Image Metadaten, die auf kritische CVEs hinweisen?
   • Falls nicht, wird das Deployment deterministisch abgelehnt – mit einer klaren, nachvollziehbaren Begründung.

4. Betriebsphase (Runtime)

   • Laufende Workloads werden weiterhin mit CVE-Daten und SBOMs abgeglichen.
   • Neue Schwachstellen können gezielt auf betroffene Deployments gemappt werden, inklusive Priorisierung und Patch-Management.

So entsteht ein durchgängiges Sicherheitsnetz, das sich automatisiert über Ihre Plattform legt – und zugleich eine belastbare Datenbasis für Audits im Rahmen von Compliance, NIS‑2, DORA und Cyber Resilience Act bereitstellt.

Praktisches Beispiel: Kyverno blockt ein Deployment mit kritischer CVE

Ein konkreter, praxisnaher Ablauf könnte so aussehen:

1. Neues Image wird gebaut
   Ihr Team baut eine neue Version eines Service-Images. In der CI-Pipeline wird automatisch ein SBOM erzeugt und das Image mit Trivy gescannt.

2. CVE wird entdeckt
   Der Scanner findet eine kritische Schwachstelle (z. B. eine Remote Code Execution im verwendeten Framework). Das Ergebnis wird sowohl im CI-System dokumentiert als auch als Metadaten am Image in Harbor gespeichert.

3. Trotzdem Release-Kandidat
   Ausnahmsweise wird das Image – etwa aus Zeitdruck oder wegen fehlender Alternative – zunächst als Release-Kandidat markiert. Der Build ist „gelb“, nicht „grün“: Die Risiken sind sichtbar, aber es wurde eine dokumentierte Ausnahme genehmigt.

4. Deployment-Versuch
   Ein Team versucht, dieses Image in ein Produktions- oder sicherheitskritisches Staging-Cluster zu deployen. Kubernetes ruft die Admission Webhooks auf, Kyverno erhält die Anfrage.

5. Kyverno prüft Policies und CVE-Metadaten
   Eine Kyverno-Policy besagt:

   • In Produktions-Namespaces dürfen keine Images mit ungepatchten kritischen CVEs laufen.
   • Ausnahmen sind nur erlaubt, wenn ein definierter „Waiver“-Mechanismus genutzt wurde (z. B. ein zusätzliches Label, das auf ein Risiko-Ticket verweist).

   Kyverno liest die Image-Metadaten aus der Registry und erkennt:

   • Kritische CVE vorhanden.
   • Kein gültiger, genehmigter Waiver für diesen Namespace.

6. Deterministische Entscheidung: Deployment abgelehnt
   Das Deployment wird abgelehnt, inklusive klarer Fehlermeldung, die sowohl die technische Ursache (CVE) als auch den Policy-Verstoß benennt.

7. Folgeeffekte

   • Das verantwortliche Team weiß sofort, was zu tun ist: Fix, Neu-Build, Re-Scan.
   • In Audits können Sie nachweisen, dass in produktiven Umgebungen keine Images mit bekannten, ungepatchten kritischen Schwachstellen ohne dokumentierte Ausnahme laufen.

Dieses Beispiel zeigt, wie Automatisierung deterministische Sicherheit erzeugt: Es gibt kein „Übersehen“, keine impliziten Ausnahmen – nur explizite, auditierbare Entscheidungen.

Häufige Fragen

Brauchen wir wirklich alle drei Säulen – Policy as Code, CVE-Scanning und SBOM?

Kurz gesagt: Für eine moderne, regulatorisch belastbare Plattform ist die Kombination der drei Ansätze der pragmatischste Weg.

• Nur Policy as Code ohne CVE-Scanning weiß nichts über Schwachstellen in Images.
• Nur CVE-Scanning ohne Policies produziert Berichte, aber keine automatisierten Entscheidungen.
• Nur SBOM ist reine Dokumentation ohne Verbindung zur Pipeline.

In Kombination erhalten Sie:

• Klare Regeln (Policies),
• belastbare Daten (CVE-Scans, SBOMs),
• und automatisierte Entscheidungen (Enforce).

Gerade vor dem Hintergrund von NIS‑2, DORA und Cyber Resilience Act ist diese Kombination der effizienteste Weg, um von „Sicherheit auf Vertrauen“ zu „Sicherheit als systematische Eigenschaft“ zu kommen.

Wie gehen wir mit False Positives und Legacy-Systemen um?

Deterministische Sicherheit heißt nicht „gnadenlos“, sondern „klar geregelt“. Zwei Elemente sind wichtig:

1. Risikobasierte Schwellwerte

   • Definieren Sie pro Umgebung (Dev, Test, Prod) und Anwendungstyp (intern, extern, kritisch) unterschiedliche Schwellenwerte.
   • Kritische Findings in einem experimentellen Dev-Cluster sind anders zu bewerten als in einem produktiven Payment-Service.

2. Geregelte Ausnahmemechanismen (Waiver)

   • Wenn ein Legacy-System kurzfristig nicht ohne Risiko-Trade-offs aktualisiert werden kann, sollte es einen formalisierten Prozess geben, um Ausnahmen zu dokumentieren – inklusive Risikoabwägung, Verantwortlichkeit und Laufzeitbegrenzung.
   • Technisch wird das in Policies abgebildet: Ein Deployment mit kritischer CVE ist nur zulässig, wenn eine genehmigte Ausnahme als Label/Annotation o. Ä. erkennbar ist.

So behalten Sie die Kontrolle, ohne die Realität von Altsystemen und Geschäftsanforderungen zu ignorieren – und bleiben dennoch auditierbar.

Wie unterstützt ayedo konkret bei der Umsetzung dieser Ansätze?

ayedo versteht Policy as Code, CVE-Scanning und SBOM nicht als Einzelprojekte, sondern als integrierte Funktionen einer modernen Plattform.

Konkret bieten wir:

• Eine Kubernetes-basierte Plattform, in der Kyverno-Policies als Guardrails vorkonfiguriert sind – inklusive typischer Sicherheitsregeln wie Non-Root-Container, Verbot von latest-Tags und verpflichtenden Network Policies.
• Integrierte Vulnerability-Scans mit Tools wie Trivy, sowohl in der CI-Pipeline als auch auf Registry-Ebene mit Harbor.
• SBOM-Erstellung und -Verwaltung als Teil des Software Delivery Prozesses, inklusive Verknüpfung mit Compliance-Anforderungen aus NIS‑2, DORA und Cyber Resilience Act.

Gemeinsam mit Ihren Teams definieren wir die passenden Policies, Schwellwerte und Ausnahmeprozesse – technisch und organisatorisch – und verankern diese in Ihrer Plattform.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Wer Verantwortung für eine Cloud-Native-Infrastruktur trägt, steht heute vor einer doppelten Aufgabe: Sicherheit technisch solide umzusetzen – und sie gegenüber Prüfern, Aufsichtsbehörden und Kunden belastbar nachweisen zu können.

Policy as Code, CVE-Scanning und SBOM sind dafür zentrale Bausteine. Entscheidend ist jedoch, wie gut sie integriert sind:

• Laufen SBOM-Erstellung, Scans und Policy-Checks automatisiert in Ihren Pipelines?
• Gibt es klare Regeln, wann Deployments blockiert werden – und wie Ausnahmen dokumentiert werden?
• Können Sie für jedes produktive System nachvollziehbar zeigen, welche Komponenten darin laufen und welche Schwachstellen-Bewertung zugrunde liegt?

Die ayedo Software Delivery Plattform adressiert genau diese Fragen:

• Guardrails mit Kyverno: Wir liefern ein kuratiertes Set an Sicherheits-Policies, das Sie an Ihre Anforderungen anpassen können – vom Verhindern privilegierter Container bis zu komplexeren Regeln, die CVE-Metadaten und SBOM-Informationen auswerten.
• Integriertes Vulnerability-Management: CVE-Scanning wird nicht als separater Bericht verstanden, sondern als Entscheidungssignal in Ihren Build- und Deployment-Prozessen – einschließlich Integration mit Harbor und gängigen CI-Systemen.
• SBOM als Plattformfunktion: SBOMs werden automatisiert erzeugt, verwaltet und mit Deployments verknüpft. Damit entsteht die Datenbasis, um Anforderungen aus Compliance, NIS‑2, DORA und Cyber Resilience Act pragmatisch zu erfüllen.

Unser Ziel ist eine Plattform, in der Security-Automatisierung nicht als Zusatzaufwand erlebt wird, sondern als Enabler: Sie schafft Transparenz, reduziert manuelle Arbeit und ermöglicht es Teams, sich auf das Wesentliche zu konzentrieren – stabile, wertschaffende Software.

Wenn Sie diesen Weg strukturiert angehen möchten, ist unser Security Automation Guide ein guter Einstieg. Er zeigt, wie Sie die beschriebenen Bausteine Schritt für Schritt in Ihre Organisation integrieren können – technisch, prozessual und im Einklang mit den europäischen Regulierungsrahmen.

Mehr dazu in unserem Security Automation Guide