DevSecOps in 2026: policy-as-code in CI/CD with OPA, SLSA, Sigstore and Trivy

Software security can no longer wait for the final review.
Transform your rules into executable, traceable and blocking controls at the right time.

1. Key figures

2. Introduction

A CI/CD pipeline can be rapide and fragile. It can compile, test, build an image, push to registry, deploy to staging, then to a live environment, while letting a secret, an unsigned artifact, a critical dependency, an IAM rule that is too open or a Kubernetes deployment without resource limits pass.

Friction doesn't always happen at commit time. It happens when a customer audit asks for proof, when a supply chain incident reveals a vulnerable dependency, when a developer bypasses a noisy scanner, when the CISO discovers that exceptions are not documented anywhere, when the "urgent" becomes the norm.

The verdict is clear: a delivery chain without enforceable policies relies on implicit trust.

DevSecOps is about more than adding a security tool to a crowded pipeline. Its interest lies elsewhere: making the rules readable, versioned, testable and applicable. With policy-as-code, this shift becomes concrete. The instruction leaves the PDF; it becomes a control that reads an artifact, makes a decision, produces a trace and blocks only when the risk justifies it.

This nuance is important. Blocking everything is impossible. Allowing everything is irresponsible. Maturity lies somewhere in between: clear policies, controlled exceptions, prioritization by severity, exportable evidence, shared responsibility.

3. Players

The DevSecOps policy-as-code ecosystem brings together standards, scanning tools, decision engines and delivery platforms.

3.1. The standards provide the vocabulary

3.2. Tools do not all have the same job

The trap would be to confuse tool and system. Trivy detects. OPA decides. SLSA structures provenance. Signstore sign. The pipeline orchestrates. The CISO is the arbiter. Developers fix. No actor replaces the others. As in an assembly line, quality control only has value if it occurs at the right position, with a criterion understood by the workshop.

4. Definition

We call policy-as-code the practice of writing security, compliance or governance rules in a versioned, executable and machine-testable format.

In a CI/CD chain, these rules evaluate concrete inputs: pull request, Terraform file, container image, Kubernetes manifest, SBOM, SLSA attestation, Cosign signature, scan result, dependency, secret, license or deployment context. The output is a decision: allow, warn, block, request an exception, or escalate.

The definition must remain precise. A scanner is not automatically policy-as-code. A scanner produces a signal. The rules engine transforms this signal into a decision consistent with a business requirement. For example: "block an unattested container in a critical environment", "refuse a root container", "prohibit a critical CVE that can be exploited without a planned patch", "request RSSI approval for an exception of 14 days", "refuse a secret detected in a commit".

DevSecOps then becomes a chain of proof.

5. Background 2026

The pressure comes from two directions. On one side, the software surface extends: microservices, containers, open source, IaC, SaaS, APIs, registries, AI agents, transitive dependencies, GitHub or GitLab workflows. On the other hand, attackers exploit the flaws in this chain more methodically. The Verizon DBIR 2026 indicates that 31 % breaches now start with software vulnerabilities, ahead of stolen passwords as the initial vector.

This data changes the order of priorities. For a long time, the security effort has focused heavily on authentication, networking, and monitoring. These subjects remain major. But the software manufacturing chain becomes a direct area of ​​attack: compromised dependency, modified image, hijacked CI script, exfiltrated secret, non-reproducible construction, overly permissive cloud configuration.

The NIST SSDF offers a substantive response: prepare the organization, protect the software, produce secure software and respond to vulnerabilities. The logic is not to block developers, but to integrate verifiable practices into the life cycle. CISA, for its part, emphasizes security by design, transparency and SBOM as elements of supply chain visibility.

This approach gives the operational layer. It avoids the big gap between the principles and the reality of the pipeline. A control written in Rego, Conftest, Gatekeeper, Kyverno or equivalent can be revised in pull request, tested, gradually deployed and audited. An SLSA attestation or GitHub Artifact Attestation proves provenance. A Sigstore signature links an artifact to a build identity. An SBOM supports vulnerability management.

