DevSecOps Build Standard: Security Gates in Every Pipeline

Two weeks before launch, a product team huddles to get the system through penetration testing. Critical findings come back. The team works late, patches what it can, ships with a "to-be-fixed" register attached to the launch document. They pass. They move on. Six months later, the next product they build looks the same — the same eleventh-hour pen test, the same patch sprint, the same register of unresolved issues. The discipline that would have caught each finding the day the code was written never existed. Pen testing functioned as a gate. It did not function as a process.

This is the failure pattern the DevSecOps Build Standard exists to prevent. The pattern is structural: when security is a stage at the end, it becomes a negotiation between launch pressure and patch effort. When security is a property of the pipeline, it becomes the path of least resistance. Inside the Built to Last™ 2.0 framework, this standard sits in P05 — The Right Code — and sets one expectation for every engagement: SAST, DAST, dependency scanning, container scanning, and secrets detection run on every commit, every pull request, every build, from sprint one. Not because compliance asks for it. Because it is cheaper than the alternative.

Why security at the end is always late

The cost of late-stage security is not the headline-grabbing breach. It is the slow grinding cost of finding issues at the moment fixing them is most expensive — when the architecture has hardened, the test surface has grown, and the next sprint is already committed. Industry research from NIST and the OWASP Foundation has long observed the same shape: vulnerabilities discovered after deployment cost dramatically more to remediate than the same vulnerabilities caught in development. The exact multiple varies by source; the direction does not.

The cost compounds across three axes. Schedule: every critical finding becomes a sprint surprise the team did not plan for. Trust: a customer who hears "we patched it in time" hears "you would not have noticed without us". And compliance: SOC 2, PCI-DSS, HIPAA, and (in Australia) the Essential Eight all expect evidence of continuous security activity, not a single annual audit. A pipeline that runs SAST on every commit produces that evidence as a by-product. A team that scrambles before launch produces a panic and an artefact nobody trusts.

The most damaging cost is invisible. When security is reactive, security work degrades velocity at the worst possible moment, which trains the team to associate security with delay. That association is the cultural failure mode the DevSecOps Build Standard exists to break.

What the DevSecOps Build Standard actually is

The DevSecOps Build Standard is a set of automated security gates wired into the CI/CD pipeline from the first sprint, with documented severity thresholds, defined break behaviours, and a human-reviewed exception path. It is not "we have a security tool". It is the specific combination of five gates running in a specific order, on every change to every codebase, against a published policy. Each gate addresses a class of vulnerability the others cannot see.

Static Application Security Testing (SAST)

SAST scans source code for vulnerabilities — SQL injection, command injection, insecure deserialisation, broken authentication, hardcoded credentials, unsafe cryptography. It runs against the developer's branch before merge, and again against main on every push. The output is a structured finding: rule ID, severity, file, line, suggested remediation. Critical findings block the merge. High findings require an explicit reviewer override with a comment. Medium and low findings are surfaced as informational and tracked in a backlog the team works down deliberately.

The common SAST tools — SonarQube, Semgrep, Checkmarx, Snyk Code, GitHub Advanced Security — produce similar findings on similar code. The decision that matters is not the tool. It is the policy: which severities block, what the override path is, who owns false-positive triage. A team that runs SAST without a documented policy is producing noise. A team that runs SAST with a documented policy is producing decisions.

Dynamic Application Security Testing (DAST)

DAST tests the running application against a known set of attack patterns — the OWASP Top 10 categories of broken access control, injection, server-side request forgery, security misconfiguration, and the rest. It runs against a deployed environment, typically a staging instance the pipeline provisions on every release candidate. Where SAST finds vulnerabilities the code contains, DAST finds vulnerabilities the running system exposes — misconfigured CORS, leaked stack traces in error responses, predictable session tokens, authorisation logic that compiles cleanly but lets the wrong user see the wrong data.

