DevSecOps Operating Model

Secure delivery without turning every release into a security project

DevSecOps works when security controls are close to the work, automated where possible, and owned by the same teams that operate production. The goal is faster feedback, clearer accountability, and evidence that survives customer or auditor review.

Operating principles#

Shift left and keep right — catch preventable issues before merge, then monitor production for what only appears at runtime.
Make secure paths the default — templates, reusable workflows, golden images, and policy bundles should be easier than exceptions.
Keep humans for risk decisions — automation should classify, block obvious failures, and route ambiguous issues to the right owner.
Record evidence automatically — every production deployment should be traceable to source, artifact, approval, and runtime owner.

Responsibility model#

Capability	Product team	Platform team	Security/compliance owner
Threat modeling	Own service assumptions and abuse cases	Provide templates and facilitation	Review high-risk changes
CI/CD controls	Fix findings and own exceptions	Provide reusable workflows and runners	Define required controls
Dependency security	Upgrade and test packages	Provide bots, caches, and mirrors	Set severity policy
Cloud/IaC policy	Own service-level IaC	Maintain policy-as-code and landing zones	Approve risky exceptions
Incident response	Triage service impact	Support infrastructure recovery	Coordinate severity, evidence, and disclosure
Compliance evidence	Provide service records	Automate control exports	Maintain control map and audit package

Pipeline control stack#

Stage	Controls	Fail condition	Evidence
Commit	Secret scanning, pre-commit checks	Verified credential or private key committed	Scanner alert and rotation ticket
Pull request	Code review, dependency diff, IaC lint	High-risk change without owner review	PR review and check status
Build	SAST, dependency scan, SBOM, container scan	Critical exploitable dependency with no exception	Build logs, SBOM, artifact digest
Deploy	Policy-as-code, approval for production, signed artifact verification	Unknown artifact or unapproved production change	Deployment record and approver
Runtime	Cloud audit logs, workload telemetry, vulnerability monitoring	Active exploit path or suspicious control-plane action	Alert, incident timeline, remediation record

yaml

1
production_release:
2
  requires:
3
    - branch_protection: main
4
    - artifact_signature: verified
5
    - sbom: generated
6
    - secrets_scan: passed
7
    - container_critical_vulns: none_or_approved_exception
8
    - deployment_owner: service_catalog_match

Maturity path#

Stage 1: Stabilize the basics#

Enforce branch protection and required reviews.
Turn on secret scanning and dependency alerts.
Establish ownership for production repositories and cloud accounts.
Create a vulnerability severity policy.

Stage 2: Standardize secure delivery#

Move teams onto reusable CI/CD workflows.
Add IaC scanning and container scanning to the standard pipeline.
Generate SBOMs for production artifacts.
Define exception records with owner, risk, and expiration date.

Stage 3: Automate evidence#

Link source commit, artifact digest, deployment, and runtime service.
Export CI/CD and access evidence for customer security reviews.
Add policy-as-code for cloud and Kubernetes controls.
Review control failures in the same cadence as reliability incidents.

Stage 4: Improve through exercises#

Run tabletop exercises for leaked secrets, compromised CI tokens, dependency compromise, and cloud account abuse.
Measure mean time to rotate, mean time to patch, and exception age.
Feed recurring findings back into platform templates.

DevSecOps checklist#

Required reviews and status checks protect production branches.
CI logs redact secrets and avoid printing sensitive environment variables.
Repository and package permissions use least privilege.
Critical dependencies have owners, upgrade paths, and emergency patch procedures.
Container images are minimal, scanned, and pinned by digest for production.
IaC changes are reviewed with blast-radius context.
CI/CD runners are isolated for untrusted code and protected environments.
Production deployments produce an auditable record.
Exceptions expire and are reviewed by a named risk owner.

Useful standards and references#

OWASP DevSecOps Guideline provides practical controls for secure delivery pipelines.
SLSA defines supply-chain integrity levels for build provenance and artifact protection.
OpenSSF Scorecard helps assess open-source project security practices.
CISA Secure Software Development Attestation reflects growing expectations around secure software practices.