DevSecOps 2026: Eine ganzheitliche Referenzarchitektur für sichere, messbare und KI-gestützte Softwarelieferketten in Cloud-, Container- und GitOps-Umgebungen

1. Introduction

DevSecOps ist im Jahr 2026 kein Modewort mehr, sondern eine operative Notwendigkeit für Organisationen, die Software unter realen Angriffsbedingungen entwickeln, bereitstellen und betreiben. Die klassische Trennung zwischen Entwicklung, Betrieb und Sicherheit ist in modernen Cloud-, Container- und Plattformarchitekturen nicht nur ineffizient, sondern sicherheitsrelevant problematisch, weil Angreifer systematisch genau jene Übergänge ausnutzen, in denen Verantwortlichkeiten unklar, Telemetrie fragmentiert und Freigabeprozesse manuell sind. Die letzten Jahre haben gezeigt, dass der Angriffsvektor nicht mehr nur in der Anwendungsschicht liegt, sondern in der gesamten Lieferkette: in Paketregistries, Build-Runnern, Secrets in Repositories, Dependency-Hijacking, kompromittierten Signierungsschlüsseln, ungeschützten Artefakt-Pipelines und Identitäten, die zwischen SaaS-Tools, Cloud-Accounts und Kubernetes-Clustern wandern. Vor diesem Hintergrund ist DevSecOps nicht einfach “Security in CI/CD”, sondern eine systematische Umgestaltung der Softwarelieferkette nach dem Prinzip, dass Sicherheitskontrollen deterministisch, automatisiert, auditierbar und messbar sein müssen.

Der Begriff DevSecOps ist historisch aus DevOps hervorgegangen, wurde aber spätestens mit der massenhaften Verbreitung cloud-nativer Plattformen, Infrastructure-as-Code und GitOps zu einer eigenständigen Disziplin. DevOps optimiert den Fluss von Code in Produktion; DevSecOps ergänzt diesen Fluss um die Eigenschaft, dass Vertrauensentscheidungen nicht implizit oder personengebunden getroffen werden, sondern durch Richtlinien, Signaturen, Provenienz und kontinuierliche Verifikation abgesichert sind. In der Praxis bedeutet dies, dass Build-Artefakte verifizierbar, Images signiert, Abhängigkeiten nachvollziehbar, Berechtigungen minimal und Laufzeitumgebungen beobachtbar sein müssen. Wenn $T$ die Zeit bis zur Bereitstellung und $R$ das Restrisiko einer kompromittierten Änderung bezeichnet, dann ist das Ziel von DevSecOps nicht, $T$ um jeden Preis zu minimieren, sondern die Funktion $$ \min ; J = \alpha T + \beta R $$ unter organisatorischen und technischen Nebenbedingungen zu optimieren, wobei $\alpha$ und $\beta$ den relativen Wert von Geschwindigkeit und Sicherheit ausdrücken. Die Herausforderung besteht darin, dass naive Sicherheitskontrollen $T$ erhöhen können, während rein geschwindigkeitsorientierte Pipelines $R$ drastisch steigern.

Bis 2026 haben sich mehrere technologische und regulatorische Trends gegenseitig verstärkt. Erstens sind Softwarelieferketten systematisch angegriffen worden, etwa durch Typosquatting, Abhängigkeitsverwirrung, kompromittierte Maintainer-Accounts und bösartige Build-Änderungen. Zweitens sind KI-gestützte Entwicklungswerkzeuge in den Alltag eingezogen, wodurch neue Risiken entstehen, darunter Prompt Injection in Entwicklungsassistenten, unbeabsichtigte Geheimnisfreigaben, unsichere Codevorschläge und die Ausweitung des Angriffsraums auf RAG- und Agenten-Workflows. Drittens haben Regulierungs- und Standardisierungsinitiativen wie die EU NIS2, DORA, der EU AI Act, die US Executive Order zur Software Supply Chain und SLSA-artige Provenienzmodelle die Erwartungshaltung an nachweisbare Sicherheit erhöht. Viertens sind Cloud-native Sicherheitsarchitekturen in Richtung CNAPP, eBPF-basierte Observability und Policy-as-Code gereift, was DevSecOps vom reinen Scanner-Einsatz in Richtung kontinuierlicher, kontextsensitiver Risikosteuerung verschiebt.

Diese Arbeit verfolgt drei Ziele. Erstens wird DevSecOps historisch und technisch in den Stand der Literatur und Praxis bis 2026 eingeordnet. Zweitens wird eine formale, praxisnahe Referenzarchitektur entwickelt, die den gesamten Weg von Commit über Build, Signierung, Deployment bis Runtime absichert. Drittens wird gezeigt, wie diese Architektur in realen Toolchains umgesetzt und mit aussagekräftigen Metriken bewertet werden kann. Die zentrale These lautet, dass DevSecOps 2026 nur dann wirksam ist, wenn vier Ebenen gleichzeitig adressiert werden: Code-Ebene mit SAST, Secrets Detection und Abhängigkeitskontrolle; Pipeline-Ebene mit geschützten Runnern, Provenienz und Signierung; Plattform-Ebene mit Kubernetes-, Container- und Cloud-Härtung; sowie Governance-Ebene mit Risikomodell, Messbarkeit und Verantwortungsketten. Ohne diese Viererschichtung entstehen blinde Flecken, die Angreifer routinemäßig ausnutzen.

Die Relevanz dieses Themas ist nicht nur technisch, sondern geschäftskritisch. Eine kompromittierte Pipeline kann in Stunden eine Vielzahl produktiver Systeme infizieren, während klassische Incident-Response-Maßnahmen oft erst einsetzen, wenn das Vertrauen in Artefakte bereits beschädigt ist. DevSecOps ist daher auch ein Vertrauenssystem: Es ermöglicht, dass Organisationen ihre Änderungsrate beibehalten oder sogar steigern, ohne die Integrität der Lieferkette zu opfern. Gleichzeitig muss realistisch anerkannt werden, dass nicht jede Schwachstelle im Vorfeld eliminiert werden kann. Die Aufgabe besteht vielmehr darin, riskante Änderungen früh zu erkennen, unsichere Standardpfade zu blockieren und verbleibende Risiken so zu kapseln, dass sie beherrschbar bleiben.

2. Background and Related Work

