How to Stop Vulnerabilities Entering Your Code in the First Place
ISO 27001 Control 8.28 Secure coding is about one thing:
Don’t let security bugs into the codebase in the first place – and if they do get in, find and fix them quickly and repeatably.
Most successful attacks exploit coding flaws: injections, XSS, broken auth, insecure deserialisation, unsafe libraries, and so on. This control expects you to treat secure coding as normal engineering practice, not a special activity you do once a year before a pen test.
It ties directly into:
- your secure development life cycle (Control 8.25)
- your application security requirements (Control 8.26)
- and your architecture and engineering principles (Control 8.27)
This guide explains what ISO 27001 Control 8.28 really expects and how to turn “secure coding” from a slogan into something your developers can actually follow.
What ISO 27001 Control 8.28 Actually Requires
In plain English, ISO 27001 Control 8.28 – Secure coding expects you to:
- Define secure coding rules and standards that apply to your developers and suppliers.
- Build those rules into your day-to-day development practices (not just documents).
- Use tools (SAST, dependency scanning, etc.) to find and fix security issues in code.
- Manage third-party and open-source components in a controlled way.
- Train developers and keep them up to date with common vulnerabilities and secure patterns.
- Maintain and patch live code so it doesn’t slowly become insecure over time.
An auditor will want to see that secure coding is:
- documented,
- embedded in your SDLC and pipelines, and
- visible in how you handle vulnerabilities and third-party code.
Step 1 – Set Clear Secure Coding Standards and Governance
Start by defining how secure coding is done here.
Your secure coding standards should cover:
- Scope and expectations
- Which languages, frameworks and platforms you use.
- Which projects and teams must follow the secure coding standard (hint: all that handle important data or business processes).
- Reference frameworks
- Use well-known guidance such as OWASP for web, APIs and mobile.
- Map your internal rules to common vulnerability categories (e.g. injection, XSS, auth, access control, cryptography).
- Baseline rules for all code
- Input validation and output encoding.
- Authentication and session management.
- Authorisation checks in the right place (server-side, not just in the UI).
- Error handling and logging patterns.
- How secrets and configuration are handled.
- Approval and ownership
- Who maintains the secure coding standard (e.g. security + lead engineers).
- How often it’s reviewed and updated.
This gives you a solid, documented basis to show compliance with ISO 27001 Control 8.28 – and something concrete for developers to follow.
Step 2 – Build Secure Coding into the Day-to-Day Development Process
Secure coding doesn’t work if it’s just a PDF on a share. It has to show up in how people actually work.
Practical ways to embed it:
- Definition of Done
- Include security in your DoD: code reviewed, tests passing, no high-severity security findings, no secrets in commits, etc.
- Code review expectations
- Every pull/merge request includes at least one peer review.
- Reviewers explicitly look for common security issues (auth, access control, input handling, logging, secrets).
- Standard templates and patterns
- Provide sample code, snippets and templates that demonstrate secure patterns (e.g. secure login flow, safe DB access, standard error handling).
- IDE and build tooling
- Configure linters and static analysers locally where possible, so developers see issues early.
This is how you turn secure coding from “extra work” into the normal way we write code.
Step 3 – Apply Core Secure Coding Practices
Within that framework, developers should consistently follow a set of practical secure coding practices.
Key areas:
Input validation and output encoding
- Validate all input on the server side (length, type, pattern, allowed values).
- Use parameterised queries to prevent SQL and other injection attacks.
- Encode output correctly for its context (HTML, JSON, XML, logs).
Authentication and session management
- Use central, well-tested auth components where possible (SSO, identity provider).
- Never roll your own password storage or crypto.
- Implement secure cookies, session timeouts and re-authentication for sensitive actions.
Authorisation and access control
- Enforce checks server-side on every sensitive operation.
- Avoid “security by URL” or assuming anything from the client is trustworthy.
- Apply least privilege at user and role level.
Error handling and logging
- Don’t expose stack traces, SQL statements or internal identifiers in error responses.
- Use structured logging for security-relevant events without leaking sensitive data.
Secrets and configuration
- No hard-coded passwords, keys or tokens in source code.
- Use a secrets manager or secure configuration store.
- Scan commits and repos for accidental secrets.
Memory and resource safety (where relevant)
- In lower-level languages, avoid unsafe functions and patterns known to cause buffer overflows or memory corruption.
- Use safer library functions and patterns endorsed by your secure coding standard.
These are the habits that drastically reduce the number of vulnerabilities that ever make it to production.
Step 4 – Use Security Testing Tools as Part of the Pipeline
Secure coding is about people and tools. ISO 27001 Control 8.28 expects you to use the tools sensibly, not just run them once a year.
Consider:
- Static Application Security Testing (SAST)
- Analyse source code or compiled artefacts for security issues.
- Run in CI so new issues are caught on every build or at least every merge into main branches.
- Dependency and software composition analysis (SCA)
- Automatically identify vulnerable libraries and frameworks.
- Block or warn on builds that include critical vulnerabilities.
- Dynamic testing (DAST, IAST, fuzzing)
- For web or API services, run dynamic scanners against deployed test environments.
- Use fuzzing where input parsing is complex or critical.
- Automated checks in CI/CD
- Treat “no critical security findings” as a pipeline gate for releases.
- Ensure critical issues are tracked in your issue tracker and prioritised based on risk.
The point is not to eliminate all findings forever, but to show you have a consistent process to identify, triage and fix issues as part of normal development.
Step 5 – Manage Vulnerabilities and Secure Code Maintenance
Bugs happen. ISO 27001 Control 8.28 cares about how you handle them.
You should have:
- A clear process for security issues
- How vulnerabilities are reported (internally, externally).
- How they are recorded, assessed for impact and prioritised.
- Patch and update routines
- Regular updates for frameworks, libraries and runtime platforms.
- Defined SLAs for fixing high and critical issues.
- Post-incident learning
- When a security defect is found in code, capture the root cause.
- Update coding standards, patterns, and training so the same issue is less likely to reappear.
- Secure decommissioning
- When code is retired, ensure that repositories, credentials and infrastructure are cleaned up and access removed.
This turns secure coding from a one-time activity into an ongoing practice throughout the code’s life.
Step 6 – Control Third-Party and Open-Source Components
Modern applications rely heavily on external libraries and services. That’s a major focus for ISO 27001 Control 8.28.
You should:
- Maintain a dependency inventory
- Know which libraries, versions and licences you’re using across your applications.
- Use trustworthy sources
- Only pull libraries from official or approved repositories.
- Avoid random code copied from forums and blogs without validation.
- Scan and update regularly
- Use SCA tools to spot known vulnerabilities.
- Plan regular dependency updates, not just emergency fixes.
- Set rules around critical components
- Extra rigour around auth, crypto and security-related libraries.
- Prefer well-maintained, widely used components with a good track record.
This is how you reduce the risk of supply chain attacks and vulnerable dependencies quietly undermining your secure coding efforts.
Step 7 – Train and Support Developers in Secure Coding
Developers are at the heart of Control 8.28. They need practical, ongoing support, not just a one-off “security awareness” session.
Good practice:
- Role-specific training
- Focus on what matters to your stack: OWASP Top 10 for web, secure APIs, mobile app security, etc.
- Include real examples from your own codebase (sanitised as needed).
- Security champions
- Nominate developers in each team as “go-to” people for security questions.
- Involve them in reviews, tooling decisions and standard updates.
- Just-in-time learning
- Link static analysis findings and code review comments to short examples or docs explaining the issue and how to avoid it next time.
- Feedback loops
- Use lessons from incidents and pen tests to update training content and standards.
The aim is that secure coding becomes part of the craft of development in your organisation, not a compliance chore.
Quick Implementation Checklist for ISO 27001 Control 8.28
Use this to gauge where you stand on secure coding:
- ISO 27001 Control 8.28 (Secure coding) is covered in a documented secure coding standard or equivalent guidance.
- Secure coding expectations are embedded into the SDLC (definition of done, stories, reviews) rather than treated as a separate bolt-on.
- Developers follow core secure coding practices (input validation, output encoding, safe auth/access control, secure logging, secrets management).
- Code is subject to peer review with an explicit security focus.
- Security testing tools (SAST, SCA, and where appropriate DAST/IAST/fuzzing) are integrated into CI/CD pipelines.
- There is a defined process for handling discovered vulnerabilities, including prioritisation and remediation SLAs.
- Third-party and open-source components are tracked, scanned and updated as part of normal development.
- Developers and engineers receive regular, practical secure coding training relevant to your tech stack.
- Secure coding practices apply equally to in-house and outsourced development (and are reflected in contracts).
- Secure coding standards and tooling are reviewed and improved based on new threats, incidents and lessons learned.
Bringing It All Together
ISO 27001 Control 8.28 – Secure coding – is about making sure your codebase isn’t quietly undoing the rest of your security work.
If you:
- Define clear secure coding standards,
- Embed them into normal development, review and pipeline practices,
- Manage vulnerabilities and third-party components properly, and
- Support developers with the right tools and training,
you’ll dramatically reduce the number of exploitable flaws that ever reach production – and you’ll have strong, practical evidence that secure coding is a real, living control in your ISMS, not just a box ticked on a policy.
Explore the ISO 27001 Control Group Purposes