The ultimate audit guide to ISO 27001 Annex A 8.28 Secure Coding
Table of contents
- 1. Verify the Secure Coding Governance and Policy
- 2. Evidence Developer Competency and Security Training
- 3. Validate Static Application Security Testing (SAST) Integration
- 4. Confirm Third-Party Library and Dependency Vetting
- 5. Ensure Secure Handling of Sensitive Data in Code
- 6. Evidence a Peer Code Review Security Focus
- 7. Ensure the Use of Proven Cryptographic Libraries
- 8. Review Application Error Handling and Information Leakage
- 9. Confirm Developer Local Environment Security
- 10. Ensure Periodic In-Depth Penetration Testing is Recorded
1. Verify the Secure Coding Governance and Policy
Verification Criteria: A formalised secure coding policy exists that mandates the use of specific security standards (e.g., OWASP, CERT, or MISRA) across all development projects.
Required Evidence: Approved Secure Coding Policy or Developer Handbook with explicit version control and management authorisation.
Pass/Fail Test: If the organisation cannot produce a documented standard defining mandatory secure coding practices for its technology stack, mark as Non-Compliant.
2. Evidence Developer Competency and Security Training
Verification Criteria: All personnel involved in writing or reviewing code have received documented training on secure coding techniques and the identification of common vulnerabilities.
Required Evidence: Training completion logs, certificates, or workshop attendance records dated within the last 12 months.
Pass/Fail Test: If active developers have not undergone secure coding training relative to their specific language (e.g., Java, Python, C#), mark as Non-Compliant.
3. Validate Static Application Security Testing (SAST) Integration
Verification Criteria: Automated SAST tools are integrated into the development lifecycle to scan source code for vulnerabilities prior to compilation or deployment.
Required Evidence: Scan reports from tools like SonarQube, Snyk, or Checkmarx showing identified flaws and remediation status.
Pass/Fail Test: If source code is promoted to a production-ready branch without an automated SAST scan being executed, mark as Non-Compliant.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Confirm Third-Party Library and Dependency Vetting
Verification Criteria: Technical mechanisms (Software Composition Analysis – SCA) are utilised to identify and manage security risks in third-party libraries and open-source components.
Required Evidence: Dependency scan logs or a Software Bill of Materials (SBOM) showing no active “Critical” or “High” severity vulnerabilities.
Pass/Fail Test: If the organisation cannot produce an inventory of third-party libraries or if production code contains unmitigated “Critical” CVEs in dependencies, mark as Non-Compliant.
5. Ensure Secure Handling of Sensitive Data in Code
Verification Criteria: Source code is free from hardcoded secrets, API keys, credentials, or plain-text PII.
Required Evidence: Secret-scanning tool logs (e.g., GitHub Secret Scanning or TruffleHog) showing zero active high-risk secrets in repositories.
Pass/Fail Test: If a manual or automated check identifies an active API key or database password hardcoded in the repository, mark as Non-Compliant.
6. Evidence a Peer Code Review Security Focus
Verification Criteria: A mandatory peer review process is enforced where security-specific checks (e.g., input sanitisation, output encoding) are documented as part of the approval.
Required Evidence: Pull Request (PR) logs or code review checklists showing explicit sign-off on security considerations by an independent reviewer.
Pass/Fail Test: If code can be merged into a production-ready branch without a documented security-focused review by someone other than the author, mark as Non-Compliant.
7. Ensure the Use of Proven Cryptographic Libraries
Verification Criteria: The organisation mandates the use of industry-standard, well-vetted cryptographic libraries rather than custom-developed or deprecated encryption methods.
Required Evidence: Code review of cryptographic modules or architectural standards citing the use of libraries like OpenSSL, Bouncy Castle, or native cloud KMS APIs.
Pass/Fail Test: If the codebase identifies “home-grown” encryption algorithms or deprecated protocols (e.g., MD5 for hashing passwords), mark as Non-Compliant.
8. Review Application Error Handling and Information Leakage
Verification Criteria: Code is engineered to handle errors gracefully, ensuring that stack traces or sensitive system information are never revealed in public-facing error messages.
Required Evidence: Exception handling code blocks or UI screenshots showing generic “Internal Error” messages for failed requests.
Pass/Fail Test: If an application in production reveals database schema details or server file paths within a browser-based error message, mark as Non-Compliant.
9. Confirm Developer Local Environment Security
Verification Criteria: Local development environments (IDEs/Workstations) are hardened and restricted to prevent the unauthorised extraction of source code or ingress of malware.
Required Evidence: Endpoint management (MDM) reports confirming disk encryption and AV/EDR presence on all developer machines.
Pass/Fail Test: If a developer workstation lacks full disk encryption or active real-time malware protection, mark as Non-Compliant.
10. Ensure Periodic In-Depth Penetration Testing is Recorded
Verification Criteria: Dynamic testing (DAST or Pentesting) is conducted at regular intervals to verify that secure coding practices have effectively mitigated runtime vulnerabilities.
Required Evidence: Signed Penetration Test reports and a corresponding Remediation Log showing closure of high-risk findings.
Pass/Fail Test: If the application has not undergone a formal security test following its last major architectural change or within the last 12 months, mark as Non-Compliant.
About the author