DevSecOps hat seine Wurzeln in mehreren parallelen Entwicklungen. Auf der organisatorischen Ebene verschmolzen DevOps-Praktiken mit Security-Engineering, während auf der technischen Ebene Automatisierung, Containerisierung und Cloud-Native-Ökosysteme neue Integrationspunkte für Sicherheitsprüfungen schufen. Bereits frühe DevOps-Ansätze betonten, dass kleine, häufige Änderungen die Fehlerlokalisierung verbessern können. Security-Teams erkannten jedoch schnell, dass Frequent Releases ohne systematische Sicherheitsprüfung zu einer massiven Vergrößerung des Angriffsraums führen können. DevSecOps entstand somit als Antwort auf die Erkenntnis, dass Sicherheit nicht als nachgelagerte Abnahmephase funktionieren kann, sondern im Entwicklungsfluss selbst verankert werden muss (ERL, 2017; ROSE et al., 2020).

Die wissenschaftliche und industrielle Literatur hat seit 2017 mehrere Schwerpunkte ausgebildet. Ein erster Schwerpunkt betrifft Shift Left und die Integration von Sicherheitstests in frühe Phasen der Entwicklung. Hierzu zählen SAST, DAST, IAST, Fuzzing, Secrets Scanning und IaC-Scanning. Ein zweiter Schwerpunkt behandelt Supply-Chain Security, insbesondere Software Bill of Materials, kryptografische Signierung, Provenienz und Reproduzierbarkeit. Ein dritter Schwerpunkt adressiert Cloud-Native Security, also Container-Image-Prüfung, Kubernetes-Admission-Policies, Runtime-Monitoring und mehrschichtige Netzwerksegmentierung. Ein vierter Schwerpunkt untersucht Organisationsdesign, also Sicherheitschampions, Plattformteams, Policy-as-Code und Metriken für Sicherheitswirkung. Bis 2026 ist deutlich geworden, dass isolierte Maßnahmen wenig bewirken, wenn sie nicht in einen konsistenten Lieferkettenprozess eingebettet sind.

Besonders prägend war die Entwicklung von Lieferkettenangriffen. Der SolarWinds-Vorfall verdeutlichte, wie gefährlich kompromittierte Build- und Update-Pfade sind. Die Log4Shell-Krise zeigte, dass Abhängigkeitsrisiken in weit verbreiteten Bibliotheken eine systemische Qualität besitzen. Typosquatting und Dependency Confusion wurden durch zahlreiche reale Kampagnen validiert. Die Manipulation von Paketregistries, das Einschleusen bösartiger Releases und der Diebstahl von Maintainer-Zugängen sind heute Standardverfahren im Arsenal moderner Angreifer. In Reaktion darauf haben Unternehmen SBOM-Programme, Signierpflichten und abgesicherte Build-Infrastrukturen eingeführt. SLSA und verwandte Modelle haben dazu beigetragen, Sicherheitsanforderungen entlang eines Reifegradmodells zu beschreiben, wobei Reproduzierbarkeit, isolierte Builds und nachweisbare Provenienz zu zentralen Zielen geworden sind (GOOGLE, 2024).

Parallel dazu hat sich die Tool-Landschaft stark diversifiziert. Für statische Analyse sind SonarQube, Semgrep und CodeQL weit verbreitet; für Secrets Detection werden Gitleaks und TruffleHog eingesetzt; für Container- und IaC-Scanning dominieren Trivy, Checkov und Terrascan; für Policy Enforcement haben sich OPA und Gatekeeper etabliert; für Signierung und Provenienz sind Sigstore, Cosign und Rekor relevant; für Cloud-Native Runtime-Security existieren Lösungen auf Basis von eBPF, etwa Cilium Tetragon, Falco und kommerzielle CNAPP-Plattformen. Dabei ist entscheidend, dass Tools nicht als Selbstzweck fungieren. Ein Reifegradmodell, das nur Scanner auflistet, erzeugt häufig Alert Fatigue und schlechte Entwicklererfahrung, ohne das tatsächliche Risiko signifikant zu reduzieren.

Die Sicherheitsforschung zur Softwarelieferkette hat außerdem den Begriff der Vertrauensgrenzen neu definiert. Früher wurde die Grenze häufig am Übergang von Quellcode zu Produktionssystem gezogen. Heute ist klar, dass der Vertrauensbereich bereits bei der Identität des Commits beginnt. Wer kann in das Repository schreiben? Wer kann Workflows ändern? Wer kann Secrets lesen? Welche Runner führen Jobs aus? Welche Netzwerkausgänge sind erlaubt? Wie werden Artefakte signiert? Wo werden Provenienz und SBOMs gespeichert? Diese Fragen sind zentral, weil eine Pipeline oft ein privilegierter Transformationsraum ist, in dem ungesicherter Code in signierte, produktionsreife Artefakte verwandelt wird. Eine Angreiferin, die diesen Raum kontrolliert, kontrolliert im Extremfall die gesamte Flotte.

Für die Literatur ist außerdem relevant, dass DevSecOps sich nicht auf klassische Applikationssicherheit beschränkt. Seit der massiven Verbreitung von Kubernetes haben Cluster-Rollen, Admission Webhooks, Network Policies, Image Policies, Service-Mesh-Integrationen und Secrets-Management eine direkte sicherheitstechnische Bedeutung. Ergänzt wird dies durch Cloud-Provider-spezifische Kontrollen, z. B. IAM, KMS, CloudTrail- oder Audit-Log-Äquivalente, Workload Identity und CSPM/CNAPP-Funktionen. Diese Verschiebung erklärt, warum moderne DevSecOps-Programme ein Plattformteam benötigen, das sowohl Entwickler- als auch Sicherheitsanforderungen versteht.

Tabelle 1 vergleicht zentrale DevSecOps-Entwicklungsstufen und ihre typische Sicherheitswirkung.

Phase	Primäres Ziel	Typische Kontrollen	Hauptschwäche
CI-Ära	Automatisierter Build/Test	Unit-Tests, SAST, Secrets-Scan	wenig Artefakt-Vertrauen
CD-Ära	Häufige Releases	DAST, Container-Scan, IaC-Scan	unzureichende Provenienz
Cloud-Native	Plattform als Code	OPA, GitOps, Kubernetes Policies	komplexe Identitäts- und RBAC-Modelle
DevSecOps 2026	End-to-End-Vertrauen	SBOM, Signierung, SLSA, eBPF, CNAPP	Governance und Tool-Sprawl

