A.8.28 Secure coding: requirements and evidence

What A.8.28 secure coding asks for in plain words

A.8.28 Secure coding asks that secure coding principles are applied to software development, so that software is written securely and the number of potential vulnerabilities is reduced. It is one of the 11 controls that were new in the 2022 revision of Annex A, with no counterpart in the 2013 edition, so organizations certified to the older version will find it has no earlier mapping to rely on. The risk it addresses is simple: flaws introduced while code is written are the cheapest to prevent and the most expensive to find later in production. If you are a compliance lead or engineering head, the practical question is not whether a secure coding policy exists but whether your teams can show that it shapes how code is written, reviewed and tested.

Assessors usually look at practice rather than a written policy alone. They will ask for the coding standards in use, sample recent changes and check whether review and testing actually happened before merge. Three things make this hard in most organizations: there is no shared coding standard that teams apply the same way, code reviews are approved in tools without a record of what was checked, and third-party and open-source components are pulled in without anyone tracking their versions or known weaknesses. Confirm with your assessor how they expect review and component tracking to be evidenced, since the auditor, not DeployOpen or the standard itself, decides what is sufficient.

A.8.28 sits alongside A.8.25 Secure development life cycle, A.8.29 Security testing in development and acceptance and A.8.4 Access to source code, and an assessor will often test them together. Decide early which team owns the coding standard, which repository controls enforce review and which pipeline stages run security checks, then record those decisions in your Statement of Applicability. The control text itself is not reproduced here, so obtain ISO/IEC 27001:2022 and ISO/IEC 27002:2022 from ISO or the IEC Webstore before you draft your procedures.

Which code and pipelines fall under A.8.28 secure coding

A.8.28 applies to any code the organization writes, builds, ships or relies on inside its ISMS boundary. The scope is set in the organization's own Statement of Applicability and risk assessment, so the questions below should be answered and recorded there before anyone decides what secure coding evidence to collect.

In-house application code

Code written by the organization's own developers for products, customer portals and internal tools is the core of A.8.28. Assessors usually expect the coding standards, peer review and security testing to cover every repository that feeds a production system. The scoping question is which repositories are inside the ISMS boundary, and whether prototypes or proofs of concept that reach customers count as in scope.

Internal libraries and shared modules

Shared authentication helpers, logging wrappers and common components are multiplied across many applications, so a flaw in one module spreads to every consumer. They usually fall in scope because a weakness here reaches the same systems the rest of the code protects. The question is who owns each library, who approves changes to it, and which applications are required to use it.

Infrastructure as code and configuration

Terraform, Helm charts, Ansible playbooks and similar files define networks, permissions and runtime settings, so they carry security decisions in the same way application code does. They are often overlooked because teams treat them as operations work. The scoping question is whether these definitions are written and reviewed under the same secure coding rules, and whether the scanning tools used for application code also cover them.

CI/CD pipelines and build scripts

Pipeline definitions decide what code is built, tested and deployed, and who can change that process. A pipeline that skips security tests or accepts unreviewed changes weakens every product it ships. Organizations should confirm whether pipeline configuration sits under the same branch protection and review rules as application code, and whether the build environment is treated as an asset in the ISMS.

Open-source and purchased components

Third-party libraries, frameworks and commercial packages become part of the delivered product even though the organization did not write them. Their known vulnerabilities, outdated versions and license terms are the organization's responsibility once shipped. The scoping question is which dependencies must be inventoried, who approves new ones and how the organization tracks them through a software bill of materials.

Code produced by outside suppliers

Code written by contractors, offshore teams or AI-assisted generation under contract may reach production without any employee reading every line. Whether this code is inside the ISMS boundary depends on whether the organization owns and deploys it. Organizations should confirm the supplier's secure development obligations, how deliverables are reviewed and tested, and which contract terms give the organization audit rights over that work.

How an assessor tests secure coding in an ISO 27001 audit

This table compares the four areas an assessor usually examines for A.8.28 Secure coding, the evidence each one asks for and the gaps that appear most often. Read each row as a question the assessor will put to the team, then check whether the records would answer it for recent changes, not just for a policy document. Assessors sample real changes and trace them back to records, so a process that is applied consistently over time carries more weight than a well-written standard that nobody follows.

