Secure coding

What the requirement 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. 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 coding is a practice with evidence. The guidance asks for the standard, the review, the tool and the fix.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep secure coding standards and a minimum baseline applying to in-house and outsourced development, updated from current threat and vulnerability information and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for secure coding standards and a minimum baseline applying to in-house and outsourced development, updated from current threat and vulnerability information, then trace it to the system it protects. For A.8.28 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: hard-coded credentials and secrets appear in source code.