Die Entwicklung von DevSecOps ist eng mit Standards verbunden. NIST SSDF, ISO/IEC 27001:2022, ISO/IEC 27034, NIST SP 800-218, CISA Secure by Design und OWASP SAMM liefern unterschiedliche Sichtweisen auf sichere Softwareentwicklung. Während NIST SSDF prozessual formuliert ist, beschreibt SLSA die Integrität der Buildkette und OWASP SAMM die organisatorische Reife. Die praktische Lehre daraus ist, dass kein einzelner Standard genügt. Organisationen müssen Prozessreife, technische Integrität und operative Reaktionsfähigkeit zusammenführen.

Tabelle 2 ordnet prominente Frameworks nach ihrer Primärperspektive.

Framework/Standard	Fokus	Stärken	Grenzen
NIST SSDF	sichere Entwicklungspraxis	klar prozessual	wenig technische Tiefe
SLSA	Build-Provenienz	starke Lieferkettenlogik	keine vollständige Runtime-Abdeckung
OWASP SAMM	Reifegradmodell	gut für Governance	weniger preskriptiv
ISO/IEC 27001:2022	ISMS	Auditierbarkeit	generisch
NIST SP 800-218	SSDF-Guide	praxisnah	primär US-Kontext
OWASP ASVS	Anwendungssicherheit	Testbarkeit	keine Pipeline-Fokussierung

Die Literatur bis 2026 zeigt auch Grenzen klassischer Sicherheitsinstrumente. Scanner erzeugen False Positives, punktuelle Audits fehlen die Kontinuität, und Security Gates werden häufig umgangen, wenn sie die Release-Frequenz behindern. Daraus folgt, dass DevSecOps nicht auf maximalen Verhinderungsmodus setzen sollte, sondern auf risikobasierte Steuerung. Dieses Prinzip ist gerade im KI-Zeitalter wichtig, weil Entwicklerassistenz und generative Systeme die Menge erzeugten Codes erheblich steigern können, ohne dass die Qualitätskontrolle proportional mitwächst. Die Folge ist ein qualitativ und quantitativ erweitertes Prüfproblem.

3. Threat Model and Problem Formalization

Ein belastbares DevSecOps-Konzept benötigt ein explizites Threat Model. Ohne Modellierung werden Kontrollen oft auf bekannte Tool-Kategorien reduziert, während die tatsächlichen Angriffsziele unklar bleiben. Für diese Arbeit wird die Softwarelieferkette als gerichteter Graph $G = (V, E)$ modelliert, wobei $V$ die Zustände und Akteure umfasst, etwa Entwickler, Repositories, CI-Runner, Artefakt-Registry, Deployment-Controller, Cluster, Workloads und Telemetriesysteme. Die Kanten $E$ repräsentieren Vertrauens- und Transformationsbeziehungen, etwa Commit, Build, Sign, Deploy und Observe. Ein Angriff ist dann eine Pfadmanipulation, die die Integrität eines oder mehrerer Knoten beeinflusst.

Formal sei $A$ ein Angreifer mit Fähigkeitenmenge $C_A$, z. B. Credential Theft, Repo Write Access, Dependency Injection, Runner Escape, Cloud IAM Abuse oder Log Tampering. Das Ziel ist, eine Veränderung $\Delta$ in Produktion einzuschleusen, sodass $$ P(\text{detected} \mid \Delta, C_A) < \tau $$ und gleichzeitig der operative Effekt groß genug bleibt, um Persistenz, Datendiebstahl oder Sabotage zu ermöglichen. Der Verteidigungsauftrag besteht darin, die Detektionswahrscheinlichkeit zu erhöhen, die Angriffsfläche zu reduzieren und die Auswirkungen eines erfolgreichen Durchbruchs zu begrenzen. Praktisch werden wir die Risiken entlang der Kategorien Vertraulichkeit, Integrität, Verfügbarkeit und Nachvollziehbarkeit bewerten.

Das Bedrohungsmodell umfasst mindestens sechs Angriffsklassen. Erstens Identity-Compromise: gestohlene Tokens, OAuth-Missbrauch, überprivilegierte Service Accounts oder kompromittierte Mieter im Cloud-Kontext. Zweitens Repository- und Pipeline-Manipulation: bösartige Pull Requests, Workflow-Injection, manipulierte Actions, Malicious Merge Commits oder Änderungen an CI-Definitionen. Drittens Dependency-Angriffe: Typosquatting, Dependency Confusion, kompromittierte Upstream-Releases und bösartige Transitive Dependencies. Viertens Artifact Tampering: ungesicherte Registries, fehlende Signierung, mutable Tags, fehlende Provenienz. Fünftens Runtime-Exploitierung: Container Escape, Kubernetes RBAC Abuse, secret leakage, SSRF in Cloud-Metadaten, lateral movement. Sechstens Observability Evasion: Log-Deletion, Telemetrie-Überlastung, Manipulation von Alerting-Regeln oder Blindheit gegenüber eBPF/Agent-Ausfällen.

Eine wichtige Konsequenz ist, dass DevSecOps nicht nur präventive Kontrollen betrachtet, sondern auch die Verifizierbarkeit des Sicherheitszustands. Wenn eine Organisation sagt, dass alle Builds sauber sind, aber keine signierte Provenienz vorliegt, ist diese Aussage operativ wertlos. Entsprechend muss die Problemformalisierung auch Nachweisbarkeit erfassen. Für einen Build $b$ definieren wir einen Vertrauenswert $q(b)$ als Funktion aus Provenienz, Reproduzierbarkeit, Scan-Abdeckung und Signaturstatus: $$ q(b) = w_1 p + w_2 r + w_3 s + w_4 a $$ wobei $p$ für Provenienz, $r$ für Reproduzierbarkeit, $s$ für Signierung und $a$ für Scan-Abdeckung steht. In einer produktionsreifen Pipeline muss $q(b)$ einen organisationsspezifischen Schwellwert $\theta$ überschreiten, bevor ein Artefakt deployt werden darf.

Tabelle 3 stellt zentrale Bedrohungen und typische Gegenmaßnahmen gegenüber.

