What is DevSecOps

DevSecOps is the practice of integrating security into every phase of the software development lifecycle (SDLC), rather than treating it as a separate phase at the end. It extends the DevOps philosophy of collaboration and automation to include security as a shared responsibility across development, operations, and security teams.

Security is everyone's job, not just the security team's.

Core Principles

1. Security as Code Treat security policies, configurations, and infrastructure as code that can be versioned, tested, and automated, just like application code.

Why it matters:

• Security becomes reproducible and testable
• Changes are tracked and auditable
• Policies can be reviewed like code
• Enables automation and consistency

2. Shift-Left Security Move security considerations earlier in the development process to catch issues when they’re cheaper and easier to fix.

3. Continuous Security Integrate security checks into automated pipelines for ongoing validation throughout the development and deployment process.

Why it matters:

• Security validation happens automatically
• Fast feedback on security issues
• Consistent security standards
• No manual security bottlenecks

4. Shared Responsibility Security is everyone’s job, not just the security team’s. Developers, operations, and security collaborate on security outcomes.

Why it matters:

• Security team can’t review everything
• Developers understand the code best
• Shared ownership improves outcomes
• Builds security awareness across teams

5. Automation First Automate security testing, scanning, and compliance checks wherever possible to provide fast feedback without slowing delivery.

Why it matters:

• Manual security reviews don’t scale
• Automation provides consistent results
• Fast feedback enables rapid iteration
• Frees security experts for complex work

DevSecOps vs. Traditional Security

Traditional Security Approach:

Plan → Design → Develop → Test → Security Review → Deploy
                                      ↑
                              Security is a gate here
                              - Manual reviews
                              - Delays releases
                              - Late-stage findings
                              - Security vs. Speed tradeoff

DevSecOps Approach:

Plan → Design → Develop → Test → Deploy
  ↓      ↓        ↓        ↓       ↓
Security integrated at every phase
- Threat modeling in planning
- Security design reviews
- Automated security scans
- Security tests in CI/CD
- Continuous monitoring

Why DevSecOps Matters

Early Detection:

• Finding vulnerabilities during development is exponentially cheaper than finding them in production
• Developer context is fresh, making fixes easier
• Prevents security debt from accumulating

Faster Delivery:

• Automated security checks don’t slow down deployment pipelines
• No waiting for manual security reviews
• Security validation happens in parallel with other checks

Reduced Risk:

• Continuous security validation reduces the attack surface
• Fewer vulnerabilities reach production
• Faster response to emerging threats

Better Compliance:

• Automated compliance checking makes audits easier
• Continuous evidence collection
• Clear audit trails through version control

Security Culture:

• Embedding security in workflows builds security awareness
• Developers gain security skills
• Security becomes part of “done”
• Less adversarial relationship between security and development teams

Shift-Left Security

Shift-left security means moving security practices earlier (to the “left”) in the development timeline, rather than treating security as a gate at the end.

The Shift-Left Mindset

Traditional approach: Security is something the security team does at the end.

Shift-left approach: Security considerations are integrated from the very beginning, with every team member playing a role.

What Shifting Left Adds

The general benefits are listed under Why DevSecOps Matters above. Two are specific to moving the work earlier.

Lower Cost:

• Fixing a vulnerability during development costs far less than fixing it in production
• Industry estimates: 10-100x cost difference depending on the phase
• Less rework and fewer emergency patches

Better Design:

• Security considerations influence architecture from the start
• Threat modeling reveals design flaws before implementation
• Prevents building systems with fundamental security weaknesses

Security in the SDLC Phases

This section provides a detailed view of security activities, deliverables, and responsibilities at each phase of the SDLC.

1. Planning & Requirements

Security Activities:

• Conduct initial threat modeling
• Define security requirements (authentication, authorization, encryption, etc.)
• Identify compliance and regulatory requirements (GDPR, HIPAA, PCI-DSS, etc.)
• Assess data sensitivity and classification
• Define security acceptance criteria
• Estimate security effort and resources

Key Questions:

