Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.25 — Secure Development Life Cycle

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.25 ISO 27001ISO 27002BSI CON.8

The new web application passes all functional tests and goes live on schedule. Two weeks later, a penetration test reveals SQL injection, insecure direct object references and missing rate limiting. Fixing these issues in production takes three sprints — more than building them correctly would have taken. A.8.25 requires that security is designed and implemented within the development lifecycle, from specification through deployment.

Retrofitting security is expensive, disruptive and often incomplete. This control demands that organizations integrate security into every phase of the development process — requirements, design, implementation, testing and deployment.

What does the standard require?

  • Establish secure development rules. Define policies and procedures for secure development that apply to all software produced by or for the organization.
  • Separate environments. Development, testing and production environments must be separated with controlled promotion between them.
  • Integrate security into each phase. Security requirements during specification, threat modelling during design, secure coding during implementation, security testing before deployment.
  • Train developers. Ensure developers have the skills to identify and prevent common vulnerabilities.
  • Extend to outsourced development. When development is outsourced, the same security standards apply and must be contractually enforced.

In practice

Define a secure SDLC. Document your development process with security activities at each stage: threat modelling in design, secure coding standards during implementation, SAST/DAST in the pipeline, manual penetration testing before major releases.

Implement security gates in the pipeline. Configure your CI/CD pipeline to block deployments that fail security checks. A critical SAST finding or a known-vulnerable dependency should prevent the build from reaching production.

Conduct threat modelling for new features. Before writing code, analyse the feature for potential threats using STRIDE, PASTA or another threat modelling methodology. Document threats, mitigations and residual risks.

Provide developer security training. Regular training on the OWASP Top 10, secure coding practices for your technology stack and hands-on workshops. Measure effectiveness through code review metrics and vulnerability trends.

Typical audit evidence

Auditors typically expect the following evidence for A.8.25:

  • Secure development policy — documented SDLC with security activities at each phase (see Secure Software Development Policy in the Starter Kit)
  • CI/CD pipeline configuration — evidence of automated security gates
  • Threat model documentation — threat models for critical applications
  • Developer training records — evidence of security training
  • Environment separation evidence — proof that dev, test and production are separated

KPI

Percentage of development projects following the secure development lifecycle

Measured as a percentage: how many active development projects have documented compliance with the secure SDLC? Target: 100%.

Supplementary KPIs:

  • Percentage of deployments that pass all automated security gates
  • Number of vulnerabilities found in production vs. pre-production (target: decreasing ratio)
  • Percentage of developers who completed security training in the last 12 months

BSI IT-Grundschutz

A.8.25 maps to BSI modules for software development:

  • CON.8 (Software Development) — the core module. Requires a documented development process with integrated security measures, environment separation and secure coding practices.
  • APP.7 (Development of Individual Software) — additional requirements for custom-developed applications.
  • CON.10 (Developing Web Applications) — specific security requirements for web application development.

Sources

Frequently asked questions

Does A.8.25 apply if we only use commercial off-the-shelf software?

If you develop any software, scripts, integrations or configuration-as-code, A.8.25 applies. Even organizations that primarily use COTS software usually have some in-house development (macros, scripts, integrations) that should follow a secure development process.

What does 'security by design' mean in practice?

It means considering security requirements from the earliest design phase — threat modelling during architecture, security requirements alongside functional requirements, and security testing as part of the definition of done. Security added retroactively costs 10-100x more than security built in.

How does this relate to DevSecOps?

DevSecOps is the practical implementation of A.8.25 in agile and CI/CD environments. It shifts security left by integrating SAST, DAST, SCA and security reviews into the development pipeline.