Test area	Evidence requested	Common findings
Coding standards exist and are applied	Written secure coding standard, the version in force, onboarding or training records, and a sample of recent merge requests showing the standard was followed or deviations were recorded	Standard is generic or outdated, no owner or review date, developers unaware of it, and no way to show it was applied to recent code
Code changes are reviewed before merge	Protected branch settings, required approvals and reviewer roles, review comments on sampled changes, and records of who approved each merge	Direct pushes allowed to main branches, self-approval permitted, reviews that do not mention security, and gaps in approval history for some periods
Security testing runs in the pipeline	Pipeline configuration files, scan job logs for sampled builds, rule sets in use, and records of findings triaged, fixed or accepted with a reason	Scanners configured but not blocking, scans skipped on some branches, findings left open without owners, and no evidence of which rule versions ran
Third-party and open-source components are governed	Software bill of materials for sampled releases, dependency vulnerability records, approval or intake records for new libraries, and license review outcomes	Inventory missing or stale, no link between components and releases, unapproved libraries in production, and vulnerable components left unpatched without a documented decision
Consistency across the audit period	Records that cover the whole audit window, not only recent weeks, with the same tools and procedures applied throughout	Evidence exists for the last month only, tooling changed without records, and procedures documented after the audit started

How to implement secure coding controls step by step

This illustrative sequence moves a development team from written standards to enforced branch rules, automated scanning, review gates, component governance and trained developers, with a named artifact at each stage that an assessor can inspect.

Choose and document a coding standard per language
Start by inventorying every language, framework and build pipeline in use across the product and internal tooling. For each one, the engineering lead selects a published secure coding guideline or writes a short internal standard that covers input validation, output encoding, authentication and session handling, error handling, secrets handling and dependency use. The output is a versioned written standard for each language, approved by the security owner and stored in the same repository as the code it governs. It is done when every language in the inventory has a named standard, an owner and a review date, and the standard is linked from the contribution guide.
Define branch and merge rules
Next, the platform or DevOps team configures protected branches so that no one can change the main line of code outside the agreed process. In GitLab Community Edition, protected branches let maintainers restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. The output is a branch protection configuration exported or documented per repository, with a short record of who holds merge rights. It is done when a test push to a protected branch is rejected for an unauthorized role and the settings can be shown to an assessor.
Add automated scanning to the pipeline
Then the team adds static analysis and dependency checks to continuous integration so that every merge request is scanned before it reaches a protected branch. Semgrep Community Edition scans code in many languages with community or custom rules and can run in CI/CD pipelines, so teams can write rules for the patterns their standard prohibits. Trivy can identify OS packages and software dependencies and produce a software bill of materials. The output is a pipeline definition, a rule set under version control and scan logs retained as evidence. It is done when a deliberately insecure test change fails the pipeline and the failure is recorded. Confirm the scanner coverage for each language in your inventory before relying on it.
Set review requirements
Define who must review a change before it merges and what the reviewer checks. Security-sensitive paths such as authentication, cryptography, input parsing and data access usually need a reviewer with security knowledge, while routine changes may follow a lighter route. The reviewer checklist should reference the written standard from the first step. The output is a documented review policy, approval rules configured in the repository platform, and a checklist template attached to merge requests. It is done when the approval rules block a merge without the required reviewer and a sample of recent merges shows that reviews addressed the checklist items.
Establish governance for external and open-source components
Create a list of approved third-party and open-source components, the criteria for adding one, and the process for retiring one. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, identifies components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX identifier. Feed it the SBOMs produced by the pipeline so the approved list stays current. The output is an approved component register, an intake procedure and a log of exceptions with approver names. It is done when a new dependency cannot enter the build without an entry in the register and the system shows the current components and their known risks.
Train developers on the standard
Finally, the team delivers training that walks developers through the written standards, the scanner findings they will see, the review checklist and the component intake process, using examples from the team's own code. Training should be repeated when standards change and when new developers join. The output is training material kept under version control, attendance or completion records, and short exercises that show developers can identify and fix the flaws the standard targets. It is done when every developer with commit rights has a completion record and the standards owner has reviewed the scanner findings for the period to see whether training needs to change. The sequence is illustrative, and teams often run several steps in parallel.

Which evidence satisfies A.8.28 secure coding

A.8.28 is judged on whether secure coding is applied in practice, so assessors look for records that show a standard exists, that code is reviewed and tested against it, and that third-party components are governed. The cards below cover the artifacts that usually connect those points, along with how each one stays current between audits.

Approved secure coding standards

The written coding standard names the languages in use, the insecure patterns developers must avoid, and the required checks before merge. Assessors look for an approval record, an owner and a version history showing it was revised after new frameworks or incidents. Keep the standard in the same repository as the code it governs so every change is traceable. Set a review date on the document and record each review, even when nothing changes, so the file shows it was checked on schedule. Confirm with your auditor how they expect review cadence to be documented.