Automated correctly, security becomes more explicit. It doesn't disappear.

6. Recommended method

The recommended method follows a simple principle: start from delivery risks, translate into minimal policies, automate gradually, then harden as signal quality increases.

6.1. Start with the actual flow

1. Map the build and deployment chain. We identify where the code comes in, where it is tested, where the container artifact is built, where secrets are available, where dependencies are resolved, where deliverables are stored, and where deployments are validated. Without this mapping, controls arise haphazardly.

2. Classify environments. The level of requirements varies between an experimental branch, a test environment, pre-production and an exposed service. The rules distinguish warning, soft blocking and strict blocking. This progressiveness reduces bypasses.

3. Define a base of minimal gates. The first base covers secrets, exploitable critical vulnerabilities, obsolete dependencies, prohibited licenses, dangerous IaC, root container, unsigned artifact, absence of SBOM, missing provenance for a sensitive deployment. Better a short, understood and accepted base than a treaty impossible to apply.

6.2. Transform signals into decisions

4. Separate detection and decision. Scanning tools produce results. Politicians decide. This separation avoids being subject to a tool's default thresholds. It also makes it possible to say: a critical vulnerability in an exposed service blocks; the same weakness in a never-loaded component can create a limited exception.

5. Version rules like code. The controls repository lives in a repository, with unit tests, review, changelog and owners. An untested security condition may break delivery. An instruction without history cannot be proven.

6. Attest the artifacts. Builds intended for critical environments produce provenance: source, commit, workflow, builder, dependencies, digest, signature. SLSA and Sigstore provide the necessary building blocks to connect the deliverable to its origin.

6.3. Govern exceptions

7. Handle exceptions like a product. A waiver contains a reason, duration, owner, accepted risk, expiration date, and corrective action. Without a deadline, it becomes a permanent flaw.

8. Measure the effects. Useful indicators cover deadlocks, false positives, remediation times, open critical vulnerabilities, expired overrides, signed images, attested artifacts, reproducible builds, detected secrets, and changed rules.

9. Linking CI/CD and production. Policy control doesn't stop at the build. The same intentions extend into Kubernetes admission, GitOps, registries, cloud and observability. Otherwise, the pipeline appears clean while execution remains permissive.

This method is deliberately pragmatic. It protects the flow without freezing it.

7. Logik tips

We recommend not starting with a “zero vulnerability” ambition. It's attractive in a presentation, rarely sustainable in a real team. The good start identifies controls that avoid serious incidents with little debate: secrets in code, unsigned artifact in critical environment, excessive privileges, critical dependency exploitable without a plan, absence of owner.

Then, we recommend appointing an owner per rule family. The doctrine remains on the security side, but the platform maintains the execution, the application teams correct, and the product arbitrates the deadlines when a business release is concerned. Without governance, policy-as-code becomes an opaque wall.

We also favor exportable evidence. A B2B client, investor, insurer or auditor will rarely request a pipeline screenshot. He will ask for proof: SBOM, certificate, signature, history of corrections, exception policy, risk matrix. Building these proofs from the start avoids a painful reconstruction at the critical moment.

Finally, we emphasize pedagogy. A block should explain what to fix, where to act, and how to request an exception. A cryptic error message creates workaround. Clear feedback creates discipline.

Recommended internal networking: link this article to contents Logiks on pre-release technical audit, EDR vs SME antivirus, Zero Trust, PRA/PCA, SME cybersecurity audit and AI governance.

8. Decision grid

8.1. Choose what is really blocking

8.2. Keep a ruler legible

A blockage must remain rare, explainable and difficult to circumvent. When everything is blocked, the teams look for a side door. When nothing blocks, politics does not exist.

9. Frequent errors

The first mistake is to activate ten scanners without a common policy. Developers receive conflicting alerts, thresholds vary, tickets pile up, and then fatigue sets in. A non-prioritized signal ends up ignored.

The second mistake is blocking too early. An organization that discovers 800 vulnerabilities should not turn the entire CI red on day one. It must create a baseline, block new critical risks and absorb the old stock in batches.

