Most application vulnerabilities are not sophisticated. They are basic coding mistakes repeated at scale. Over my 30 years in governance, risk, and compliance, I have seen far too many businesses spend fortunes on firewalls and penetration testing while their development teams write hardcoded passwords, ignore input validation, and copy-paste unvetted code into production. Fixing code bugs after launch is painful. Writing secure code from line one is smart engineering.
ISO 27001:2022 introduced Annex A 8.28 as a dedicated control to eliminate this exact problem. It ensures your organisation applies secure coding principles consistently across in-house, outsourced, and open-source software, stopping vulnerabilities at the point they are created.
Quick Summary: What ISO 27001 Annex A 8.28 Requires
At a practical level, Annex A 8.28 is about how code is written, not just how it is tested. It is a new control in the 2022 standard that reflects how often modern breaches originate directly inside application code. Here is what you need to do in plain English:
- Establish Secure Coding Baseline Standards: Define documented secure coding rules tailored to your technology stack.
- Eliminate Unsafe Coding Practices: Ban hardcoded credentials, deprecated libraries, and unvalidated user inputs completely.
- Govern Open-Source and Reused Code: Review and track all third-party software libraries and dependencies before integration.
- Automate Developer Security Tools: Use IDE plugins and static analysis tools to catch coding errors in real time.
- Protect Source Code Repositories: Lock down repository access rights and protect security-critical code logic from tampering.
- Maintain Code Post-Deployment: Keep software updated and apply controlled security patches promptly after launch.
Why Poor Coding Practices Are a Major Security Risk
When developers prioritise delivery speed over secure coding principles, they introduce flaws that bypass standard perimeter defences. Attackers actively scan for these predictable coding mistakes because they provide direct access to your databases and servers.
Ignoring secure coding practices exposes your business to several critical hazards:
- Injection Attacks: Failure to validate inputs allowing attackers to run malicious commands against your databases (SQLi) or users (XSS).
- Hardcoded Credentials: Storing admin passwords, API keys, or encryption tokens directly inside public or internal source code.
- Supply Chain Breaches: Importing infected or vulnerable open-source packages into your core applications.
- Remote Code Execution: Unsafe object deserialisation or memory handling allowing hackers to hijack your servers.
My 12 Step Plan to Implement Annex A 8.28 Fast
You do not need your developers to become deep security researchers to satisfy an auditor. Here is my pragmatic, 12-step plan to embed audit-ready secure coding across your engineering team.
1. Define Clear Secure Coding Principles
Establish written secure coding guidelines that cover all software development across your business. Ensure standards apply to:
- In-house custom software development.
- Third-party outsourced code and contractor deliverables (Annex A 8.30).
- Open-source software components and frameworks.
2. Tailor Standards to Specific Languages and Frameworks
Generic security guidelines fail in practice. Adapt your secure coding rules to match the exact programming languages and tools your team uses:
- Define language-specific security rules (e.g., memory safety in C/C++, parameterised queries in SQL, input sanitisation in JavaScript).
- Provide specific guidance for your modern web, mobile, or cloud frameworks.
- Update language standards as new framework versions are introduced.
3. Prohibit Known Dangerous Coding Mistakes
Explicitly ban common, high-risk coding habits across your development team. Ensure your guidelines prohibit:
- Hardcoded credentials, API keys, passwords, or secret tokens.
- Direct concatenation of raw user inputs into database queries or command line calls.
- The use of deprecated, unmaintained, or unsafe functions and libraries.
4. Address Top Vulnerability Patterns
Focus developer training and guidelines on stopping the most frequent causes of software breaches, such as the OWASP Top 10:
- Enforce strict server-side input validation and output encoding.
- Implement robust, secure authentication and session management logic (Annex A 8.5).
- Handle application errors gracefully without leaking raw stack traces or system details to end users.
5. Govern Open-Source and Third-Party Code
Your application is only as secure as its weakest third-party library. Manage software supply chain risk tightly:
- Maintain a Software Bill of Materials (SBOM) listing all third-party libraries and dependencies.
- Scan external packages for known vulnerabilities before importing them into your builds.
- Monitor dependencies continuously for newly disclosed security flaws.
6. Deploy Automated Developer Security Tools
Support your engineering team by catching insecure coding patterns automatically while code is being written:
- Equip developers with Static Application Security Testing (SAST) plugins directly inside their IDEs.
- Embed automated code scanning tools into your continuous integration and deployment (CI/CD) pipelines.
- Configure build tools to block deployments automatically if high-risk vulnerabilities are detected.
7. Adopt Defensive Programming Techniques
Encourage structured coding methods that inherently lower error rates and improve overall code quality:
- Use peer code reviews or pair programming for all pull requests touching security-critical functions.
- Adopt defensive coding principles that assume all external data inputs are untrusted by default.
- Write comprehensive automated unit tests that include security edge cases and boundary checks.
8. Keep Code Clean and Remove Unused Logic
Bloated, unmaintained code accumulates hidden vulnerabilities over time. Maintain clean codebase discipline:
- Remove dead code, unused functions, and temporary testing endpoints before pushing to production.
- Document code logic clearly so future developers understand the security context.
- Refactor legacy code modules to replace insecure historical patterns with modern equivalents.
9. Conduct Security-Focused Code Reviews
Functional testing proves that code works; security reviews prove that code cannot be abused. Build security reviews into sign-offs:
- Conduct mandatory peer reviews for changes affecting authentication, cryptography, or access controls.
- Use automated static analysis results as a baseline requirement before manual code review.
- Verify that identified coding defects are remediated prior to staging deployment (Annex A 8.29).
10. Lock Down Security-Critical Code
Code that handles sensitive functions like encryption, payment processing, or user authentication requires extra protection:
- Isolate security-critical modules so they cannot be easily bypassed or tampered with.
- Obfuscate or compile sensitive client-side application logic where appropriate.
- Restrict code modification permissions on core security modules to senior engineering leads.
11. Maintain Secure Repository Access Controls
Source code is a primary corporate asset. Protect your repositories from unauthorised access and modification:
- Enforce strong multi-factor authentication and role-based access across all code repositories.
- Require branch protection rules that mandate approval before merging code into main branches.
- Audit access logs regularly to remove former employees or inactive contractor accounts immediately.
12. Establish Secure Post-Launch Maintenance
Secure coding does not end when software goes live. Maintain long-term code health through controlled maintenance:
- Patch newly discovered vulnerabilities in production libraries promptly using formal change controls (Annex A 8.32).
- Maintain secure update procedures for releasing software patches to users.
- Conduct periodic re-scans of live code repositories against updated threat intelligence lists.
Common Implementation Pitfalls and How to Fix Them
When preparing clients for ISO 27001 audits, I frequently spot the same secure coding mistakes. Here are the main traps and how to solve them:
- Problem: Relying Entirely on Penetration Tests to Find Coding Bugs
Ninja Solution: Catch vulnerabilities early by enforcing secure coding standards and static analysis during development. - Problem: Developers Unaware of Secure Coding Guidelines
Ninja Solution: Provide concise, language-specific cheat sheets and integrate automated scanning directly into their daily workflow. - Problem: Unchecked Third-Party Open-Source Libraries Brought In Freely
Ninja Solution: Implement automated software composition analysis (SCA) tools to scan dependencies on every build. - Problem: API Keys and Secrets Committed to Public Repositories
Ninja Solution: Use automated secret-scanning tools in git hooks to block commits containing plain-text keys.
The ISO 27001 Ninja Bottom Line
ISO 27001 Annex A 8.28 is about stopping vulnerabilities at their absolute source. Attackers continuously scan software looking for predictable human errors. By defining clear standards, training developers, automating code scans, and keeping third-party libraries updated, you stop making those predictable mistakes.
You do not need to slow down product delivery to write secure code. By embedding security directly into your engineering habits and build pipelines, you ship high-quality features fast while keeping your applications, customer data, and business completely secure.