Skip to main content

Pro audit program · v1.0

Secure SDLC Maturity

Are security activities baked into the development lifecycle, or are they bolted on at the end? A focused maturity snapshot.

  • General target area
  • OWASP SAMM / NIST SSDF framework
  • 6 controls in this program
  • Cyentrix Cyentrix Trusted Author
Sign in to run → Back to library

About this program

Are security activities baked into the development lifecycle, or are they bolted on at the end? A focused maturity snapshot.

Risks addressed

  • High Security review only at the very end u2014 costly rework
  • High No threat modelling for high-risk features
  • High Production hot-fixes bypass review entirely

Controls (6)

  1. Documented secure SDLC policy

    High

    A documented secure Software Development Lifecycle (SDLC) policy establishes the organization's formal requirements, processes, and controls for integrating security throughout all phases of software development—from requirements gathering and design through coding, testing, deployment, and maintenance. This policy defines roles and…

    How to test + evidence

    Testing procedure: A short policy maps security activities to dev phases (design, code, test, deploy).

    Evidence to collect: Policy document.

  2. Threat modelling for high-risk changes

    High

    Threat modelling for high-risk changes requires organizations to conduct structured threat analysis before deploying architectural modifications, new externally-facing services, privileged access expansions, or changes to authentication/authorization mechanisms. The process applies frameworks such as STRIDE, PASTA, or attack trees to identify…

    How to test + evidence

    Testing procedure: New features with auth / data sensitivity have a recorded threat model.

    Evidence to collect: Threat-model samples.

  3. Security training for developers (annual)

    Medium

    This control requires that software developers, engineers, and other personnel who write, review, or maintain application code complete annual security training focused on secure coding practices, common vulnerabilities, and secure development lifecycle principles. Training typically covers topics such as OWASP…

    How to test + evidence

    Testing procedure: Annual secure-coding training tied to top OWASP categories.

    Evidence to collect: Training records.

  4. Code review gates security findings

    High

    This control enforces automated quality gates within the code review process that block merge or deployment when security vulnerabilities, insecure coding patterns, or policy violations exceed defined thresholds. Static application security testing (SAST), software composition analysis (SCA), or similar tooling…

    How to test + evidence

    Testing procedure: PR review explicitly flags security-impacting changes; security team optional reviewer.

    Evidence to collect: PR template + sample.

  5. Production change requires approved PR + tests

    Critical

    This control ensures all code or configuration changes deployed to production environments must pass through a pull request (PR) approval process and automated testing before merge and deployment. The PR workflow requires peer review from authorized personnel, and automated tests…

    How to test + evidence

    Testing procedure: No direct prod commits; all changes go via the same review + CI gate.

    Evidence to collect: Branch protection settings.

  6. Bug-bounty or responsible-disclosure channel

    Medium

    A bug-bounty or responsible-disclosure channel provides external security researchers with a documented, safe method to report vulnerabilities in the organization's systems, applications, or services without fear of legal retaliation. This typically includes a public security.txt file, a dedicated email address…

    How to test + evidence

    Testing procedure: security.txt / disclosure email published; intake workflow defined.

    Evidence to collect: security.txt + intake log.