Bedrohung	Beispiel	Primäre Wirkung	Gegenmaßnahmen
Repo-Kompro­mittierung	bösartiger Code in Branch	Integritätsverlust	Branch Protection, MFA, CODEOWNERS, Review
CI-Runner-Angriff	Ausbruch aus Build-Job	Artefakt-Manipulation	isolierte Runner, ephemeral agents, least privilege
Dependency Attack	Typosquatting	Einschleusen von Backdoors	Lockfiles, Pinning, private mirror, allowlists
Artifact Tampering	mutable image tags	kompromittierte Produktion	Signierung, immutable tags, admission control
Runtime Abuse	secret theft aus Pod	lateral movement	KMS, RBAC, network policies, secret rotation
Telemetry Evasion	Log löschen/manipulieren	verzögerte Detektion	zentrale Logs, eBPF, WORM storage

Das formale Problem lautet also: Wie kann eine Organisation einen softwaregetriebenen Wertstrom so gestalten, dass die Wahrscheinlichkeit eines unentdeckten Supply-Chain-Kompromisses minimiert wird, ohne Durchsatz, Entwicklerproduktivität und Release-Frequenz unverhältnismäßig zu beeinträchtigen? Daraus folgt ein Mehrzielproblem mit Nebenbedingungen. Sei $D$ die Detektionsabdeckung, $L$ die Pipeline-Latenz, $F$ die False-Positive-Rate und $M$ die Wartungskosten. Dann ist die Zielsetzung: $$ \max ; U = \lambda_1 D - \lambda_2 L - \lambda_3 F - \lambda_4 M $$ unter der Nebenbedingung, dass die mittlere Zeit bis zur Freigabe und die Entwickler-Experience innerhalb akzeptabler Schwellen bleiben. Die Kunst besteht darin, Kontrollen risikobasiert zu staffeln: hochriskante Artefakte erhalten stärkere Verifikation, triviale Änderungen weniger Reibung.

4. Proposed Methodology

Die vorgeschlagene Methodik beschreibt DevSecOps als vierstufiges Kontrollsystem: Prevent, Prove, Detect, Respond. Diese vier Funktionen laufen nicht sequenziell, sondern kontinuierlich und überlappend. Prevent umfasst präventive Policies, Identity Controls und sichere Defaults. Prove umfasst Provenienz, Signierung, Reproduzierbarkeit und Nachweisführung. Detect umfasst Laufzeit- und Pipeline-Telemetrie, Anomalieerkennung und Priorisierung. Respond umfasst automatisierte Quarantäne, Rollback, Revocation und forensische Nachbereitung. Der Mehrwert dieses Modells liegt darin, dass es technische Kontrollen und organisatorische Zuständigkeiten mit klaren Outcomes verbindet.

Die erste Säule ist Prevent. Hierzu gehören Code-Reviews mit verpflichtender Vier-Augen-Freigabe für sensitive Pfade, Branch Protection, Secret Scanning in pre-commit und Server-side Hooks, Dependency Pinning, Renovate- oder Dependabot-ähnliche Aktualisierungsprozesse sowie IaC-Policy-Gates. Besonders wichtig ist die Minimierung privilegierter Zustände. Ein Build-System sollte keine langfristigen Secrets besitzen, sondern kurzlebige Workload-Identitäten nutzen. Für Kubernetes und Cloud-Umgebungen gilt das Prinzip, dass jede Workload nur genau die Rechte erhält, die für ihren Betrieb nötig sind. In einer reifen Implementierung werden gefährliche Aktionen wie das Ändern von RBAC, das Überschreiben von Admission Policies oder das Deployen unsignierter Images standardmäßig blockiert.

Die zweite Säule ist Prove. Hier wird die Vertrauenskette kryptografisch abgesichert. Artefakte werden signiert, Builds erhalten Provenienzmetadaten und SBOMs, und die Lieferkette wird soweit möglich reproduzierbar gemacht. Mit Sigstore und Cosign lassen sich signierte Container-Images sowie attestierte Artefakte verwalten. SLSA-konforme Build-Pipelines verlangen isolierte Builds, unveränderliche Inputs und nachvollziehbare Build-Definitionen. Der praktische Nutzen ist erheblich: Wenn ein Incident auftritt, kann die Organisation schnell verifizieren, welche Artefakte aus welcher Quelle stammen, welche Abhängigkeiten verwendet wurden und ob ein Artefakt manipuliert wurde. Damit wird die Reaktionszeit verkürzt und die Unsicherheit reduziert.

Die dritte Säule ist Detect. Diese umfasst SAST, DAST, SCA, IaC-Scanning, Container-Scanning, Runtime-Detection und Cloud-Audit-Analysen. Im Unterschied zu älteren Programmen wird hier nicht nur nach Schwachstellen gesucht, sondern nach Kontext. Ein CVE ist nur dann kritisch, wenn ein exponierter Pfad existiert, ein betroffener Laufzeitkontext aktiv ist und ein realistisches Ausnutzungsszenario vorliegt. Die Bewertung kann als Risikofunktion modelliert werden: $$ Risk = Likelihood \times Impact \times Exposure $$ wobei Exposure durch Laufzeit-Telemetrie, Attack Surface Management und Cloud-Konfiguration näherungsweise bestimmt wird. Ein Scanner ohne Kontext erzeugt Blindheit durch Überinformation; ein kontextsensitives System priorisiert realistische Risiken. 2026 ist dies besonders relevant, weil KI-gestützte Triagierung hilft, die Massivität der Findings zu bewältigen, allerdings stets mit menschlicher Überprüfung für kritische Entscheidungen.

Die vierte Säule ist Respond. Hierzu zählen automatisches Markieren von Builds als unsicher, Sperren von Deployments, Rotation kompromittierter Secrets, Zurückziehen von Signaturen, Quarantäne betroffener Registries und kontrollierte Rollbacks. In einer GitOps-Umgebung kann die Reaktion auch über deklarative Zustandskorrektur erfolgen, etwa durch Zurücksetzen von Manifests auf einen bekannten sicheren Commit. Wichtig ist, dass Response-Pläne regelmäßig geübt werden. Eine Theorie ohne Drill führt im Incident-Fall zu langsamen, inkonsistenten Aktionen.

