Key takeaways
- Apply secure coding principles to software development.
- Secure coding avoids common flaws like injection and broken authentication.
- Start here: adopt secure coding guidelines for your languages.
Purpose
Apply secure coding principles to software development.
Requirement
Requirement summarySecure coding principles shall be applied to software development.
Why it matters
Secure coding avoids common flaws like injection and broken authentication.
How to implement
- Adopt secure coding guidelines for your languages.
- Use static analysis and dependency scanning.
- Review code for security issues.
- Manage third-party libraries and keep them updated.
What evidence you need to provide
Here is what you will typically need to provide for Annex A 8.28. It does not matter which system it lives in: a document, screenshot or export is fine.
Documents to have ready
- Your secure coding standards.
- Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.28 marked as used or not used, a short reason, and its current status.
Records and examples to show
- Code review records showing security was checked.
- Automated code scan results and fixes.
- Developer training on secure coding.
Things you should be able to show or explain
- Be able to walk through a recent code review.
How much to show: A handful of changes.
Common mistakes
- No code reviews.
- Scan findings ignored.
- Ignoring warnings from security scanners.
- Outdated libraries with known flaws.
- Tip: Use SAST tools and OWASP guidance.
Policies & documents to have
- Secure Development Policy
FAQ
Is A.8.28 mandatory?
Annex A controls are not automatically mandatory. You must consider every control and record in your Statement of Applicability whether it applies and why. In practice, most organisations include this one.
What will I need to show for A.8.28?
Be ready to explain how the control works in your organisation and to provide things like: Your secure coding standards…