Merge request review records

Review records show that a second person examined each change before it reached a protected branch. Export the approval history from your platform and check that reviewers are not the change authors and that security-relevant changes received security-aware review. Sample a few merge requests during internal checks to confirm comments, approvals and any reopened discussions are complete. Retain these records for as long as your audit cycle requires, and confirm the retention setting in your platform so pipeline and review history is not purged early.

Branch protection configuration export

Protected branch settings are the technical proof that the review rule cannot be bypassed quietly. In GitLab Community Edition, protected branches let you restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Export these settings as configuration and store them with change history so an assessor can see the state on a given date. Recheck the export after any repository migration or permission change.

Scanning reports and triage decisions

Static analysis output only counts as evidence when someone decided what to do with each finding. Semgrep Community Edition can run in CI/CD pipelines and scan repositories continuously, so keep the scan job logs and the reports they produce. Record a triage decision for every finding: fixed, accepted with an owner and reason, or determined to be a false positive. Review the open backlog on a set schedule and keep the closed findings with their justifications, not only the open ones.

Component inventory and SBOM approvals

A.8.28 extends to open-source and external components, so assessors ask how dependencies were selected and whether they are monitored. Generate a CycloneDX SBOM with Trivy for each build, then load it into OWASP Dependency-Track, which tracks known vulnerabilities, outdated or modified components and license risk using SPDX license IDs. Keep an approval record for each new component, including its license and maintainer status. Review the inventory whenever a release is cut, and keep superseded SBOMs so you can show what shipped at any past date.

Developer training records

Training records show that developers know the standard they are held to. Keep attendance or completion records for secure coding sessions, along with the material used and the date it was last updated. Link training topics to the findings your scans most often raise, so the curriculum reflects what your own code gets wrong. Confirm with your certification body how far back they expect records to go and whether new hires must complete training before committing code.

What meeting A.8.28 secure coding costs

This table compares the cost components of meeting A.8.28 Secure coding, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote, and note that open-source tools remove license spend but not the engineering and review effort that the control depends on.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring if commercial, none for Community Editions	Number of repositories, developers and pipeline runs; whether premium scanning or support tiers are bought	GitLab Community Edition, Semgrep Community Edition, Dependency-Track and Trivy carry open-source licenses; confirm feature gaps against your needs before assuming they cover everything
Engineering time to write standards and configure pipelines	One-time, with periodic revision	Number of languages and frameworks in use, existing pipeline maturity, and how many teams must adopt the standard	Start with a short standard covering your main languages, and reuse existing CI templates instead of building each pipeline from scratch
Review time	Recurring	Volume of merge requests, size of changes, and whether security review is required for every change or only sensitive code	Route only high-risk changes to security review, and use protected branch rules so review is enforced consistently
Dependency and SBOM upkeep	Recurring	Number of third-party and open-source components, release frequency, and handling of vulnerability and license findings	Automate SBOM generation in the pipeline and define triage rules so that only actionable findings reach engineers
Evidence upkeep	Recurring	Frequency of audits and internal reviews, number of teams producing records, and how much evidence is gathered by hand	Let pipelines and repository settings produce logs, scan results and approvals automatically, then keep a regular review schedule
External application security testing or code review	Recurring or per engagement	Scope of applications, release cadence, and whether testing covers code, APIs or the running system	Define scope in writing, focus on applications with the highest exposure, and agree retesting terms up front
Auditor sampling time	Recurring with each audit cycle	Number of code changes and projects the auditor samples, and how easily records can be retrieved	Keep a consistent record trail for each change, so samples can be pulled without manual reconstruction

Which open-source tools produce secure coding evidence

A.8.28 Secure coding is tested by asking whether code is written, reviewed and checked in a way that reduces vulnerabilities, and whether that practice is repeatable. The four tools below each produce a different kind of record: who may change the code, what static analysis found, which third-party components are present and what is known about them. Confirm each tool's current feature coverage against your own stack before you rely on it as evidence.

Protected branches in GitLab

GitLab Community Edition (MIT license) provides protected branches, which restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes to the main branch, so every change must pass through a reviewed merge request. Force pushes stay disabled unless explicitly allowed, which protects the history that reviewers rely on. Export the protected branch settings and merge request approval records as evidence. Confirm which approval rules and audit features are included in the edition you run, because some controls are only available in paid tiers.

