01
The four-stage maturity model
| Stage | Operating mode | Evidence that should exist |
|---|---|---|
| 1. Discover | Map the current delivery system before enforcing new policy. | Languages, frameworks, deployment model, tests, coverage, dependencies, licenses, CI platform and current findings are inventoried. |
| 2. Baseline / Warn | Run common controls without blocking inherited debt. | Legacy findings are classified, critical test gaps are repaired, and temporary exceptions have owners and expiry dates. |
| 3. Enforce New Changes | Prevent new risk from entering while existing debt is worked down. | New secrets, denied licenses, new critical/high findings, material IaC failures, missing critical tests and releases without required SBOM evidence are blocked. |
| 4. Full Release Enforcement | Apply the complete release policy to the releasable artifact and customer experience. | Regression, browser/UI, DAST where applicable, final artifact/image scans, license review, signing or attestation, deployment approval, post-deployment verification and reporting are enforced. |
02
Measure maturity across the delivery system
- Governance: protected branches, reviewed changes, accountable owners and explicit exception handling.
- Application security: secrets, SAST, dependency, infrastructure-as-code and dynamic testing where applicable.
- Software supply chain: final-artifact SBOM, vulnerability and license analysis, provenance and signing or attestation where required.
- Quality engineering: unit, API, integration, functional, negative, regression and deployment tests mapped to change risk.
- Frontend quality where applicable: browser, responsive, visual, accessibility and performance evidence.
- Release operations: rollback or recovery planning, deployment approval, smoke checks and refreshed release evidence.
03
A release gate is a policy, not a scanner list
A mature Secure SDLC does not block every finding indiscriminately. It defines which conditions stop a release, which findings require review, who can approve an exception, how long that exception remains valid and what evidence is retained.
Examples of default blocking conditions can include build or type failures, confirmed secrets, unexcepted critical or high security findings, SBOM generation failure, denied licenses, unexpected visual regressions, critical browser or accessibility defects and missing required release attestations.
04
Use evidence completeness as a maturity signal
A useful maturity assessment asks whether a team can prove that the required controls ran against the actual release candidate. Missing evidence should not be treated as a healthy zero. The assessment should distinguish pass, fail or blocked, review required, not run, not applicable, not integrated and active or expired exception states.
This makes maturity measurable across GitHub, Azure DevOps or another CI platform without making a dashboard the source of truth. CI and release policy remain authoritative; reporting is a visibility layer.
05
Common failure modes
- Installing scanners before defining ownership and remediation workflow.
- Treating legacy debt as a reason to leave all new changes unenforced.
- Generating an SBOM from source only while ignoring the final built artifact or image.
- Allowing permanent silent exclusions or exceptions without expiry.
- Using coverage percentage as a substitute for meaningful critical-path tests.
- Auto-approving visual or security baselines merely to make CI green.
06
How to use the model
Start with the lowest stage that accurately describes the current operating model, then identify the smallest evidence-backed controls needed to reach the next stage. The model is an adoption and engineering-governance framework, not an external certification or assurance scheme.
For an existing project, the practical goal is controlled progression: establish visibility, stop adding new preventable risk, then enforce the full release policy once the team has enough test, security, supply-chain and operational evidence to sustain it.
From insight to action
Discuss the practical next step
If this topic maps to an active initiative, Zurix can help assess the current state, define a proportionate target and plan controlled implementation.