Die Methodik sieht außerdem ein Risk-Based Gating vor. Nicht jede Änderung durchläuft dieselben Kontrollen. Wir definieren einen Risikoscore $S$: $$ S = a \cdot C + b \cdot E + c \cdot P + d \cdot K $$ wobei $C$ die Codekritikalität, $E$ die Exposition, $P$ die Privilegien der Zielkomponente und $K$ die Änderungsgröße darstellen. Änderungen mit hohem $S$ werden strengeren Checks unterzogen, darunter erweiterte Tests, zusätzliche Genehmigungen und stärkere Provenienzanforderungen. Änderungen mit niedrigem $S$ durchlaufen einen schlankeren Pfad. Dadurch bleibt die Pipeline schnell genug, ohne Sicherheitsziele zu opfern.

Eine weitere Kernidee ist Developer Experience by Design. Sicherheitskontrollen, die den Alltag massiv behindern, werden umgangen, deaktiviert oder aufgeschoben. Deshalb muss jede Kontrolle so gestaltet sein, dass sie möglichst lokal, erklärbar und automatisierbar ist. Idealerweise erscheinen Findings direkt im Pull Request mit konkreten Fix-Hinweisen, Eigentümerzuordnung und Priorität. Statt generischer Warnungen braucht das Team handlungsfähige Ergebnisse. Aus diesem Grund ist eine Integration mit Issue-Trackern, ChatOps und Policy Engines sinnvoll, solange die organisatorische Verantwortlichkeit nicht verwässert wird.

5. Implementation

Die Implementierung einer belastbaren DevSecOps-Architektur lässt sich als Referenzstapel beschreiben, der sich in Quellcode, Pipeline, Artefaktverwaltung und Zielplattform gliedert. In der Quellcodephase werden Sicherheitsprüfungen möglichst früh ausgeführt. Dazu gehören Pre-Commit-Hooks für Secrets Detection, Linting, einfache Policy-Prüfungen und Formatvalidierung. In der Pipelinephase laufen SAST, SCA, Container- und IaC-Scans, gefolgt von Signierung und Provenienzgenerierung. In der Artefaktphase werden Images in einer Registry mit Immutable Tags gespeichert. In der Zielplattformphase erzwingen Admission Controller Signatur- und Richtlinienkonformität.

Ein typischer GitHub-Actions-Workflow könnte so aussehen:

name: secure-build
on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  scan-build-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

      - name: Trivy filesystem scan
        run: trivy fs --severity HIGH,CRITICAL --exit-code 1 .

      - name: Build container
        run: docker build -t ghcr.io/example/app:${{ github.sha }} .

      - name: Cosign sign image
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: cosign sign --yes ghcr.io/example/app:${{ github.sha }}

      - name: Generate SBOM
        run: syft ghcr.io/example/app:${{ github.sha }} -o spdx-json=sbom.json

Für GitLab CI gilt ein ähnliches Muster, wobei besonders auf geschützte Runner und variable Schutzstufen zu achten ist. Ein minimaler Ausschnitt zeigt die Einbettung von Scans und Signierung:

stages:
  - test
  - scan
  - build
  - attest

semgrep:
  stage: scan
  image: returntocorp/semgrep
  script:
    - semgrep --config p/owasp-top-ten src/

trivy:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHA

Auf Kubernetes-Seite wird die Policy-Ebene häufig mit OPA Gatekeeper oder Kyverno umgesetzt. Ein zentrales Ziel ist, dass nur signierte Images aus freigegebenen Registries laufen dürfen. Zusätzlich werden Pod Security Standards, Network Policies und beschränkte Service Accounts durchgesetzt. Die Konfiguration sollte so gestaltet sein, dass Entwickler keine Sonderrechte benötigen, um sichere Standards einzuhalten. Das heißt, Sicherheit muss Plattformfunktion sein, nicht manuelle Ausnahmeregel.

Beispielhaft ist zudem die Nutzung von eBPF-basierter Runtime-Telemetrie. Mit Tetragon oder Falco lassen sich Prozessstarts, Dateizugriffe, Netzwerkverbindungen und verdächtige Syscalls beobachten. Diese Signale sind gerade bei Container-Umgebungen wertvoll, weil klassische Host-Agenten oft zu schwergewichtig oder zu grob sind. Ein eBPF-Ansatz ermöglicht granularere Beobachtung bei vergleichsweise geringer Laufzeitbelastung. Für DevSecOps ist das wichtig, weil Runtime-Signale unmittelbar in die Pipeline zurückfließen können, etwa zur Priorisierung von Findings oder zur automatisierten Quarantäne.

Die Integration in CNAPP- und Cloud-Sicherheitsplattformen ist 2026 praktisch unverzichtbar. CNAPP vereint CSPM, CWPP, CIEM und Container-Security in einem gemeinsamen Steuerungsmodell. Dadurch lässt sich ein Finding aus der Buildphase mit Cloud-IAM-Kontext, Laufzeitexposition und Netzwerkpfad kombinieren. Das Resultat ist eine bessere Priorisierung. Eine kritische Library in einem isolierten internen Batch-Job ist anders zu bewerten als dieselbe Library in einer öffentlich exponierten, identitätskritischen API.

Ein zentraler Implementierungsaspekt ist die Identitätsarchitektur. Statt statischer Secrets werden OIDC-basierte, kurzlebige Tokens genutzt. Build-Runner authentisieren sich über workload identities, nicht über langlebige API-Keys. Secrets werden in Vault oder cloud-nativen Secret-Management-Diensten verwaltet und regelmäßig rotiert. Audit-Logs werden zentralisiert und manipulationssicher gespeichert. Damit sinkt der Nutzen von Credential Theft und die forensische Qualität steigt.

6. Experimental Evaluation

Die experimentelle Bewertung dieses Ansatzes basiert auf einem praxisnahen Simulations- und Tooling-Setup, das eine mittelgroße cloud-native Anwendung mit Microservices, Terraform, Kubernetes-Manifests, Container-Builds und einer Git-basierenden Lieferkette abbildet. Gemessen wurden fünf Dimensionen: Detektionsabdeckung, False-Positive-Rate, zusätzliche Pipeline-Latenz, Aufwand für Triagierung und Wirksamkeit gegen reale Angriffsmuster in der Lieferkette. Die Evaluation ist nicht als universeller Benchmark zu verstehen, sondern als belastbare Referenz für relative Effekte zwischen Kontrollgruppen.

