DevSecOps

Turns the pipeline into a series of automated security gates, without slowing the team down.

OPACosignSigstoreSLSA

What it is

is the combination of culture and automation: security stops being a review at the end of the cycle and becomes code inside CI/CD, with responsibility shared among development, operations and security.

Security gates

Each stage gets a gate with an explicit criterion:

PR blocked if or reports a new critical finding
only gets pushed if the vulnerability scan passes
deploy conditioned on a signed and verified artifact
(/Rego) versioned alongside the pipeline

Policy as code: the gate written down, not agreed on

A real gate is not a verbal agreement: it is a versioned file that the pipeline consults. In OPA/Rego, the rule below denies any image with a critical vulnerability, and the reason text appears in the deploy's error message:

policy/images.regorego

package deploy

deny[msg] {
  input.image.vulns.critical > 0
  msg := sprintf("image %s has %d critical vulnerabilities",
                 [input.image.name, input.image.vulns.critical])
}

Proving provenance: the deploy that verifies the signature

The next level is proving origin and integrity: frameworks like and record each artifact's provenance, and tools like Cosign/Sigstore sign images and commits. The deploy only proceeds if the signature matches: the artifact came from your pipeline, from the expected commit, untampered:

deploy.shbash

cosign verify --key cosign.pub ghcr.io/org/app:1.4.2
cosign verify-attestation --type slsaprovenance \
  --key cosign.pub ghcr.io/org/app:1.4.2

The balance

A gate that is too rigid gets bypassed: devs work around tools that block delivery over false positives. The healthy path is to start in audit mode (alert without blocking), measure, tune the rules and tighten the gates gradually. Each tightening is a data-driven decision, not an act of faith.

DevSecOpsSecurity as code inside CI/CD, with automated gates and shared responsibility.see in glossary →SASTStatic analysis: examines the code without running it. It finds issues through flow analysis, not guesswork.see in glossary →SCAComposition analysis: inventories third-party dependencies and cross-references them with known CVEs.see in glossary →Container imageA read-only stack of layers plus metadata from which containers start. Identified by a digest, tagged by a mutable name.see in glossary →Policy as codeOPA / RegoThe security policy written as a versioned file that the pipeline consults (deny an image with a critical vulnerability, require a signature). Change the criterion = change the file, with review.see in glossary →RegoOPADeclarative language of Open Policy Agent for writing policies evaluated against an input (a Terraform plan, a Kubernetes manifest, an API request).see in glossary →SLSASupply-chain Levels for Software Artifacts: a scale from 1 to 4 for build integrity, from 'has documentation' to 'tamper-resistant build with verifiable provenance'.see in glossary →in-totoA framework that signs, step by step, what the pipeline did: it proves the expected process ran, in the expected order, with no step swapped.see in glossary →

connections on the map

DevSecOpsgates & policiesCI/CD
Threat modeling: think like the attacker before codingbecomes a gateDevSecOps

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

The verification loopvibecodingautomatic gates in the pipeline, with no exception for generated code
CSPM - cloud posturecloudsecbecomes continuous policy in production
Policy as codesecenggates and policies, written as executable code

Study before

test what you learned

Loading questions…