The third mistake is treating the SBOM like a PDF. A useful SBOM is automatically generated, attached to an artifact, preserved, machine-exploitable, and linked to vulnerabilities. Otherwise, it reassures more than it protects.

The fourth mistake is forgetting the secrets of the pipeline. CI/CD environments manipulate cloud tokens, registry keys, deployment identifiers and elevated permissions. Protecting the code without protecting the pipeline is like closing the door and leaving the keys outside.

The fifth mistake is not testing policies. A poorly written OPA control can block a healthy release or miss a critical case. The rules must have their fixtures, their tests and their reviews.

The sixth mistake is leaving exceptions endless. A permanent exception is no longer an exception. It is an unsupported alternative policy.

10. Action Plan 30 / 60 / 90 days

10.1. days: establish the baseline

Within 30 days, we map the pipeline, artifacts, registries, secrets, environments and responsibilities. Existing scans are consolidated, but the only immediate blocks are on secrets and risks that are already indisputable. A first exception policy specifies ownership, duration and expected proof.

10.2. days: apply the first gates

Within 60 days, the first coded controls enter the chain: IaC, containers, signatures, SBOM, vulnerability thresholds and Kubernetes admission if the context lends itself to it. The rules are versioned, tested and reviewed. The reporting distinguishes between historical stock and new risk introduced.

10.3. days: produce auditable evidence

Within 90 days, provenance and attestations cover critical deliverables. Sensitive containers are signed, SBOMs attached, exceptions expire automatically, and large deployments verify the origin of artifacts. The steering committees track few metrics: useful blocks, correction time, expired exceptions, signature/provenance coverage, critical debt.

The flow then carries a measurable share of security. Not an end-of-race meeting.

11. FAQ

What is the difference between DevSecOps and policy-as-code?
DevSecOps is a culture and organization that integrates security into development and operations. Policy-as-code is a technical way of making rules executable, testable and auditable.

Is takeover mandatory?
No. OPA is a powerful and widely adopted engine, but Kyverno, Conftest, Sentinel, Checkov or native gates may be suitable. The structuring point is the clarity of the rules and their integration into the pipeline.

Should we block all critical vulnerabilities?
Not mechanically. Critical vulnerabilities that can be exploited, exposed or without acceptable mitigation must be blocked. A mature policy considers context, but documents any exceptions.

Does SLSA replace scanners?
No. SLSA mainly deals with provenance and build integrity. The scanners process vulnerabilities, secrets, IaC, licenses or configurations. The two complement each other.

What is Sigstore used for in an SME SaaS?
Sigstore allows you to sign and verify artifacts without managing a complex PKI. For an SMB deploying containers, this is a pragmatic way to reduce the risk of unauthorized images.

How to avoid slowing down developers?
By starting with few rules, clear messages, limited exceptions, an existing debt baseline and targeted blocking of new or critical risks.

12. Main sources

• Verizon, 2026 Data Breach Investigations Report: https://www.verizon.com/business/resources/reports/dbir/
• NIST, Secure Software Development Framework SP 800-218: https://csrc.nist.gov/pubs/sp/800/218/final
• NIST SP 800-218 PDF: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf
• OpenSSF SLSA v1.1 levels: https://slsa.dev/spec/v1.1/levels
• SLSA Build Track basics v1.2: https://slsa.dev/spec/v1.2/build-track-basics
• CNCF, Open Policy Agent project: https://www.cncf.io/projects/open-policy-agent-opa/
• Open Policy Agent: https://openpolicyagent.org/
• Trivy GitHub repository: https://github.com/aquasecurity/trivy
• Trivy misconfiguration scanning: https://trivy.dev/docs/latest/scanner/misconfiguration/
• CISA, Secure by Design: https://www.cisa.gov/securebydesign
• CISA, 2025 Minimum Elements for SBOM: https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
• Sigstore Cosign signing overview: https://docs.sigstore.dev/cosign/signing/overview/
• GitHub Artifact Certifications documentation: https://docs.github.com/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds