A DevSecOps Checklist: Securing the Pipeline from Commit to Production

Security teams used to test applications shortly before release, producing long reports that delivery teams struggled to address. DevSecOps replaces that with security built into each step of delivery, automated where possible and owned by the teams who build the software. This checklist turns the idea into concrete controls.

The checklist

1. Design

• Threat modeling for new features, integrations and data flows — see our guide to threat modeling.
• Security acceptance criteria in user stories.
• Data classification for new data stores.

2. Code

• Static application security testing on every pull request.
• Peer review with a security checklist for high-risk changes.
• Secure coding standards mapped to the OWASP Top 10.

3. Dependencies

• Software composition analysis for known vulnerabilities and licences.
• Lockfiles and pinned versions.
• A software bill of materials (SBOM) for each release.
• A policy for new dependencies, including checks that packages exist and come from expected publishers.

4. Secrets

• Secret scanning on commits and in history.
• Secrets stored in a secret manager, injected at runtime.
• Rotation procedures and alerts on exposure.

5. Infrastructure as code

• Scanning templates for misconfigurations before deployment.
• Policy as code for rules such as encryption, public access and network exposure.
• Drift detection between declared and actual infrastructure.

6. Containers

• Minimal, maintained base images.
• Image scanning in the pipeline and registry.
• Non-root containers, read-only file systems where possible and resource limits.

7. The pipeline itself

• Least-privilege credentials for pipeline jobs, preferably short-lived.
• Protected branches and required reviews.
• Signed artefacts and verification before deployment.
• Audit logs for pipeline changes and deployments.

8. Deployment and runtime

• Dynamic application security testing against staging.
• Web application firewall and rate limiting where appropriate.
• Centralised logging, security alerting and incident response playbooks.
• Regular patching and vulnerability management for running systems.

Worked example: securing a SaaS pipeline in 90 days

A hypothetical SaaS company with 12 repositories and a cloud-hosted platform starts with no automated security checks.

• Weeks 1–2: enable secret scanning across all repositories and history; rotate three exposed keys found; protect main branches and require reviews.
• Weeks 3–6: add dependency scanning with blocking only on critical vulnerabilities with available fixes; generate SBOMs on release; move pipeline credentials to short-lived tokens.
• Weeks 7–10: introduce static analysis and infrastructure-as-code scanning in warning mode, tune rules, then make high-severity findings blocking.
• Weeks 11–13: scan container images, adopt minimal base images and add a dynamic scan against staging before releases.

Each step is measured by open critical findings and time to remediate, reviewed fortnightly with team leads.

Roles and responsibilities

Prioritising

Avoiding alert fatigue

• Tune tools to reduce false positives before making them blocking.
• Block only on critical and high findings with clear fixes; report others.
• Route findings to the owning team’s backlog, not a separate security queue.
• Track exceptions with expiry dates.

Metrics

• Mean time to remediate critical and high findings.
• Number of open critical findings over time.
• Share of repositories with each control enabled.
• Secrets detected and time to rotate.
• Security issues found in production versus in the pipeline.

Frequently asked questions

Does DevSecOps slow down delivery?

Poorly tuned tools can. Well-tuned, fast checks that block only serious issues usually speed delivery by avoiding late surprises.

Who owns security in DevSecOps?

Delivery teams own the security of what they build, supported by security specialists who set standards, provide tools and handle complex risks.

Do we still need penetration testing?

Yes, periodically and for significant changes. Automated checks do not replace skilled manual testing.

Where do AI features fit?

Add checks for prompt injection, data leakage and excessive agency to threat models and tests for any feature using language models.