Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.28 — Secure Coding

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.28 ISO 27001ISO 27002BSI CON.8

A developer concatenates user input directly into a SQL query. The code passes functional testing because the test cases only use expected inputs. In production, an attacker submits a crafted input string and extracts the entire customer database. A.8.28 requires that software is written according to secure coding principles — preventing vulnerabilities from entering the codebase in the first place.

Secure coding is not about perfection — it is about systematically preventing the most common and dangerous vulnerability classes through standards, training, tooling and review.

What does the standard require?

  • Establish secure coding standards. Define rules for input validation, output encoding, authentication handling, session management, error handling and cryptographic use for each programming language and framework.
  • Apply standards to all code. Secure coding practices apply to all code — internal, outsourced and open-source contributions.
  • Use secure development tools. Configure IDEs, linters and build tools with security-relevant settings.
  • Conduct code reviews. Review code for security vulnerabilities through a combination of automated analysis and peer review.
  • Manage third-party code. Assess security of external libraries, pin versions and monitor for vulnerabilities.
  • Update practices continuously. Review and update secure coding standards as new vulnerability classes and attack techniques emerge.

In practice

Define language-specific coding standards. For each technology stack, document: input validation rules (always validate, always server-side), output encoding requirements, parameterized query requirements (never concatenate SQL), session management rules and error handling guidelines.

Integrate SAST into the CI/CD pipeline. Configure static analysis to run on every commit or pull request. Block merges when critical or high-severity findings are present. Common tools: SonarQube, Semgrep, CodeQL, Checkmarx.

Require peer review for all production code. Every pull request requires at least one reviewer who checks for security issues alongside functionality. Use a security-focused review checklist for high-risk changes.

Scan dependencies continuously. Use SCA tools (Dependabot, Snyk, Trivy) to monitor third-party libraries for known vulnerabilities. Automate pull requests for dependency updates and prioritize security patches.

Typical audit evidence

Auditors typically expect the following evidence for A.8.28:

  • Secure coding standards — documented rules per language/framework (see Secure Software Development Policy in the Starter Kit)
  • SAST tool configuration — evidence of automated analysis in the pipeline
  • Code review records — pull request history showing security-focused reviews
  • SCA scan results — dependency vulnerability reports and remediation status
  • Developer training records — evidence of secure coding training

KPI

Percentage of code reviews that include secure coding compliance checks

Measured as a percentage: how many code reviews include a security-focused evaluation (automated or manual)? Target: 100%.

Supplementary KPIs:

  • Number of SAST findings per 1,000 lines of code (trend over time)
  • Percentage of critical dependency vulnerabilities remediated within SLA
  • Number of developers who completed secure coding training in the last 12 months

BSI IT-Grundschutz

A.8.28 maps to BSI software development modules:

  • CON.8 (Software Development) — secure coding requirements including input validation, output encoding and error handling.
  • CON.10 (Developing Web Applications) — specific secure coding requirements for web applications, including OWASP Top 10 coverage.

Sources

Frequently asked questions

What secure coding standards should we follow?

OWASP provides the most widely used resources: OWASP Top 10 for awareness, OWASP ASVS for verification, OWASP Cheat Sheets for implementation guidance. For specific languages, use CERT Secure Coding Standards (C, C++, Java) or language-specific guidelines.

Is code review mandatory?

ISO 27002 recommends reviewing code for security vulnerabilities through both automated tools and peer review. In practice, mandatory code review for all changes to production code is standard practice and an auditor expectation.

How do we handle third-party libraries?

Use Software Composition Analysis (SCA) tools to scan dependencies for known vulnerabilities. Maintain a list of approved libraries, pin versions and monitor for new CVEs. Abandoned libraries with no security maintenance should be replaced.