A Practical DevSecOps Pipeline Checklist
How a 30-service org cut security gate noise by 60% and fixed more critical findings—without a six-month transformation program.
A mid-size engineering org had SonarQube, Trivy, and secret scanning in GitHub Actions—but developers ignored the results. Merge requests showed dozens of medium findings. Critical issues sat open for weeks because they looked like style warnings in the UI.
Start with what actually fails pipelines today
We pulled 30 days of pipeline runs and tagged failures: secrets (4%), critical CVEs (9%), dependency policy (22%), everything else. Most of “everything else” was noise. Leadership agreed to fail builds only on secrets and criticals for four weeks while teams cleared the backlog—otherwise engineers would keep using admin overrides.
Critical-only gates developers will accept
One security stage in GitHub Actions with three checks: gitleaks, Trivy on the built image (critical/high only), SonarQube scoped to security hotspots. Medium findings became MR comments, not blockers. Critical fix time dropped from 12 days median to 4 in the first month.
Add policy-as-code only when basics are stable
OPA policies for non-root containers and approved base images came after 90% of services passed the lighter gates. Admission control on day one would have blocked deploys while teams were still fixing Dockerfiles.
An evidence store reviewers can search—not PDFs
Security did not want PDFs—they wanted searchable artifacts. Each release uploads scan JSON, SBOM, and approval metadata to S3, keyed by service and git SHA. Reviewers use a simple lookup form. Audit prep went from half a day per release to under an hour of spot checks.