Static analysis with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans source code with community or custom rules and can run in CI/CD pipelines to scan repositories continuously. Its output shows which rules flagged which lines, and whether findings were triaged or fixed before merge. Custom rules let your team encode its own coding standards, such as banned functions or unsafe patterns in your frameworks. Check the supported language list for each language you use, including C/C++, Go, Java, Python, TypeScript and Terraform, and confirm the current rule coverage for any language that is not on that list.

Component risk in Dependency-Track

OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, and identifies components with known vulnerabilities, outdated or modified components and license risk. License use is tracked by component using SPDX license IDs. This gives you a current inventory of third-party and open-source code, and a record of how each known vulnerability was assessed. Keep the VEX statements for vulnerabilities marked as not affected, since an assessor will ask why a finding was dismissed. Confirm which data sources and integrations your version uses for vulnerability intelligence.

Inventory and SBOM scanning with Trivy

Trivy (Apache-2.0) identifies the OS packages and software dependencies in a target and can produce them as a software bill of materials. It can also scan existing SBOMs, so the same inventory can be checked in CI and again later without rebuilding the artifact. This supports the governance of external and open-source components by showing what shipped in each release. Store the SBOM with each build, and confirm which package ecosystems and artifact types your current version detects, since coverage differs between language ecosystems and container images.

Who does what for secure coding: your team, a partner and the auditor

Your organization owns A.8.28 in full. Accountability for the control sits with you, so the coding standards, the review rules, the decisions about which findings block a release and any risk accepted for a known weakness must come from your own people. An assessor will ask who approved each standard and who signed off each exception, and the answer must name your staff, not a vendor.

Coding standards: Your engineering leads write and approve the secure coding rules for each language and framework you use, and they review them when the stack changes.
Review decisions: Your developers and reviewers decide how security review fits into merge requests, and who may approve a change that touches authentication, cryptography or data handling.
Risk acceptance: Your security or risk owner records each accepted finding, its rationale, its owner and its review date.
Training and competence: Your team keeps records showing developers have been trained on the standards that apply to their work.
Ongoing operation: Your staff run the pipeline and triage findings after the initial setup is handed over.

Before relying on this split, confirm that a named owner exists for each of these items and that the approvals are recorded somewhere an assessor can read.

Where secure coding programs usually fall short

Most organizations have a secure coding policy somewhere. The gaps that fail assessments sit between that policy and daily development: rules nobody reads, checks the platform does not enforce, and decisions nobody recorded. Each card below names one such gap under A.8.28 Secure coding and a practical way to close it.

Standards that live only on a wiki

A coding standard published as a wiki page rarely changes how developers write code. Assessors look for the standard being applied, so ask for evidence that it is used: linter configuration checked into the repository, rules referenced in merge request templates, and examples drawn from the organization's own code. Keep the standard short enough that a developer can apply it during review, and record who approved each revision and when it took effect.

Review rules the platform does not enforce

A written rule that a second engineer must approve every change means little if the repository lets maintainers merge their own work. Use protected branches so direct pushes are blocked and merges require the review rules you described. Confirm in your own environment that these settings apply to administrators as well as ordinary developers, because an exception granted for convenience is often the first thing an auditor finds.

Scanner findings marked ignored without a decision

Static analysis tools produce findings that teams often dismiss in the tool interface with no reason attached. A dismissal with no owner, date or rationale is indistinguishable from a missed vulnerability. Require every suppression to carry a named approver, a justification and a review date, and sample those records during internal review. Semgrep can run in CI/CD pipelines to scan repositories continuously, which gives you a steady record to test against.

Open-source dependencies added without approval

Developers add packages in minutes, and the component list changes without anyone deciding it should. Put an approval step in front of new dependencies, such as a required reviewer for changes to manifest and lock files. Pair it with a software bill of materials so you can show which components were in each release, and track known-vulnerable, outdated and license-risk components continuously rather than once a year.

Developer training that leaves no record

Secure coding training that happens informally cannot be shown to an assessor. Keep a record for each developer that names the course or session, the topic covered, the completion date and the role. Link training to the secure development rules so that a change in standards triggers a short refresher. Ask your assessor which records they expect to see, because the format matters less than being able to tie each developer to completed training.

Common questions about A.8.28 secure coding

How much effort does A.8.28 secure coding take for a small development team?

For a small team, the effort is mostly one-time setup of a written secure coding standard, a review step in the merge process, and automated scanning in the build pipeline, followed by a steady recurring cost of reviewing findings. The work scales with the number of repositories, languages and release frequency rather than with headcount alone. A team with one product, one language and a single main branch has far less to define than a team shipping several services. Ask any partner to break the estimate into the standard, the pipeline changes, the training and the recurring review hours, so you can see which part your own engineers must carry.

Can A.8.28 secure coding be met with open-source tools alone?

Open-source tools can produce much of the technical evidence, but they do not cover the whole control. Tools such as Semgrep Community Edition can scan code in CI/CD pipelines, GitLab Community Edition supports protected branches that restrict who can push or merge, and OWASP Dependency-Track and Trivy help track components and software bills of materials. The control also needs a written coding standard, defined review expectations and training records, which are management documents rather than tool outputs. Confirm each tool's language coverage and licensing against your own stack before you rely on it, using the Semgrep supported languages page as the starting point.

How long does setting up secure coding controls usually take?

No fixed duration applies, because setup time depends on what already exists. The main drivers are how many repositories and pipelines need scanning, whether a coding standard already exists, how many languages and frameworks are in use, how much noise the first scans produce, and whether review and branch rules are already enforced. Teams that already use protected branches and automated builds typically have a shorter path than teams starting from manual releases. Ask for a timeline tied to a written scope with named repositories, pipelines and deliverables, and confirm the assumptions behind it, including how long the first wave of findings triage will take.

What does the control need from our own engineering and security staff?

The control needs internal owners who make decisions that an outside partner cannot make for you. Engineering leads must agree the secure coding standard, accept or reject scanner rules, decide what blocks a merge, and enforce review on their own repositories. Security staff should own risk acceptance for findings and the review of dependency and license risk. Developers must complete the training the standard requires and follow the review process in daily work. Before you start, name these people and their time commitment, since the evidence an auditor reviews shows whether those people actually performed the duties.

Will an auditor test our source code directly for A.8.28?

Generally, an auditor tests whether the process works and whether it leaves evidence, rather than reviewing every line of code. A typical check looks at the coding standard, whether it is approved and communicated, samples of merged changes showing review, pipeline logs showing scans ran, records of how findings were handled, and how third-party and open-source components are governed. The auditor may ask engineers to walk through the process and may select repositories for sampling. Confirm the expected sample and evidence format with your certification body before the audit, because the approach varies by assessor. Only the independent certification body decides whether the control is met.

Can a partner replace our internal owner for secure coding?

A partner can prepare the systems, pipelines, documentation and evidence, but it cannot replace the internal owner. DeployOpen implements, configures and documents self-hosted platforms and security tooling in your own environment, and can run security testing and training. The organization still owns its controls, approves its standards and accepts its risks. Responsibility for the control after handover, including tuning rules, reviewing new findings and keeping the standard current, must sit with a named person in your organization. An outside partner that offers to own the control long term should be asked how knowledge and evidence transfer to your staff.

What should a written scope for A.8.28 work include?

A written scope should name the repositories, languages, pipelines, environments and teams covered, along with the deliverables and the responsible owner for each. It should state which tools will be deployed, whether they are self-hosted in your infrastructure, and who maintains them after handover. Include the coding standard, review and merge rules, training scope, dependency and software bill of materials handling, and the evidence to be retained. Also state what is excluded, such as outsourced development governed under A.8.30 or code the organization does not control. A clear scope makes pricing and timelines comparable across proposals.

How DeployOpen prepares secure coding evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the repository, review, scanning and component tracking that A.8.28 Secure coding evidence depends on. We prepare the systems and records; your organization owns the controls, and only an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which repositories, pipelines and development teams fall within the A.8.28 Secure coding scope.
Confirm which coding standards, languages and frameworks your teams use so the controls match real development work.
Define which open-source and third-party components are covered by governance and which owners approve them.

How we build

Configure protected branches in GitLab Community Edition so direct pushes and unreviewed merges are blocked.
Add Semgrep Community Edition to CI/CD pipelines with community or custom rules for the languages in scope.
Generate CycloneDX SBOMs with Trivy and track components, known vulnerabilities and license risk in OWASP Dependency-Track.

How we hand over

Deliver written procedures for coding standards, peer review, scanning exceptions and component approval, mapped to A.8.28.
Provide configuration records and exported logs showing pipeline scans, review approvals and dependency findings over time.
Document open findings, owners and remediation decisions so your auditor can sample the evidence independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
Review scanner rule sets and SBOM outputs periodically as languages, frameworks and components change.
Ask us to confirm during the quote which tools, versions and integrations are covered by the agreed scope.