Secure development life cycle

What the requirement asks

The organization is to set and apply rules for developing software and systems securely. Purpose: have security designed and built in as software and systems are developed. Guidance: secure development is the basis to produce secure services, architectures, software and systems, so consider: keeping development, test and production environments separate (8.31); guidance on security in the development life cycle, covering security in the development methodology (8.27, 8.28) and secure coding guidelines for every programming language used (8.28); security requirements at specification and design (5.8); security checkpoints within projects (5.8); testing of the system and its security, for example regression tests, code scans and penetration tests (8.29); protected repositories holding code and configuration (8.4, 8.9); security in version control (8.32); the application security knowledge and training required (8.28); developers' ability to prevent, find and fix vulnerabilities (8.28); and licensing requirements and alternatives that keep solutions cost-effective and avoid later licensing problems (5.32). Where development is outsourced, obtain assurance that the supplier follows the organization's secure development rules (8.30). Other information: development also happens inside applications such as office tools, scripts, browsers and databases. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Secure development starts with the lifecycle. The guidance asks for the gates, the roles, the training and the evidence on a real release.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep documented secure development rules or SDLC standard covering environments, methodology, coding guidelines, security requirements, checkpoints, testing, repositories and version control and one live sample together.

Evidence an assessor asks for

• Secure SDLCDocumented secure development rules or SDLC standard covering environments, methodology, coding guidelines, security requirements, checkpoints, testing, repositories and version control
• Secure SDLCSecure coding guidelines for each language in use
• Secure SDLCProject records showing security checkpoints or gates passed
• Secure SDLCSecurity testing outputs such as static analysis, regression and penetration test results
• Secure SDLCDeveloper security training records and competence expectations
• Secure SDLCEvidence of assurance that outsourced developers follow the rules, and of licence checks on components

The question an assessor will ask

An assessor will ask for documented secure development rules or SDLC standard covering environments, methodology, coding guidelines, security requirements, checkpoints, testing, repositories and version control, then trace it to the system it protects. For A.8.25 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• The SDLC standard exists but projects skip the security gates under schedule pressure
• Coding guidelines cover only one language while several are used
• Low-code, scripting and spreadsheet development fall outside the rules
• Outsourced development is accepted without any evidence of secure practices

Before the next audit

Before the next audit, check one live sample for this gap: the sdlc standard exists but projects skip the security gates under schedule pressure.