• What sensitive data will we handle?
• What are the regulatory requirements?
• What are the top security risks?
• What security controls are required?
• How will we know we’re secure enough?

Deliverables:

• Security requirements document
• Initial threat model
• Compliance checklist
• Data classification matrix
• Security acceptance criteria

Collaboration:

• Product managers and security work together on requirements
• Architects provide early input on security design
• Compliance team identifies regulatory needs

2. Design & Architecture

Security Activities:

• Detailed threat modeling using frameworks like STRIDE or PASTA
• Security architecture review and approval
• Design authentication and authorization flows
• Define trust boundaries and data flow diagrams
• Select security controls and frameworks
• Plan for secure configuration management
• Design security monitoring and logging

Key Questions:

• What are all possible attack vectors?
• Where are the trust boundaries?
• How will users authenticate and what will they be authorized to do?
• How will sensitive data be protected?
• What security frameworks/libraries will we use?
• How will we detect and respond to security incidents?

Deliverables:

• Threat model documentation
• Security architecture diagrams
• Authentication/authorization design
• Security control selection rationale
• Data flow diagrams with trust boundaries

Collaboration:

• Architects lead design with security team input
• Security team reviews and approves architecture
• Development team understands security architecture
• Operations plans monitoring and incident response

3. Development & Implementation

Security Activities:

• Follow secure coding standards (OWASP guidelines, language-specific best practices)
• Use IDE security plugins for real-time feedback
• Implement pre-commit hooks for secret detection
• Conduct security-focused code reviews
• Write security unit tests
• Integrate SAST (Static Application Security Testing) in CI pipeline
• Implement security controls as designed

Key Questions:

• Are we following secure coding standards?
• Are secrets properly managed (not hardcoded)?
• Are inputs validated and outputs encoded?
• Are security controls implemented correctly?
• Do we have tests for security functionality?

Deliverables:

• Secure code following standards
• Security unit tests with good coverage
• Code review records
• SAST scan results and remediation records
• Security controls implementation

Collaboration:

• Developers write secure code with automated tool feedback
• Security champions provide guidance to team
• Peer reviewers check for security issues
• Security team provides secure coding training

4. Testing & Quality Assurance

Security Activities:

• Run DAST (Dynamic Application Security Testing)
• Perform SCA (Software Composition Analysis) for dependency vulnerabilities
• Conduct penetration testing
• Test security controls (authentication, authorization, input validation)
• Perform security regression testing
• Test for OWASP Top 10 vulnerabilities
• Verify compliance with security requirements

Key Questions:

• Does the running application have vulnerabilities?
• Are our dependencies secure?
• Do security controls work as designed?
• Can we penetrate our own defenses?
• Have we tested all security requirements?

Deliverables:

• DAST and SCA scan results
• Penetration test reports
• Security test coverage metrics
• Vulnerability remediation records
• Security requirements verification

Collaboration:

• QA engineers execute security tests
• Automated scanners run continuously
• Security team conducts penetration testing
• Developers prioritize and fix findings

5. Deployment & Release

Security Activities:

• Secure configuration management
• Secrets management (rotate, never hardcode)
• Infrastructure security scanning
• Container image scanning
• Deployment security validation
• Security monitoring and alerting setup
• Security runbooks and incident response plans

Key Questions:

• Are all configurations secure?
• Are secrets properly managed?
• Are container images free of vulnerabilities?
• Is security monitoring in place?
• Do we have incident response plans?

Deliverables:

• Secure deployment scripts and configurations
• Configuration baselines
• Security monitoring dashboards
• Incident response runbooks
• Deployment security checklist

Collaboration:

• Operations ensures secure deployment
• Security team validates deployment security
• Developers provide security monitoring requirements
• SRE sets up monitoring and alerting

6. Operations & Maintenance

Security Activities:

• Continuous vulnerability scanning
• Security monitoring and alerting
• Incident response and remediation
• Patch management and updates
• Security log analysis
• Regular security assessments and audits
• Threat intelligence monitoring

Key Questions:

• Are new vulnerabilities affecting us?
• Are we being attacked?
• Are we compliant with security policies?
• Do we need to patch or update?
• What’s our current security posture?

Deliverables:

• Security monitoring reports
• Incident response records
• Patch management logs
• Periodic security assessment results
• Security posture dashboards

Collaboration:

• Operations monitors and maintains security
• Security team responds to incidents
• Developers deploy security patches quickly
• SRE maintains security infrastructure

Security Culture and Collaboration

Building a Security-Aware Culture

DevSecOps is as much about culture as it is about tools and processes. Creating a culture where security is valued and practiced requires intentional effort.

Security Training and Education

Developer Security Training:

Onboarding training:

• Secure coding fundamentals for all new developers
• Overview of security policies and standards
• Introduction to security tools and processes
• OWASP Top 10 awareness

Ongoing training:

• Regular security workshops and lunch-and-learns
• Secure coding bootcamps for specific technologies
• Participation in security CTFs (Capture the Flag) and challenges
• Security conference attendance and knowledge sharing

Role-specific training:

• Frontend developers: XSS, CSRF, client-side security
• Backend developers: SQL injection, authentication, authorization
• DevOps engineers: Infrastructure security, secrets management
• Architects: Threat modeling, security architecture

Hands-on learning:

• Internal security challenges
• Bug bounty programs (internal or external)
• Security code reviews as learning opportunities
• Pair programming with security champions

Security Champions Program

What it is: Identify and empower security champions within development teams. These are developers who have extra security training and advocate for security in their teams.

Benefits:

• Scales security expertise across the organization
• Security champions understand both development and security
• Reduces bottlenecks on security team
• Improves security outcomes through peer influence
• Builds security awareness organically

How to implement:

1. Identify champions:

• Volunteers interested in security
• Developers with natural security inclination
• Representation from each team

2. Provide advanced training:

• Deep-dive security training
• Threat modeling workshops
• Security tool training
• Access to security team for mentorship

3. Define responsibilities:

• First point of contact for security questions
• Lead security discussions in team meetings
• Review security-sensitive code changes
• Stay current on security trends
• Share knowledge with team

4. Support and empower:

• Regular security champion meetings
• Direct line to security team
• Time allocated for security activities
• Recognition for security contributions

5. Measure success:

• Security issues found and fixed by champions
• Security awareness in teams with champions
• Champion satisfaction and engagement

Blameless Security Culture

Blameless Incident Reviews:

When security incidents occur, focus on learning and improvement rather than blaming individuals.

Process:

1. Document what happened:
   • Timeline of events
   • Root cause analysis
   • Contributing factors
2. Ask “why” not “who”:
   • Why did the vulnerability exist?
   • Why wasn’t it caught earlier?
   • Why did detection take so long?
3. Identify systemic improvements:
   • What processes failed?
   • What tools could help?
   • What training is needed?
4. Share lessons learned:
   • Document findings
   • Share across organization
   • Update procedures and training

Benefits:

• Encourages reporting of security issues
• Focuses on systemic fixes, not individual blame
• Reduces fear of bringing up security concerns
• Improves security posture over time

Creating Psychological Safety:

• Reward developers for finding and reporting security issues
• Celebrate security improvements
• Never punish honest mistakes
• Encourage questions about security
• Make security concerns safe to raise

Collaboration Models

Embedded Security:

• Security engineers embedded in development teams
• Close collaboration on daily basis
• Security expertise readily available
• Better understanding of team context

Security as a Service:

• Central security team provides services to dev teams
• Self-service security tools and documentation
• Consultative relationship
• Security team focuses on high-value activities

Guild/Community of Practice:

• Security champions from different teams meet regularly
• Share knowledge and best practices
• Discuss security challenges and solutions
• Build community around security

Effective Communication

Making Security Accessible:

• Avoid security jargon when possible
• Explain security findings in developer terms
• Provide actionable remediation guidance
• Prioritize security issues clearly (critical vs. informational)

Positive Security Messaging:

• Frame security as enabling, not blocking
• “Here’s how to do it securely” instead of “you can’t do that”
• Celebrate security wins, not just failures
• Recognize teams with good security practices

Making Security Easy and Accessible

DevSecOps holds that security should be easy to do correctly. If secure practices are difficult or time-consuming, developers will find workarounds.

Provide Secure Defaults

Security-Hardened Templates:

• Pre-configured project templates with security baked in
• Secure framework configurations
• Authentication/authorization modules ready to use
• Standard security headers configured

Example secure defaults:

• Web frameworks with CSRF protection enabled
• API projects with authentication required by default
• Database connections using encrypted connections
• Logging configured to avoid logging sensitive data

Benefits:

• Developers start with security, not without it
• Reduces chance of misconfiguration
• Lowers cognitive load on developers
• Consistent security posture across projects

Paved Roads

What it is: Provide well-supported, easy-to-use paths for common development tasks that include security by default.

Examples:

• Standard CI/CD pipeline templates with security scanning
• Approved libraries and frameworks
• Standard deployment patterns
• Pre-configured infrastructure as code modules

Characteristics of good paved roads:

• Easy to use (easier than doing it yourself)
• Well-documented
• Maintained and supported
• Flexible enough for most use cases
• Security built in, not bolted on

Benefits:

• Developers naturally choose secure options
• Reduces security team workload
• Consistent security practices
• Faster development (reuse vs. build)

Self-Service Security

Empower developers to:

• Run security scans on-demand
• Access security documentation and training
• Request security reviews when needed
• Get answers to security questions

Self-service tools:

• Security scanning in CI/CD (automatic)
• Security dashboards showing current posture
• Documentation portal with secure coding guides
• Chatbot or FAQ for common security questions
• Security issue tracking with clear priorities

Benefits:

• Reduces waiting for security team
• Faster feedback and remediation
• Developers take ownership of security
• Security team focuses on complex issues

Reduce Friction

Automate security checks:

• Automated security scanning in CI/CD
• Pre-commit hooks catch issues before commit
• Automated dependency updates (Dependabot, Renovate)
• Automatic secret scanning

Provide fast feedback:

• Security scans complete in < 10 minutes
• Clear, actionable findings
• Links to remediation guidance
• Prioritized by severity

Integrate into existing workflows:

• Security tools in IDE (real-time feedback)
• Security checks in pull requests
• Security findings in issue tracker
• Security metrics in team dashboards

Don’t slow down development:

• Non-blocking security checks for low/medium issues
• Block only on critical/high security issues
• Option to override with justification
• Clear escalation path for urgent deployments

Celebrate Security Wins

Recognition:

• Recognize developers who find and fix vulnerabilities
• Highlight security improvements in team meetings
• Share success stories across the organization
• Security awards or acknowledgments

Gamification:

• Security scoreboards (in a positive way)
• Security challenges and CTFs
• Badges for security achievements
• Bug bounty programs (internal or external)

Make it visible:

• Security dashboards showing improvement
• Metrics on security debt reduction
• “Security Champion of the Month”
• Case studies of security successes

Security Gates and Scanning

Which Scanner Runs Where

Each class of scanner needs something different to exist before it can run, and that requirement decides its place in the pipeline more than any preference does.

Two placement rules follow from the table.

Scheduled re-scans matter as much as build-time scans, and only for some classes. SAST results change when the code changes. SCA results change when the world changes, because a dependency that was clean at build time acquires a published vulnerability later without anyone touching the repository. A pipeline that only scans dependencies on build will not notice, so dependency and image scanning need a recurring scan against what is already deployed.

DAST cannot gate a merge. It needs a running system and it takes too long, so treating it as a build gate either slows every change unacceptably or, more commonly, gets it quietly disabled. It belongs after deployment to a test environment, gating promotion rather than integration.

What each class finds, what it systematically misses, and how the classes overlap is a security testing topic in its own right. Know it before trusting a clean scan, because a scanner’s silence is only as meaningful as the class of defect it was ever able to see.

Security Gate Strategy

Pre-Commit Gates:

• Secret detection hooks
• Linting and formatting
• Fast local security checks

Pull Request Gates:

• SAST scanning
• Dependency scanning (SCA)
• Code review (including security review)
• Unit and integration tests

Main Branch Gates:

• DAST scanning (staging environment)
• Container image scanning
• IaC security scanning
• Comprehensive integration tests
• Performance and load tests

Pre-Production Gates:

• Final security validation
• Compliance checks
• Manual security review (for high-risk changes)
• Deployment smoke tests

Post-Deployment:

• Production smoke tests
• Runtime security monitoring
• Anomaly detection
• Continuous vulnerability scanning

Managing False Positives

Tune scanners:

• Configure tools for your tech stack
• Adjust severity thresholds
• Exclude test code from some scans

Triage and track:

• Review and categorize findings
• Document false positives
• Track technical debt for accepted risks

Continuous improvement:

• Regularly review scanner configuration
• Update rules and policies
• Share knowledge across teams

Secrets and Credential Management

What Are Secrets?

Secrets are sensitive pieces of information that grant access to systems, services, or data:

• API keys and tokens
• Database passwords
• Private keys and certificates
• OAuth client secrets
• Encryption keys
• Service account credentials

The Secrets Problem

Why secrets are challenging in CI/CD:

• Need to be available to pipelines but not exposed in code
• Different secrets for different environments
• Must be rotated regularly
• Need to be auditable
• Can’t be committed to version control

Secrets Management Best Practices

2. Use Dedicated Secrets Management Tools

Cloud Provider Solutions:

• AWS Secrets Manager
• Azure Key Vault
• Google Cloud Secret Manager
• Alibaba Cloud KMS

Third-Party Solutions:

• HashiCorp Vault
• 1Password Secrets Automation
• CyberArk Conjur
• Doppler

CI/CD Platform Built-In:

• GitHub Secrets
• GitLab CI/CD Variables
• CircleCI Contexts
• Jenkins Credentials

3. Rotate Secrets Regularly

• Automate rotation where possible
• Have a rotation schedule for all secrets
• Rotate immediately if exposure suspected
• Test rotation process regularly

4. Use Short-Lived Credentials

• Prefer temporary tokens over long-lived credentials
• Use IAM roles and service accounts where possible
• Implement just-in-time access
• Token TTL < 24 hours when possible

5. Apply Least Privilege

• Grant minimum necessary permissions
• Use separate credentials for different environments
• Regularly audit and revoke unused credentials
• Scope secrets to specific pipelines or stages

6. Encrypt Secrets at Rest and in Transit

• Use TLS for all network communication
• Encrypt secrets in configuration files
• Use encrypted storage for secrets
• Never log secrets in build output

Secrets in CI/CD Pipelines

Using CI/CD Platform Secrets:

GitHub Actions:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        env:
          API_KEY: ${{ secrets.API_KEY }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: ./deploy.sh

GitLab CI/CD:

deploy:
  script:
    - ./deploy.sh
  variables:
    API_KEY: $CI_API_KEY
    DB_PASSWORD: $DB_PASSWORD

Using External Secrets Manager:

Vault example:

deploy:
  script:
    - export VAULT_TOKEN=$(vault login -token-only)
    - vault kv get -field=password secret/db > db_password.txt
    - ./deploy.sh
  variables:
    VAULT_ADDR: "https://vault.example.com"

Injecting Secrets at Runtime:

• Fetch secrets at deployment time, not build time
• Use environment variables
• Mount secrets as files in containers
• Use cloud provider instance roles when possible

Example: Kubernetes Secrets:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password

Secrets in Different Environments

Development:

• Use local environment variables or .env files (not committed)
• Use mock credentials where possible
• Limited access to production secrets
• Developers should never need production secrets locally

CI/CD:

• Use CI/CD platform secret management
• Inject secrets as environment variables at runtime
• Never log secrets in build output
• Mask secrets in logs automatically

Staging:

• Use separate secrets from production
• Rotate regularly
• Similar access controls to production
• Can be less restrictive for debugging

Production:

• Use cloud provider secret management services
• Inject secrets at runtime, not build time
• Strict access controls
• Monitor and audit secret access
• Automatic rotation where possible

Secret Rotation Strategy

Automated Rotation:

• Cloud provider native rotation (AWS Secrets Manager, etc.)
• Custom scripts for unsupported services
• Schedule rotation (30-90 days)
• Test rotation process in staging first

Manual Rotation:

• Document rotation procedure
• Rotate on schedule
• Rotate on team member departure
• Rotate after suspected exposure

Zero-Downtime Rotation:

• Support multiple active secrets during rotation
• Gradual rollout of new secrets
• Verify new secret works before revoking old

Pipeline Hardening

Securing the Pipeline Infrastructure

1. Keep CI/CD Tools Updated

• Regular security patches
• Monitor CVE feeds for CI/CD tools
• Test updates in non-production first
• Automate update notifications

2. Access Control

• Use multi-factor authentication (MFA)
• Role-based access control (RBAC)
• Principle of least privilege
• Regular access audits
• Remove access for departed team members

3. Audit Logging

• Log all pipeline activities
• Log authentication and authorization events
• Log configuration changes
• Centralized log collection
• Retain logs per compliance requirements
• Alert on suspicious activities

4. Harden Build Agents/Runners

• Use minimal base images
• Regularly patch and update
• Isolate runners (containers, VMs)
• No persistent state between builds
• Network segmentation
• Monitor for anomalies

5. Restrict Pipeline Modifications

• Require code review for pipeline changes
• Separate pipeline configuration from application code (when appropriate)
• Use signed commits
• Protected branches for pipeline config
• Audit trail for all changes

Preventing Pipeline Manipulation

1. Validate Inputs

• Sanitize all external inputs to pipelines
• Validate webhooks and triggers
• Check parameter values
• Prevent command injection

2. Use Pipeline as Code

• Version control pipeline definitions
• Code review for pipeline changes
• Automated validation of pipeline config
• Treat pipelines like application code

3. Least Privilege for Pipelines

• Minimal permissions for service accounts
• Scope permissions to specific resources
• Different credentials for different stages
• No admin credentials in pipelines

4. Isolated Execution

• Run builds in isolated containers/VMs
• No network access unless required
• Clean workspace between builds
• Prevent cross-contamination between builds

5. Dependency Pinning

• Pin versions of build tools
• Pin versions of CI/CD plugins/actions
• Use checksums to verify integrity
• Review updates before adopting

Continuous Compliance

Policy as Code

What it is: Defining security and compliance policies as code that can be automatically enforced, versioned, and tested.

Benefits:

• Automated compliance checking
• Consistent policy enforcement
• Audit trails through version control
• Faster policy updates
• Self-service compliance validation
• Documentation as code

Tools:

• Open Policy Agent (OPA)
• HashiCorp Sentinel
• Cloud Custodian
• Chef InSpec
• AWS Config Rules

What to codify:

• Infrastructure security policies
• Access control policies
• Data retention policies
• Encryption requirements
• Network security rules
• Deployment approval requirements

Example OPA Policy:

package deployment.approval

# Require security team approval for production deployments
deny[msg] {
    input.environment == "production"
    not has_security_approval(input)
    msg := "Production deployments require security team approval"
}

has_security_approval(deployment) {
    some i
    deployment.approvals[i].team == "security"
}

Automated Compliance Checking

In CI/CD Pipeline:

• Validate infrastructure changes against policies
• Block non-compliant deployments
• Generate compliance reports automatically
• Fail builds on policy violations

Example GitLab CI:

compliance_check:
  stage: validate
  script:
    - opa test policies/
    - conftest test -p policies/ kubernetes/*.yaml
  allow_failure: false

Continuous Monitoring:

• Real-time security posture assessment
• Drift detection from compliance baselines
• Automated remediation of violations
• Alerting on policy violations

Tools for Continuous Compliance:

• AWS Config
• Azure Policy
• Google Cloud Security Command Center
• Prisma Cloud
• Lacework

Audit Trails and Documentation

What to Log:

• All code changes (git history)
• Pipeline executions and results
• Security scan findings
• Deployment activities
• Configuration changes
• Access and authentication events
• Approval and sign-off records

Log Retention:

• Follow regulatory requirements (GDPR, HIPAA, SOC 2, etc.)
• Typically 1-7 years depending on compliance framework
• Immutable logs (prevent tampering)
• Encrypted at rest and in transit

Compliance Documentation:

• Security architecture decisions
• Threat models
• Security controls implementation
• Vulnerability assessment results
• Incident response activities
• Policy documents
• Audit reports

Automated Evidence Collection:

• Screenshots of deployments
• Test result artifacts
• Security scan reports
• Deployment logs
• Change approval records

DevSecOps Metrics and Measurement

Key Metrics

Mean Time to Remediate (MTTR):

• How long from vulnerability discovery to fix deployed
• Measures speed of security response
• Track separately for different severity levels
• Goal: Minimize MTTR, especially for critical issues

Vulnerability Escape Rate:

• Percentage of vulnerabilities found in production vs. pre-production
• Measures effectiveness of shift-left security
• Goal: Most vulnerabilities found in dev/test, not production

Security Debt:

• Number of open security issues by severity
• Age of open security issues
• Trend over time (increasing or decreasing)
• Goal: Decreasing security debt over time

Test Coverage:

• Percentage of code covered by security tests
• Security requirements with automated tests
• Goal: High coverage of security-critical code

Security Scan Adoption:

• Percentage of projects with SAST enabled
• Percentage of projects with dependency scanning
• Percentage of pipelines with security gates
• Goal: 100% coverage for production systems

Developer Security Training:

• Percentage of developers with security training
• Frequency of security training
• Security awareness assessment scores
• Goal: All developers trained, regular refreshers

Security Champion Engagement:

• Number of active security champions
• Security champion activities (reviews, trainings, etc.)
• Developer satisfaction with security support
• Goal: Active champions in every team

Leading vs. Lagging Indicators

Leading Indicators (Predictive):

• Number of security scans run
• Developer security training completion
• Security issues found in development
• Security champion engagement

Lagging Indicators (Retrospective):

• Production security incidents
• Time to remediate vulnerabilities
• Vulnerabilities found in production
• Compliance audit results

Use both:

• Leading indicators help you improve proactively
• Lagging indicators show actual security outcomes
• Track trends over time to measure improvement

Avoiding Metric Pitfalls

Don’t:

• Use metrics punitively (creates fear and gaming)
• Focus only on quantity (encourage quality too)
• Compare teams publicly (creates competition, not collaboration)
• Set unrealistic targets (demotivates teams)

Do:

• Use metrics for learning and improvement
• Track trends, not just point-in-time values
• Celebrate improvements
• Involve teams in defining and tracking metrics
• Focus on outcomes, not just outputs

What Actually Determines Whether This Works

DevSecOps has more moving parts than most of the practices in this category, and teams tend to adopt them in the wrong order. Three things decide the outcome, and none of them is a tool.

The easy path has to be the secure one. Every control described here competes with a developer’s deadline, and controls that lose that competition get bypassed. Paved roads, secure defaults and self-service exist so that the secure option is also the fastest option, which is the only arrangement that survives pressure. A security programme built on asking people to do extra work is one bad quarter from collapsing.

Findings need an owner and a budget. Scanners produce findings faster than teams remediate them, so a programme that only adds scanning converts an unknown risk into a known and growing backlog. Deciding in advance what severity blocks a release, what gets scheduled, and what is accepted with a documented reason is what stops the backlog from becoming noise everyone ignores.

Blame ends the flow of information. The same dynamic that makes blameless post-mortems work applies more strongly to security, because the person best placed to report a mistake is usually the person who made it. Where reporting a leaked credential or a bad configuration has personal consequences, those things stop being reported and start being quietly worked around, and the programme loses exactly the signal it exists to collect.