APP-003 Secure Coding Standards
Description
Documented secure coding standards are adopted, communicated to all developers, and enforced during development. Standards address common vulnerability classes (e.g. OWASP Top 10, injection, memory safety). Code is written to avoid known insecure patterns. Standards are reviewed and updated at least annually.
Rationale
Consistent application of secure coding practices prevents the introduction of well-understood vulnerability classes. Standards reduce dependence on individual developer knowledge.
Framework Mappings (4)
| AIS-02 | Application Security Baseline Requirements | partial |
| 8.28 | Secure coding | full |
| SA-15 | Development Process, Standards, and Tools | partial |
| CC8.1 | Change Management | informative |
Evidence (2)
Documented secure coding standards adopted by the engineering team, covering common vulnerability classes and referencing an industry baseline such as OWASP Top 10 or CWE Top 25.
Example: Secure Coding Standards document or Engineering Security Standards page (Confluence, Notion, internal wiki) explicitly referencing OWASP Top 10 or CWE Top 25, listing prohibited patterns (e.g. parameterised queries required, no eval() on user input), with a last-reviewed date within the last 12 months.
Test: Request the secure coding standards document. Verify: (1) the document explicitly references at least one industry vulnerability taxonomy (OWASP Top 10, CWE Top 25, or equivalent), (2) the document covers input validation, output encoding, authentication, and secrets handling at minimum, (3) the document is communicated to all developers — confirm via onboarding checklist or training record, (4) last-reviewed date is within the last 12 months.
SAST scan result showing that secure coding rules aligned to the adopted standards are enforced in the CI pipeline and that high-severity findings block merges.
Example: Semgrep, SonarQube, Checkmarx, or Snyk Code scan report for the main repository, showing the ruleset applied (e.g. OWASP Top 10 ruleset), the last scan date, and the count of open high/critical findings. Pipeline configuration file (e.g. .github/workflows/sast.yml) showing the scan runs on every PR.
Test: Review the SAST pipeline configuration and the most recent scan report. Verify: (1) SAST runs automatically on every pull request targeting the main/production branch, (2) the ruleset includes coverage for OWASP Top 10 vulnerability classes, (3) critical and high findings block the PR from being merged (check branch protection status checks), (4) the count of open high/critical findings is zero, or each open finding has a documented risk acceptance or remediation ticket.
Questions (2)
Has your organisation adopted documented secure coding standards that are communicated to all developers and cover common vulnerability classes?
Standards must be accessible to and used by all developers — not just security specialists. They should reference an industry taxonomy (e.g. OWASP Top 10, CWE Top 25) and be reviewed at least annually.
How are secure coding standards enforced in your development process?
Automated enforcement via SAST in CI is the strongest mechanism. Documentation without enforcement or training provides weak assurance.