A.8.28

Objective

Apply secure coding principles to software development to reduce security weaknesses.

Points of focus

• Language-specific secure coding standards exist and are referenced in code review
• SAST and dependency/SCA scanning run automatically on every pull request
• Secrets scanning prevents credentials from being committed to source control
• Findings above an agreed severity block merges rather than merely warn
• A defined process triages, prioritizes, and tracks remediation of scan findings to closure

Implementation notes

Adopt a secure coding standard scoped to the languages and frameworks you actually use — OWASP's cheat sheets are a reasonable starting point — and keep it short enough that engineers reference it, focusing on the vulnerability classes most relevant to your stack (injection, broken authorization, unsafe deserialization, SSRF for services that fetch user-supplied URLs). Wire SAST and dependency scanning into CI as required status checks rather than advisory ones, and set severity thresholds that block merges for criticals/highs while allowing lower-severity findings to be tracked without stopping delivery entirely — an all-or-nothing gate usually gets disabled the first time it blocks a launch. Run secrets scanning on every commit and on repository history, since leaked credentials in old commits are just as exploitable as ones in the latest push; rotate and revoke immediately if scanning catches something live. Assign clear ownership and an SLA for triaging findings — critical dependency vulnerabilities patched within days, lower-severity findings within a sprint or quarter — and track exceptions (accepted risk, false positive) as explicit, reviewed decisions rather than silent dismissals. Extend secure coding practices to infrastructure-as-code as well: scan Terraform and Kubernetes manifests with tools like Checkov or tfsec, since misconfigured infrastructure is as exploitable as insecure application code. Pair automated scanning with periodic manual code review training so engineers can catch the logic-level authorization bugs that static analysis tools reliably miss.

Audit tip: Show a pull request where a scan finding actually blocked a merge and how it was resolved — fixed, suppressed with justification, or accepted as a documented risk. A real blocked-and-resolved example proves the gate has teeth; a clean scan history alone could just mean nothing has been checked yet.

Common gaps

• SAST and dependency scanning run in CI but are configured as informational only, so critical findings are routinely merged anyway under deadline pressure
• Dependency alerts pile up in a dashboard with dozens of unaddressed criticals because there's no owner or SLA for remediation
• Secrets scanning covers the main branch but not historical commits or forked/personal repos, leaving old exposed credentials undetected

Related

Primary sources

• ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.28)