Secure coding standards: OWASP, CERT and NIST for small teams

Secure coding standards are published rule sets that say how code must handle input, authentication, access, secrets and errors, written so that someone can check whether the code follows them. The three names a small team meets first are OWASP, CERT and NIST. They do different jobs, so picking one starts with knowing which job you need done.

This guide compares them, shows which one fits a small team, and explains how to hold AI-written code to the same rules as everything else. If an AI tool wrote part of your product and nobody has checked it against any standard, our AI code audit starts with access control, data exposure, secrets and dependencies.

What is a secure coding standard?

A secure coding standard is a written set of requirements for code, specific enough that a reviewer or a tool can say whether a piece of code meets each one. That test separates a standard from general advice, and it is the reason customers and auditors ask for one by name.

The Software Engineering Institute (SEI), which publishes the CERT standards, draws the line clearly in its page on rules versus recommendations. A rule is a requirement whose violation is likely to cause a defect, and conformance can be determined through automated analysis, formal methods or manual inspection. A recommendation is guidance that should improve safety, reliability and security, but breaking one does not necessarily mean the code has a defect.

Documents that people call secure coding standards sit at three different layers:

• Process: how the team works. NIST's Secure Software Development Framework (SSDF) describes practices for the whole development process and leaves the code rules to you.
• Application: what the product must do. The OWASP Application Security Verification Standard (ASVS) lists security requirements for web applications and services, whatever language they are written in.
• Language: how the code is written. The SEI CERT standards give rules for one programming language at a time.

Two more names come up in the same conversations and are not standards at all. The OWASP Top 10 and the Common Weakness Enumeration (CWE) Top 25 are ranked lists of what goes wrong. They are useful for training and for deciding what to review first, and neither tells you when code passes.

Secure coding standards compared

The main standards differ in who publishes them, how close they sit to the code and what they suit. The table gives the current version of each as of November 2026, checked against the publisher's own page.

The last two rows are in the table because buyers ask about them, not because they are standards. The sections below take the three publishers in turn.

OWASP secure coding standards: ASVS and the checklist

For a web application, SaaS product or API, the OWASP standard to adopt is the ASVS. The current stable version is 5.0.0, dated May 2025, and it is the closest thing to a ready-made secure coding standard for a team that ships web software.

The OWASP ASVS project describes it as a basis for testing an application's technical security controls and a list of requirements for secure development. Version 5.0.0 has around 350 requirements in 17 chapters, including chapters on authentication, authorization, validation and business logic, and secure coding and architecture. It contains requirements only. In OWASP's words, a requirement describes what must be achieved, and the ASVS leaves out recommendations.

The requirements come in three levels, which is what makes the ASVS usable by a small team:

• Level 1 holds around 20% of the requirements. OWASP calls it the minimum to consider and a critical starting point.
• Level 2 holds around another 50% of the requirements, so meeting it means implementing around 70% of the ASVS. OWASP says most applications should be striving for this level.
• Level 3 is the final 30% or so, for applications that need to show the highest level of security.

Many articles still point to the OWASP Secure Coding Practices Quick Reference Guide. OWASP has archived that project. Its page says the checklists were moved into the OWASP Developer Guide, where the web application checklist now lives. It is a good short list for code reviews. If a customer asks which standard you follow, name the ASVS and a level instead.

The OWASP Top 10 is a different kind of document. OWASP calls it a standard awareness document, and the current edition is 2025. Its list opens with broken access control and ends with mishandling of exceptional conditions, with software supply chain failures third. Use it to teach a team what to look for. It does not say when an application passes.

CERT secure coding standards: rules per language

The CERT secure coding standards are language-specific rule sets from the Software Engineering Institute at Carnegie Mellon University. SEI publishes standards for C, C++ and Java. Choose CERT when you write native, embedded or Java code and need rules at the level of a single line.

The SEI CERT C Coding Standard, which many people search for as the CERT C secure coding standard, shows how the family works. Its rules are grouped by area: declarations, expressions, integers, arrays, strings, memory management, input and output, error handling, concurrency and more. Each group has rules, which are requirements, and recommendations, which are guidance.

Two details matter when you cite it. SEI maintains the standard on a wiki that it describes as a work in progress, and it publishes mature rules as official releases. The 2016 edition of the C standard is the release to name in a policy. SEI says it provides rules to help programmers ensure that their code complies with the C11 language standard and earlier ones, including C99.

SEI also notes that the set of recommendations a project adopts depends on its requirements. A project with stricter requirements is likely to adopt a broader set. That gives a small team a sensible order: adopt the rules first, then add recommendations as the product and its risks grow.

If you need an ISO reference for C, there is one. ISO lists ISO/IEC TS 17961:2013, a technical specification of C secure coding rules, and says it was last reviewed and confirmed in 2024.

NIST secure coding standards: SSDF and SP 800-218A

NIST does not publish line-by-line coding rules. Its SSDF, in NIST SP 800-218, is a set of high-level practices for the whole development process, and it expects you to bring your own secure coding standard.

