The Gap Between Aspiration and Reality
Every DevOps team says they do DevSecOps. In most cases, what they mean is: "We added a SAST scanner to our pipeline six months ago and nobody looks at the results." That's not DevSecOps. That's checkbox compliance with a modern label.
Real DevSecOps maturity isn't about which tools you've purchased. It's about how deeply security thinking is embedded in your development culture, your architecture decisions, your deployment practices, and your incident response capabilities. The distance between "we have a scanner" and "security is a first-class engineering concern" is vast, and most organizations are closer to the first than they'd like to admit.
This maturity model isn't academic. It's built from observing hundreds of engineering organizations — from startups running npm audit in a cron job to enterprises with dedicated product security teams. The levels aren't meant to shame anyone. They're meant to give you an honest baseline so you can figure out where to invest next.
Level 0: Ad Hoc
Characteristics:
- Security is somebody else's problem (usually "the security team")
- No automated security scanning in the development workflow
- Vulnerabilities are discovered through periodic penetration tests or, worse, production incidents
- Developers have no visibility into the security posture of their applications
- Open-source dependencies are chosen based on functionality alone, with no security consideration
- No SBOM generation or software inventory
How you got here: This is the starting state for most organizations. Security was historically a gate at the end of the development process — something that happened to software after it was built. Many teams haven't yet shifted from this model.
The risk: At Level 0, your vulnerability detection is reactive. You find out about problems after they're exploitable, often after they've been exploited. Your mean time to remediation is measured in weeks or months because there's no process, no tooling, and no ownership.
Level 1: Reactive Scanning
Characteristics:
- At least one security scanner runs in CI/CD (typically SAST or SCA)
- Scan results go to a dashboard or report that someone theoretically reviews
- High false-positive rates erode developer trust in the tooling
- Security findings are filed as bugs but rarely prioritized against feature work
- Dependency updates happen sporadically, usually only when something breaks
- Some awareness of SBOM requirements, but no consistent generation
How you got here: Someone (often a security champion or a compliance mandate) pushed to add scanning to the pipeline. The tool was configured with defaults. Initial enthusiasm faded as false positives piled up and nobody owned the remediation workflow.
The risk: Level 1 creates a dangerous illusion of security. The scanner runs, alerts fire, but nothing changes. When auditors ask "do you scan for vulnerabilities?" you can say yes. But the gap between scanning and acting on results means vulnerabilities still ship to production.
Level 2: Integrated Scanning
Characteristics:
- Multiple security tools in the pipeline (SAST, SCA, container scanning, secrets detection)
- Results are integrated into developer workflows (PR comments, IDE plugins, Jira tickets)
- False positive suppression and tuning are actively maintained
- Severity-based policies gate deployments (critical vulnerabilities block merges)
- Dependency update automation (Dependabot, Renovate) is configured and maintained
- SBOMs are generated for releases, at least for primary applications
How you got here: The reactive scanning stage generated enough pain that someone invested in tuning. False positives were suppressed. Results were routed to developers instead of siloed dashboards. Policies were created to prevent the worst vulnerabilities from shipping.
The risk: Level 2 is where most "good" organizations plateau. The tooling works, developers see results, and critical issues get blocked. But security is still primarily a detection game. You catch known vulnerabilities in known components. You don't catch architectural weaknesses, business logic flaws, or supply chain attacks that don't trigger CVE-based detection.
Level 3: Proactive Security Engineering
Characteristics:
- Security requirements are defined during design, not after implementation
- Threat modeling is practiced for significant features and architecture changes
- Developers receive regular security training relevant to their stack
- Security champions exist within development teams (not just centralized security)
- Supply chain security controls go beyond scanning: dependency pinning, lockfile enforcement, package provenance verification
- SBOMs are comprehensive, automatically generated, and actively used for vulnerability monitoring
- Vulnerability remediation has defined SLAs that are actually tracked and met
How you got here: Leadership recognized that catching vulnerabilities at build time is necessary but insufficient. Investment shifted upstream — into design reviews, developer education, and architectural patterns that prevent vulnerability classes entirely.
The risk: Level 3 organizations are significantly more resilient than Levels 0-2. The remaining gaps are typically in supply chain attacks that evade known-vulnerability detection (typosquatting, dependency confusion, compromised maintainer accounts) and in the consistency of practices across teams.
Level 4: Security as Culture
Characteristics:
- Every developer understands the security implications of their code and dependencies
- Security metrics (time to remediate, vulnerability density, SBOM coverage) are tracked alongside performance and reliability metrics
- Automated policy enforcement covers the full software supply chain: source code, dependencies, build systems, container images, deployment configurations
- The organization can respond to zero-day vulnerabilities in hours, not days
- Open-source contribution includes security considerations (upstream patches, vulnerability reports)
- Software provenance and attestation are standard practice (SLSA, Sigstore)
- Security debt is tracked and addressed with the same rigor as technical debt
How you got here: Years of sustained investment. Security isn't a department that reviews things. It's an engineering discipline practiced by everyone who writes code. The security team's role shifted from gatekeeper to enabler — building platforms, tooling, and training that make secure development the path of least resistance.
The risk: Level 4 organizations aren't immune to attack. They're just prepared. The risk at this level is complacency — believing that mature practices mean the work is done. Security is a continuous process. The threat landscape evolves faster than any maturity model.
Assessing Where You Are
Be honest. Here's a quick diagnostic:
Answer these questions:
-
When Log4Shell was disclosed, how long did it take your organization to determine which applications were affected?
- We still don't know → Level 0
- Days to weeks → Level 1
- Hours to a day → Level 2
- Under an hour → Level 3-4
-
When a developer opens a pull request that adds a new dependency, what happens?
- Nothing → Level 0
- A scanner might flag known CVEs → Level 1
- Automated checks verify license, known vulnerabilities, and maintainer health → Level 2-3
- The dependency is evaluated against supply chain policies including provenance, popularity, and security posture → Level 3-4
-
Who owns vulnerability remediation?
- Nobody (or "security") → Level 0-1
- Development teams, but without SLAs → Level 1-2
- Development teams with tracked SLAs → Level 3
- Development teams with SLAs, automated tracking, and executive visibility → Level 4
-
Can you produce an SBOM for your production applications right now?
- No → Level 0
- For some applications, manually → Level 1
- Automatically for most applications → Level 2
- Automatically for all applications, with continuous monitoring → Level 3-4
Moving Up the Ladder
Maturity improvements compound. Each level makes the next one easier. Here's where to focus at each transition:
Level 0 to 1
Start with SCA. It delivers the most value with the least friction. Pick a tool that integrates with your CI platform, turn it on with default settings, and start generating data. Don't worry about tuning yet. Just get visibility.
Level 1 to 2
Invest in tuning and workflow integration. Suppress false positives ruthlessly. Route findings to the developers who own the code. Add deployment gates for critical and high severity vulnerabilities. Set up automated dependency updates.
Level 2 to 3
Shift investment upstream. Start threat modeling for new features. Launch a security champions program. Define and track remediation SLAs. Expand supply chain controls beyond known-vulnerability scanning.
Level 3 to 4
This is the hardest transition because it's cultural, not technical. Security must become a shared value, not a shared obligation. Invest in developer security education. Make security metrics visible at the leadership level. Adopt software provenance and attestation practices.
The Maturity Trap
One final caution: maturity models are useful for self-assessment, but dangerous as goals. The objective isn't to reach Level 4. The objective is to reduce risk proportional to your threat model. A ten-person startup doesn't need Level 4 DevSecOps maturity. It needs Level 2 practices executed consistently, with a plan to grow as the organization grows.
Conversely, a financial services company or defense contractor operating at Level 1 is carrying risk that regulators and adversaries will eventually punish. The maturity level you target should match your risk profile, your regulatory environment, and your resources.
Don't chase maturity for its own sake. Chase security outcomes.
How Safeguard.sh Helps
Safeguard meets you where you are. For Level 0-1 organizations, it provides immediate visibility through automated SCA scanning and SBOM generation that plugs into your existing CI/CD pipeline with minimal configuration. For Level 2-3 organizations, it adds policy enforcement, continuous monitoring, and vulnerability prioritization that cuts through noise. Wherever you are on the maturity curve, Safeguard gives you the tooling foundation to move up — without requiring a six-month implementation project.