A.8.28
Secure coding
Technological controlsCheckpoints 6Evidence 6Cases 5
Control objective
The organization is required to define secure coding principles and standards suited to the languages and frameworks it uses, and to apply them in day-to-day development so that code-level vulnerabilities are not introduced into software that is built or acquired. Coding-stage defects such as insufficient input validation, flawed authentication/authorization handling, use of unsafe libraries, and hardcoded credentials become an attack surface once deployed. Controlling code quality from a security perspective across design through maintenance reduces the likelihood of incidents, lowers the cost of remediation, and increases the trustworthiness of development deliverables.
Key checkpoints
- Are secure coding standards or guidelines established per programming language/framework in use, and shared with developers?
- Is there a procedure to detect and remediate vulnerabilities during coding and build using automated tools such as static analysis (SAST)?
- Are the vulnerabilities and licenses of external libraries/open source components identified, and is their currency managed?
- Is secure coding training delivered to developers on a regular basis, with completion status tracked?
- Do code review and merge/release approval procedures include security check items?
- Are severity classification, remediation deadlines, and recurrence prevention for identified vulnerabilities tracked and managed?
Implementation guidance
- Document secure coding standards reflecting language/framework characteristics, covering input validation, output encoding, authentication/session management, error handling, and safe logging principles.
- Integrate SAST/SCA/secret scanning into the development pipeline (CI/CD) to check automatically at commit/build time, and apply build-blocking or exception-approval policies based on severity.
- Maintain an SBOM and assess whether known vulnerabilities apply to the versions/features in use. Prioritize upgrades, replacement, or mitigation according to exposure, exploitation, and safeguards, with approved, expiring exceptions.
- Prohibit hardcoding credentials/cryptographic keys in source code, and keep secrets separated in a dedicated secrets management solution.
- Operate a security-focused code review checklist, and ensure high-risk changes cannot be merged without peer review and approval.
- Deliver secure coding training and hands-on practice to developers regularly, continuously reflecting new threat and vulnerability types in the material.
Evidence
- Secure coding standard/guideline documents and their revision history
- SAST/SCA tool scan results and vulnerability remediation records
- Code review records and merge/release approval logs (PR approval history)
- Developer secure coding training plans and completion status
- SBOM and open source vulnerability management register
- Vulnerability remediation tracking tickets/issue records and exception approval justifications
Nonconformity examples
- Secure coding standards exist but are not applied to actual development or the pipeline, remaining as formal documents only.
- High/medium severity vulnerabilities from SAST results are left unremediated for a long period with no exception approval justification.
- A component affected by a known vulnerability is deployed without risk assessment, necessary mitigation, or an approved remediation plan.
- API keys and database passwords are hardcoded in source code and committed to the version control repository.
- A code review procedure is defined, but reviews are performed with a focus on functionality only, without security check items.