Version 1.1 of the SSDF was published in February 2022. NIST organizes its practices into four groups:

• Prepare the Organization (PO): people, processes and technology are ready for secure development.
• Protect the Software (PS): every component is protected from tampering and unauthorized access.
• Produce Well-Secured Software (PW): releases have as few vulnerabilities as possible.
• Respond to Vulnerabilities (RV): remaining vulnerabilities are found, fixed and prevented from recurring.

Two tasks in the third group show how the SSDF relates to the other standards. Task PW.5.1 says to follow all secure coding practices that are appropriate to the development languages and environment. Task PW.7.2 says to perform code review or code analysis based on the organization's secure coding standards. The framework tells you to have a standard and to check code against it. It does not supply the rules, which is where the ASVS or a CERT standard comes in.

A revision is on the way. NIST published a draft of SSDF version 1.2 on December 17, 2025, and its comment period closed on January 30, 2026. As of November 2026, NIST still lists version 1.2 as a draft, so version 1.1 is the one to cite.

One NIST document is often misread. NIST SP 800-218A, published in July 2024, is an SSDF profile for generative AI. It adds practices for developing AI models, and NIST says it is for producers of AI models, producers of AI systems that use those models, and acquirers of those systems. It is not a rule set for code that an AI assistant writes for you. For that code, the standard is the same one you apply to code a person wrote.

Which secure coding standard fits a small team?

Most small teams need one application standard, one process frame and nothing else. For a web product that usually means ASVS Level 1 now, Level 2 for the parts that hold customer data, and the NIST SSDF as the outline of how you work.

Whichever row you are in, write the choice down. A one-page internal standard is enough for a team of five, and it should say four things:

1. The standard, its version and the level you hold yourself to, for example ASVS 5.0.0 Level 1.
2. The requirements you have decided not to meet yet, and why.
3. How each requirement is checked: by a tool in the pipeline, by a reviewer, or by an outside test.
4. Who owns the document and when it is next reviewed.

That page is also most of the answer when a security questionnaire asks about secure development. The rest is evidence that the checks run. Our guide to SOC 2 for startups covers how that evidence is collected, and penetration testing for startups covers the outside test.

Applying secure coding standards to AI-written code

AI-written code gets the same standard as any other code, with more of it checked, because two published studies found that assistants often produced vulnerable code and that people trusted it too readily. No separate standard exists for it, and you do not need one.

Two studies are worth knowing, with the caveat that both tested earlier models. Pearce and colleagues, in a paper accepted at the IEEE Symposium on Security and Privacy 2022, asked GitHub Copilot to complete 89 scenarios built around high-risk weaknesses. Of the 1,689 programs it produced, approximately 40% were vulnerable. In a user study by Perry and colleagues, participants with an AI assistant wrote significantly less secure code than those without one. They were also more likely to believe their code was secure.

The second finding is the one a standard fixes. A written requirement does not care who wrote the code or how confident they feel. In practice:

• Keep one standard. The page from the previous section applies to every pull request, whoever or whatever wrote it.
• Review access first. Missing authorization ranks fourth on MITRE's 2025 CWE Top 25, up five places from 2024. Start with the ASVS chapters on authorization and authentication.
• Check input and output handling. Cross-site scripting and SQL injection are first and second on the same list. The ASVS chapters on encoding and sanitization and on validation cover both.
• Automate what a tool can decide. Static analysis, dependency checks and secret scanning belong in the pipeline, as our comparison of DevOps vs DevSecOps explains.
• Keep a person on the rest. Whether a user may see a record is a business rule. A tool can rarely decide it, and a reviewer who knows the product can.

If you are not sure where an AI-built app stands, our vibe coding risk check gives a first read. Our guide asking is vibe coding bad explains what tends to break once such code reaches real users.

How to adopt a secure coding standard

Adopt a standard in small steps: pick one, cut it to a level, automate the checks a tool can run, and review the rest in pull requests.

1. Pick the standard and the version. Use the table above. Cite the version, because the documents change: the ASVS moved from 4.0.3 to 5.0.0 in May 2025.
2. Cut it to a level. ASVS Level 1 is around 20% of the requirements. Mark the ones that do not apply to your product and say why.
3. Map each requirement to a check. Some go to a tool, some to a review checklist, some to an outside test.
4. Apply it to new code first. Every new pull request meets the standard. Old code is brought up to it by risk, starting with anything that touches sign-in, permissions or customer data.
5. Record exceptions. An exception with an owner and a date is a decision. An unrecorded one is a gap.
6. Review the page when the publisher releases a new version. Check the publisher's site, not an article that quotes it.

How we check code against a standard

Our AI code audit and fix for vibe-coded apps reviews access control, data exposure, secrets, keys and dependencies, areas the lists above rank high. For any codebase, our code audit services end in ranked findings with fixes and effort, which you can set beside the standard you chose.

Every engagement is under an NDA, and the IP is always yours. Each one is quoted after a short call, because every codebase is different.

Frequently asked questions