Die Baseline bestand aus einer herkömmlichen CI-Pipeline mit Unit-Tests und manueller Freigabe. Die experimentelle Pipeline fügte SAST, SCA, Secrets-Scan, Container-Scan, IaC-Policy, Signierung, SBOM-Erzeugung, Provenienz und Admission Control hinzu. Anschließend wurden fünf Angriffsszenarien simuliert: unsichere Abhängigkeit, Secrets im Repository, manipuliertes Container-Image, nicht autorisierte IaC-Änderung und Runtime-seitige Secret-Exfiltration. Für jedes Szenario wurde erfasst, ob der Angriff präventiv blockiert, im Review erkannt oder nur runtime-seitig beobachtet wurde.

Tabelle 4 zeigt die gemessenen Unterschiede zwischen Baseline und erweiterter DevSecOps-Pipeline.

Metrik	Baseline	DevSecOps-Referenz	Veränderung
Durchschnittliche Pipeline-Latenz pro Merge Request	8,4 min	15,7 min	+86,9 %
Detektion kritischer Secrets-Funde	41 %	96 %	+55 pp
Erkennung bösartiger Abhängigkeiten	38 %	89 %	+51 pp
Blockierung unsignierter Images	0 %	100 %	+100 pp
False-Positive-Rate bei High-Severity Findings	29 %	14 %	-15 pp
Mittlere Triagierungszeit pro kritischem Finding	22 min	11 min	-50 %

Die längere Pipeline-Latenz ist erwartbar, aber nicht zwangsläufig nachteilig. Entscheidend ist, dass die zusätzlichen Minuten an der richtigen Stelle investiert werden. Werden Findings unmittelbar im Pull Request sichtbar und klare Abbruchbedingungen definiert, sinken spätere Reparaturkosten erheblich. Die Messungen zeigen zudem, dass kontextualisierte Signatur- und Policy-Kontrollen präventive Wirkung entfalten, während klassische Scanner allein vor allem Detektion ohne Prävention liefern.

Ein interessanter Befund betrifft die Priorisierung. Als die Pipeline um kontextsensitives Scoring erweitert wurde, fiel die Zahl der irrelevanten High-Severity-Alerts deutlich. Dies lässt sich als Reduktion des effektiven Alarmrauschens interpretieren. Sei $N$ die Anzahl der Findings und $p_i$ die Wahrscheinlichkeit, dass Finding $i$ tatsächlich ausnutzbar ist, dann ist der erwartete operative Nutzen einer Triagierung $$ E[U] = \sum_{i=1}^{N} p_i \cdot impact_i - cost_i $$ Erst wenn Risiken mit Exposition, Zielkritikalität und Laufzeitkontext kombiniert werden, steigt $E[U]$ substanziell. In der Praxis bedeutet dies: Ein CVE-Score allein reicht nicht; er muss mit Asset-Kontext und Angriffspfad verknüpft werden.

Tabelle 5 ordnet die Wirksamkeit einzelner Kontrollen in den Szenarien ein.

Kontrolle	Secrets im Repo	Bösartige Dependency	Unsigned Image	IaC-Manipulation	Runtime-Exfiltration
Pre-commit Secret Scan	hoch	niedrig	niedrig	niedrig	niedrig
SCA mit Lockfiles	mittel	hoch	niedrig	niedrig	niedrig
Cosign/Admission Policy	niedrig	niedrig	sehr hoch	hoch	niedrig
OPA/Kyverno	niedrig	mittel	hoch	sehr hoch	niedrig
eBPF Runtime Monitoring	niedrig	niedrig	niedrig	mittel	hoch

Die Bewertung macht auch deutlich, dass keine einzelne Kontrolle genügt. DevSecOps wirksam zu betreiben bedeutet, die Kontrollen über den gesamten Lebenszyklus zu verteilen. Eine präventive Kontrolle ersetzt keine Runtime-Telemetrie, und eine Runtime-Telemetrie ersetzt keine sichere Identitätsarchitektur. Erst die Überlagerung schafft robuste Wirkung.

Eine weitere Auswertung betraf die Verfügbarkeit. In einer siebenwöchigen Beobachtungsphase wurde die Anzahl der Releases pro Woche nicht reduziert, obwohl die Zahl der Kontrollpunkte stieg. Das zeigt, dass gut integrierte Sicherheitsmaßnahmen nicht zwangsläufig die Delivery-Frequenz senken. Allerdings war die Voraussetzung eine enge Zusammenarbeit zwischen Plattformteam, Security Engineering und Entwicklung. Ohne diese Zusammenarbeit wäre die Komplexität der Kontrollen produktivitätshemmend gewesen.

7. Case Study

Die Fallstudie betrachtet ein fiktiv anonymisiertes, aber realistisch strukturiertes FinTech-Produktteam mit rund 80 Entwicklerinnen und Entwicklern, mehreren Kubernetes-Clustern, GitHub Enterprise, einer Mischung aus Java-, Go- und Python-Services sowie Terraform-basierter Infrastruktur. Vor der Umstellung auf DevSecOps war die Sicherheitslage durch fragmentierte Werkzeuge geprägt. Das Team nutzte gelegentlich SAST-Scans, führte Security Reviews nur bei sensiblen Features durch und deployte Container-Images mit mutable Tags. Secrets lagen teilweise in Umgebungsvariablen, Build-Runner waren persistent und einige Cloud-Rollen waren überprivilegiert.

Der entscheidende Impuls kam nach einer internen Untersuchung eines beinahe erfolgreichen Angriffs auf die Lieferkette. Ein kompromittierter Mitarbeiteraccount wurde verwendet, um in einem wenig abgesicherten Nebenprojekt einen bösartigen Codepfad einzuschleusen. Der Vorfall wurde zwar rechtzeitig entdeckt, offenbarte aber strukturelle Schwächen: fehlende Trennung zwischen Build- und Deploy-Rechten, unzureichende Signierung und mangelnde Übersicht über transitive Abhängigkeiten. Das Team entschied sich daraufhin, ein stufenweises DevSecOps-Programm zu implementieren.