DAST tools (OWASP ZAP, Burp Suite, Nuclei) carry higher false-positive rates than SAST because they infer vulnerabilities from external behaviour. The integration that works treats DAST as a gate on release candidates rather than every commit, with the same severity-driven policy SAST uses.

Software composition analysis and dependency scanning

SCA scans the dependency tree — direct dependencies, transitive dependencies, lockfile contents — against vulnerability databases (the National Vulnerability Database, the GitHub Advisory Database, vendor-specific feeds). A critical finding triggers an automated pull request to update the affected dependency to a patched version where one exists, or a tracked exception where it does not. Dependency scanning is one of the cheapest gates to install and catches the most novel vulnerabilities, because the surface it covers — third-party code — is the surface the team has the least visibility into.

The supply-chain failure modes SCA addresses are not theoretical. Log4Shell, the xz-utils backdoor, the regular cadence of compromised npm packages — each was a multi-week firefight for teams without dependency scanning and a same-day automated patch for teams with it.

Container and infrastructure scanning

For systems that ship containers or infrastructure-as-code, two more gates run alongside the application gates. Container image scanning (Trivy, Grype, Anchore, Snyk Container) inspects the base image and every layer for known vulnerabilities, embedded secrets, and configuration issues — running as root, missing health checks, exposed unnecessary ports. Infrastructure-as-Code scanning (Checkov, tfsec, KICS) inspects Terraform, CloudFormation, Kubernetes manifests, and Helm charts for misconfigurations — public buckets, overly permissive IAM policies, unencrypted volumes, missing logging.

The same severity-driven policy applies. The same documented exception path applies. The same observation holds: the tools are commoditised; the discipline is the policy.

Secrets detection

Secrets in source control are the single most common preventable cause of breach. The pipeline runs a secrets detection gate (Gitleaks, TruffleHog, GitHub Secret Scanning, Snyk Code) on every commit, and a pre-commit hook on the developer's machine catches the secret before it leaves the laptop. When a secret is found post-commit, the gate blocks the build, the secret is revoked automatically through an integration with the secrets manager, and a runbook entry triggers rotation. Revocation alone is insufficient — a leaked credential in Git history has been read by every fork, every clone, and every public-feed scraper between commit and discovery.

How the gates fit together

A pull request runs SAST, SCA, and secrets detection in parallel within a minute or two. A merge to main triggers a rebuild and re-runs the same scans against the integrated branch. A release candidate provisions a staging environment, runs DAST against it, and runs container and IaC scans against the deployment artefacts. The dashboard reports current status per service: critical, high, medium, low findings; trend over time; mean time to remediate. The dashboard is not a vanity metric. It is the evidence trail SOC 2, ISO 27001, and the Essential Eight all ask for.

Three failure modes recur. The gates run but findings are not actioned, so the build is permanently red and the team starts merging around it. The gates run but severity policies are not documented, so each engineer makes a judgement call and the policy drifts. Or the gates run on main but not on pull requests, so issues are discovered after merge — too late to prevent them entering history.

How to build the standard into an active engagement

Implementation is more sequencing than tooling. The five gates take roughly four sprints to install if work is sequenced; six to eight if the team is retrofitting onto an existing pipeline with significant debt.

Sprint one is policy. Before any tool is configured, the team writes down what severities block, what severities warn, what the override path is, and who owns triage. A one-page document — committed to the repository — is enough. Tools without policy generate noise; policy without tools generates intent. Both have to land in the same week, in that order.

Sprint two installs SAST, secrets detection, and a pre-commit hook. These three are the cheapest to add, the most immediately useful, and the lowest-friction for the team to adopt. Findings start as informational for the first two weeks while the team triages false positives and tunes rules to the codebase. Then severities become blocking, in the order Critical → High → Medium, with a sprint between each escalation so the team is never gated by an unexpected wall of findings.

Sprint three adds dependency scanning and automated pull requests for vulnerable packages. The first run will surface dozens of findings on an established codebase. Prioritise critical and high severity issues by exploitability — not severity score alone — and accept the others into a tracked backlog with a deliberate burn-down. Dependabot, Renovate, and Snyk all do this work; the team chooses one and commits to it.

