Control 8.28 asks you to set secure coding principles and apply them to software development, so the software has fewer vulnerabilities. It is new in the 2022 revision. You need a defined baseline, practices during coding, review and maintenance, a process for changes, and trained developers.
Before coding
The control expects a minimum baseline for secure coding. That covers code you write and third party components you bring in. You also need a way to follow emerging threats and secure coding guidance, and a decision process for which external tools and libraries developers may use.
For most teams this becomes a short written standard: approved languages and frameworks, rules for dependencies, and where to look for guidance.
During coding
Apply the baseline while developers work. The supporting technology that one guide lists includes tools to keep a library inventory, protect source code from tampering, log errors and attacks, and run tests. Authentication and encryption components also count. Small companies might run tools on developer machines, and larger ones use central shared tools.
A dependency inventory is the part teams often lack. Without one you cannot show what third party code you ship.
After coding
Plan for review and maintenance. That means code review on changes, a way to handle vulnerabilities found later, and a defined process for changes to existing software. Old code needs the same rules as new code.
People
Developers should understand why secure coding matters and be trained on the methods and tools. Keep attendance records, since training evidence is a mandatory record under clause 7.2.
What auditors check
Auditors look for evidence that secure coding principles are built into the software life cycle. If they cannot find it, they treat that as a nonconformity. Bring:
- The secure development policy or coding standard
- A sample of pull requests with review evidence
- Test or scan results from the pipeline
- The dependency inventory
- Training records
Documents for this control are recommended but not mandatory. A secure development policy suits smaller and mid sized companies, and larger companies may write a separate secure coding policy.
Where tooling helps
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates that can run on pull requests. They give you the inventory and pipeline evidence an auditor will ask for. You still write the standard and own the decisions. You can try the free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Do we need a separate secure coding policy?
Not necessarily. A secure development policy is enough for many smaller and mid sized companies, as long as the practices are written down and followed.
Does the control cover open source libraries?
Yes. The baseline should cover third party components, and you need a way to decide which external libraries are allowed.
Sources
Last reviewed: 19 October 2026.