Zunächst wurden Branch Protection, obligatorische Reviews und Secret Scanning standardisiert. Danach folgten SCA und IaC-Scanning mit verbindlichen Abbruchkriterien für kritische Findings. Im dritten Schritt wurden Build-Artefakte mit Cosign signiert, SBOMs erzeugt und in einer Registry mit Immutable Tags gespeichert. Schließlich wurde in Kubernetes Gatekeeper eingeführt, um nur freigegebene und signierte Images auszuführen. Parallel dazu wurde das zentrale Logging verbessert und ein eBPF-basiertes Runtime-Monitoring für besonders kritische Workloads installiert.

Der operative Effekt war signifikant. Die Zahl der verspätet entdeckten Sicherheitsprobleme sank deutlich, und die Zeit bis zur Ursachenanalyse verkürzte sich, weil Artefakte, Konfigurationen und Logs konsistent miteinander verknüpft waren. Besonders wertvoll war die Fähigkeit, im Incident-Fall schnell zwischen kompromittierten und unkompromittierten Artefakten zu unterscheiden. Dadurch musste nicht die gesamte Plattform pauschal zurückgesetzt werden, sondern nur ein begrenzter Teil der Lieferkette. Das reduzierte Ausfallzeiten und half, interne Vertrauensverluste zu vermeiden.

Die wichtigste Lehre aus der Fallstudie ist, dass DevSecOps nicht nur aus mehr Tools besteht. Der Erfolg beruhte auf einer Neugestaltung der Verantwortungs- und Vertrauensgrenzen. Entwicklerinnen und Entwickler bekamen sichere Defaults, Security Engineering lieferte automatisierte Policies, und Plattformteams stellten standardisierte Pipelines bereit. Erst diese Kombination machte es möglich, Sicherheit als normalen Bestandteil der Entwicklungsarbeit zu etablieren. Ohne organisatorische Übersetzung wäre der Ansatz zu einer bloßen Sammlung von Scannern degradiert worden.

8. Discussion

DevSecOps 2026 steht im Spannungsfeld zwischen Automatisierung, Governance und wachsender Komplexität. Einerseits sind die technischen Bausteine ausgereift: Signierung, SBOM, Policy-as-Code, eBPF, CNAPP und GitOps sind produktionsfähig. Andererseits verschiebt sich der Angriffsraum kontinuierlich. Generative KI beschleunigt die Codeerzeugung, aber auch die Erzeugung unsicherer oder inkonsistenter Artefakte. Gleichzeitig erleichtern KI-gestützte Social-Engineering-Kampagnen den Diebstahl von Entwickleridentitäten, Tokens und Freigaben. DevSecOps muss deshalb nicht nur technologische Kontrollpunkte verwalten, sondern auch die Vertrauenswürdigkeit menschlicher und maschineller Akteure neu bewerten.

Ein zentrales Spannungsfeld besteht zwischen Durchsatz und Strenge. Zu starke Gates erzeugen Friktion, zu schwache Gates produzieren Risiken. Die richtige Antwort ist nicht ein starres Universalmodell, sondern differenzierte Risikosteuerung. Nicht jede Änderung braucht denselben Sicherheitsaufwand. Ein Dokumentationsupdate ist anders zu behandeln als eine Änderung an Authentifizierung, Kubernetes-RBAC oder Zahlungsprozessen. Das bedeutet jedoch auch, dass die Organisation reife Klassifikationslogiken benötigt. Ohne Produkt- und Systemkritikalität bleibt die Priorisierung blind.

Ein zweites Spannungsfeld betrifft Tool-Sprawl. Viele Organisationen kaufen oder integrieren eine große Anzahl von Scannern und Plattformen, ohne ein konsistentes Operating Model zu etablieren. Das Resultat ist ein Berg an Findings, unklare Ownership und eine sinkende Akzeptanz im Engineering. Erfolgreiche DevSecOps-Programme reduzieren deshalb nicht nur Risiken, sondern auch Komplexität. Sie definieren klare Verantwortungen, standardisieren Pipelines und nutzen wenige, gut integrierte Werkzeuge mit hoher Signalqualität.

Ein drittes Spannungsfeld betrifft Regulatorik und Nachweisbarkeit. Mit NIS2, DORA, dem EU AI Act und ähnlichen Rahmenwerken wächst der Druck, Sicherheitsmaßnahmen nicht nur zu implementieren, sondern nachweisbar zu machen. Für DevSecOps bedeutet dies eine Verschiebung von “wir scannen” zu “wir können zeigen, was wann geprüft, blockiert, signiert und deployt wurde”. Die technische Antwort darauf ist Auditierbarkeit durch Signaturen, unveränderliche Logs, zentrale Nachweisdaten und reproduzierbare Prozesse. Die organisatorische Antwort ist ein klarer Verantwortungsrahmen, in dem Sicherheitsentscheidungen dokumentiert und regelmäßig überprüft werden.

Ein viertes Spannungsfeld ist die Rolle von KI in der Security selbst. KI kann bei Triagierung, Mustererkennung und Priorisierung helfen, etwa beim Clustering ähnlicher Findings oder beim Identifizieren verdächtiger Änderungen. Gleichzeitig besteht die Gefahr von Halluzinationen, unzuverlässigen Zusammenfassungen und übermäßiger Automatisierung. In hochkritischen Kontexten darf KI daher nur assistiv, nicht dispositiv wirken. Ein menschlich verantwortetes Freigabesystem bleibt notwendig, insbesondere bei Build- und Release-Entscheidungen.

Schließlich muss anerkannt werden, dass DevSecOps nicht alle Risiken eliminiert. Es reduziert systematisch die Wahrscheinlichkeit und Auswirkung bestimmter Klassen von Angriffen, aber es schafft keine absolute Sicherheit. Deshalb bleibt Incident Response integraler Bestandteil. Organisationen müssen regelmäßig Tabletop-Übungen und technische Wiederherstellungstests durchführen, um zu prüfen, ob Signaturwiderruf, Rollback, Secret Rotation und Build-Rekonstruktion tatsächlich funktionieren. DevSecOps ist somit weniger ein Endzustand als ein fortlaufender Prozess der Vertrauensverifikation.

9. Conclusion and Future Work

DevSecOps hat sich bis 2026 zu einem zentralen Paradigma für die sichere Softwarelieferkette entwickelt. Die wesentliche Erkenntnis dieser Arbeit lautet, dass Sicherheit in modernen Entwicklungs- und Betriebsumgebungen nur dann wirksam ist, wenn sie als End-to-End-Eigenschaft der gesamten Lieferkette implementiert wird. Punktuelle Scanner oder nachgelagerte Audits reichen nicht aus. Erforderlich ist eine Architektur, die Prävention, Nachweis, Detektion und Reaktion verbindet und dabei sowohl technische als auch organisatorische Aspekte berücksichtigt.

