Secure coding

What the control asks

Software development is to follow secure coding principles. Purpose: have software written securely so that it contains fewer potential security vulnerabilities. Guidance: put organization-wide governance of secure coding in place with a minimum secure baseline, extended to third-party components and open source, and use real-world threat monitoring and current vulnerability advice to keep improving the principles. Apply them to new code and to reuse, internally and in products and services supplied to others. Before coding, plan for: the organization's expectations and approved secure coding principles for in-house and outsourced code; the coding habits and defects that have commonly caused vulnerabilities in the past; configuring tools such as IDEs to help enforce secure code; following guidance from tool and runtime providers; keeping development tools such as compilers up to date; developers' qualification in secure coding; secure design and architecture, with threat modelling; secure coding standards, mandated where relevant; and controlled development environments. While coding, consider language-specific secure practices; techniques such as peer review, pair programming, refactoring, test-driven development and security-focused iterations; structured programming; documenting code and removing defects that could be exploited; and banning insecure design choices, for example passwords written into code, code samples nobody approved, or web services that require no authentication. Test during and after development (8.29), for instance with static application security testing. Before release, evaluate the attack surface and least privilege, and analyse the most common programming errors and record that they have been mitigated. After release, package and deploy updates securely; handle reported vulnerabilities (8.8); log errors and suspected attacks and review the logs to adjust code; and protect source code from unauthorized access and tampering with configuration management tools offering access and version control. For external tools and libraries, keep an inventory with versions and update them in line with releases; select, authorize and reuse well-vetted components, especially for authentication and cryptography; weigh their licence, security and history; ensure software is maintainable, tracked and from proven, reputable sources; and ensure development resources and artefacts remain available long enough. When modifying a software package, consider the risk to built-in controls and integrity processes, whether vendor consent is needed, whether the vendor could supply the change as a standard update, the impact of taking over future maintenance, and compatibility with other software. Other information: security-relevant code should be invoked when needed and be tamper-resistant; interpreted code keeps this property only on servers users cannot reach, with administrator access protected by just-in-time administration and strong authentication and directory browsing disabled; code should assume it will be attacked, critical applications can check outputs against safe bounds with simple verifiable code, web applications are prone to injection and cross-site scripting; ISO/IEC 15408 covers security evaluation.

Purpose in the standard’s terms, in our words: Ensures software is written securely, reducing potential vulnerabilities.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Application security, System and network security; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• Secure coding standards and a minimum baseline applying to in-house and outsourced development, updated from current threat and vulnerability information
• IDE and pipeline configuration enforcing secure coding checks, including SAST results and remediation records
• Threat models and peer review records for significant changes
• Pre-release records of attack surface review and mitigation of common programming errors
• A software component inventory (libraries and versions) with vetting, licence and update records
• Developer secure coding training or qualification records

Where audits commonly find gaps

• Hard-coded credentials and secrets appear in source code
• Open source libraries are pulled in without inventory or update tracking
• SAST findings are ignored or suppressed without review
• Vendor packages are modified locally with no assessment of future maintenance impact

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. It is one of the eleven controls added in the 2022 edition, so a register carried over from the previous edition may have no row for it.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.18 Use of privileged utility programs
• 8.25 Secure development life cycle
• 8.26 Application security requirements

Read the five attributes All 93 controls