Sprint four adds DAST and container scanning. DAST requires a staging environment the pipeline can provision and tear down; if one does not exist, that is the prerequisite the sprint addresses. Container scanning requires reproducible build artefacts; if the team's build is non-deterministic, that is the prerequisite. Neither is exotic, both are common, and both are worth fixing on their own merits.

What to do this week. Run a one-day baseline scan with any open-source SAST and secrets tool — Semgrep and Gitleaks both work from the command line in minutes. Take the report to the next architecture review. The conversation about "what shall we do with the secrets we just found in Git history" is the conversation that turns DevSecOps from an item in a backlog into a sprint with an owner.

What to avoid. Do not install all five gates in one sprint. Do not turn every severity blocking on day one. Do not let security findings sit in a separate ticket queue from feature work; they belong in the same backlog, prioritised by the same engineering lead. And do not make the security review a meeting. It is a pipeline result.

The DevSecOps Build Standard pairs with the CI/CD Pipeline Implementation (which provides the substrate the gates run on), AI-Powered Code Review (which catches a different class of issue earlier in the loop), and the Production Readiness Review™ (which verifies the gates are operational before launch). Our DevOps practice treats these as a single discipline, and our custom software delivery approach embeds the standard from the first sprint of every engagement. The same gates protect agentic AI systems, where supply-chain risk from model and embedding libraries is now part of the dependency surface.

A composite from two builds

A Sydney-based fintech we worked with shipped a customer-facing application after a final-fortnight pen-testing scramble. Eighteen findings came back, six of them critical. The team patched what it could in eight days, accepted residual risk on three findings into a launch register, and went live. The pattern repeated on the next two products. By the third launch, the team was budgeting two weeks of every release for the same scramble; the cumulative cost across the portfolio approached a sprint per product per quarter.

The same team's next build was structured against the DevSecOps Build Standard. Severity policy was committed to the repository in sprint one. SAST, dependency scanning, and secrets detection ran in CI from sprint two. Container scanning was added in sprint three; DAST against staging was wired in sprint four. By the time the build reached the Production Readiness Review, the pen-testing engagement looked different. The external testers ran their full battery and returned two findings — both medium severity, both in areas the automated gates were not designed to cover (a business-logic authorisation issue and a session-handling edge case the automated tools did not pattern-match). Remediation took two days. The launch register was empty at go-live.

In scenario terms, the cost difference was roughly three sprints across a six-month build — the difference between security as a final-fortnight panic and security as a structural property of the pipeline. Same engineering quality, same compliance position, lower calendar cost.

When this matters most, and when you can defer it

The standard is critical the moment a system handles user data, processes payments, sits in a regulated industry, or operates under SOC 2, ISO 27001, PCI-DSS, HIPAA, or the Australian Essential Eight. It is critical for any system whose breach would constitute a notifiable incident under the Notifiable Data Breaches scheme. And it is critical for any engagement where an external squad has production access — staff augmentation, TaaS, or contract engineering — because the standard is what makes that access defensible.

It can be deferred — not skipped — for narrow internal prototypes where the system handles synthetic data, is not exposed to the public internet, and will be retired before production scale. Even there, secrets detection and dependency scanning are worth wiring in week one; they cost almost nothing and prevent the class of mistake that follows a prototype into production when it is unexpectedly promoted.

The honest broker view: the cost of the standard is consistently overestimated and the cost of its absence is consistently underestimated. Teams that defer it almost always defer it longer than they intended.

What to do next

If your pipeline does not currently fail a build on a critical SAST finding, a leaked secret, or a known-vulnerable dependency, schedule the hour this week to write the severity policy and the next sprint to install the first three gates. The remaining two follow in the sprints after. For the broader cadence the standard sits inside, see our project delivery framework and our custom software engineering practice.

Frequently Asked Questions