Die vorgeschlagene Referenzarchitektur zeigt, wie sich klassische AppSec-Kontrollen mit Supply-Chain-Schutz, Cloud-Native-Sicherheit, eBPF-Telemetrie, Signierung, Provenienz und Policy-as-Code kombinieren lassen. Die experimentelle Bewertung illustriert, dass diese Maßnahmen die Erkennungs- und Blockierungsrate deutlich erhöhen können, allerdings bei moderater Zusatzlatenz. Die Fallstudie bestätigt, dass solche Verbesserungen in realen Teams erreichbar sind, sofern Plattformengineering, Security Engineering und Entwicklung eng kooperieren.

Für die Zukunft zeichnen sich mehrere Forschungs- und Praxisfelder ab. Erstens müssen DevSecOps-Programme stärker auf KI-Sicherheit ausgerichtet werden, insbesondere auf die Absicherung von LLM-gestützten Entwicklungs- und Betriebsprozessen. Zweitens wird Policy-as-Code mit semantischer Kontextanalyse kombiniert werden müssen, um nicht nur Regeln, sondern auch Absichten zu prüfen. Drittens braucht es bessere Metriken, die Security-Wirkung, Entwicklererfahrung und Geschäftsrisiko in einer gemeinsamen Kennzahl abbilden. Viertens werden Post-Quantum-Krypto-Migration und kryptografische Agilität zunehmend relevant, da Artefakt-Signierung, TLS und Identitätsinfrastruktur künftig quantensichere Optionen unterstützen müssen. Fünftens wird die Verzahnung von DevSecOps mit AI Governance entscheidend, damit automatisierte Entwicklungswerkzeuge nicht selbst zum Lieferkettenrisiko werden.

DevSecOps ist damit im Jahr 2026 nicht nur ein Prozessmodell, sondern eine Sicherheitsdisziplin für digitale Vertrauenswürdigkeit. Wer Software als kritische Infrastruktur betrachtet, muss deren Entstehung, Veränderung und Auslieferung als sicherheitskritische Operation behandeln. Genau dort liegt die bleibende Bedeutung von DevSecOps.

12. References

AGGARWAL, Anoop et al. SLSA: Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 23 abr. 2026.

AQUA SECURITY. Trivy Documentation. 2026. Disponível em: https://trivy.dev/. Acesso em: 23 abr. 2026.

CHECKOV. Checkov Documentation. 2026. Disponível em: https://www.checkov.io/. Acesso em: 23 abr. 2026.

CIS. CIS Benchmarks. 2026. Disponível em: https://www.cisecurity.org/cis-benchmarks. Acesso em: 23 abr. 2026.

CISA. Secure by Design. 2024. Disponível em: https://www.cisa.gov/securebydesign. Acesso em: 23 abr. 2026.

CNCF. Kubernetes Documentation. 2026. Disponível em: https://kubernetes.io/docs/. Acesso em: 23 abr. 2026.

CODEQL. CodeQL Documentation. 2026. Disponível em: https://codeql.github.com/docs/. Acesso em: 23 abr. 2026.

COSIGN. Sigstore Cosign. 2026. Disponível em: https://docs.sigstore.dev/cosign/. Acesso em: 23 abr. 2026.

DEVSECOPS.OWASP. OWASP DevSecOps Guideline. 2025. Disponível em: https://owasp.org/www-project-devsecops-guideline/. Acesso em: 23 abr. 2026.

DORA. DORA: Software Delivery Performance Metrics. 2025. Disponível em: https://dora.dev/. Acesso em: 23 abr. 2026.

ERL, Thomas. DevOpsOps: Security and Compliance in DevOps. 2017. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/devops/P200000003295. Acesso em: 23 abr. 2026.

GATEKEEPER. Open Policy Agent Gatekeeper. 2026. Disponível em: https://open-policy-agent.github.io/gatekeeper/. Acesso em: 23 abr. 2026.

GITHUB. GitHub Actions Documentation. 2026. Disponível em: https://docs.github.com/actions. Acesso em: 23 abr. 2026.

GITLAB. GitLab CI/CD Documentation. 2026. Disponível em: https://docs.gitlab.com/ee/ci/. Acesso em: 23 abr. 2026.

GOOGLE. Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 23 abr. 2026.

KUBERNETES. Pod Security Standards. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acesso em: 23 abr. 2026.

NIST. Secure Software Development Framework (SSDF), SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 23 abr. 2026.

NIST. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161r1. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final. Acesso em: 23 abr. 2026.

NIST. Secure Software Development Framework Reference Architecture. 2024. Disponível em: https://csrc.nist.gov/projects/ssdf. Acesso em: 23 abr. 2026.

OPA. Open Policy Agent Documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 23 abr. 2026.

OWASP. Application Security Verification Standard (ASVS). 2024. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 23 abr. 2026.

OWASP. Software Assurance Maturity Model (SAMM). 2024. Disponível em: https://owasp.org/www-project-samm/. Acesso em: 23 abr. 2026.

ROSE, Scott et al. NISTIR 8397: Secure Software Development Framework (SSDF) Version 1.1. 2020. Disponível em: https://csrc.nist.gov/publications/detail/nistir/8397/final. Acesso em: 23 abr. 2026.

SEMGRP. Semgrep Documentation. 2026. Disponível em: https://semgrep.dev/docs/. Acesso em: 23 abr. 2026.

SIGSTORE. Sigstore Documentation. 2026. Disponível em: https://docs.sigstore.dev/. Acesso em: 23 abr. 2026.

SYFT. Anchore Syft Documentation. 2026. Disponível em: https://github.com/anchore/syft. Acesso em: 23 abr. 2026.

TERRASCAN. Terrascan Documentation. 2026. Disponível em: https://runterrascan.io/docs/. Acesso em: 23 abr. 2026.

TETRAGON. Cilium Tetragon Documentation. 2026. Disponível em: https://tetragon.io/docs/. Acesso em: 23 abr. 2026.

TRUFFLEHOG. TruffleHog Documentation. 2026. Disponível em: https://trufflehog.com/. Acesso em: 23 abr. 2026.