Write each rule as a short, checkable statement tied to a weakness type, then mark whether a tool can enforce it or a human must review it. A standard that says "validate all input" cannot be enforced. One that says "never build SQL by string concatenation" can be.
Why the standard comes first
NIST's Secure Software Development Framework says code review or analysis should be performed against the organization's secure coding standards, and that discovered issues be recorded and triaged in the team's workflow. That sentence assumes a standard exists. Without one, a scanner's default rule set becomes your standard by accident.
A five step method
- List the weakness types that matter to you. Start from your own incidents and from a public list such as the CWE Top 25, then trim to what applies to your stack.
- Write one rule per weakness, in plain words. Use verbs a developer can act on: use, never, always.
- Add a positive example and a negative example. Short code snippets from your own codebase help most.
- Classify enforcement. Mark each rule as tool enforced, review enforced or test enforced.
- Assign an owner and a review date. Standards rot when nobody owns them.
Example rules and how to classify them
| Rule | Enforcement |
|---|---|
| Never build SQL statements by joining strings with user input | Tool, a data flow rule can check this |
| Never pass user input to a shell command | Tool |
| Resolve file paths against an allowed base directory | Tool plus review |
| Every route that returns account data must check ownership | Review and tests, static tools struggle here |
| Do not disable certificate checks | Tool, a simple pattern rule |
| Log security events with a request identifier | Review |
The pattern is useful. Rules about how untrusted data reaches a risky operation suit static analysis. Rules about what the application should allow suit review and tests. OWASP lists access control and authentication among the flaws that are very difficult to find automatically.
Map rules to tool rules
Once the standard exists, map each tool enforced rule to a rule or query in your scanner. Two outcomes are useful. A rule with no matching tool check is a gap you now know about. A tool check with no matching standard rule is noise you may be able to turn off.
Keep the mapping in a simple table: standard rule, scanner rule name, severity, action on a finding. Reviewing that table once a quarter is lightweight and keeps both sides honest.
Keep it short
A standard with sixty rules will not be read. Aim for a page that a new developer can finish in one sitting, with links to deeper guidance. Add rules when a real incident or repeated finding earns them a place.
A worked example: from vague rule to enforceable rule
Start with a common line in an old standard: "Developers must validate all input." It sounds good and cannot be checked. Here is how to rewrite it in steps.
- Identify the weakness: untrusted data reaching a database call.
- State the behavior: "Database queries must use parameterized statements. String concatenation with request data is not allowed."
- Add examples. Show a short unsafe snippet and a safe one from your own code.
- Classify enforcement: tool enforced, because a data flow rule can detect string built queries.
- Name the exception route: "Dynamic table names must come from an allow list defined in code and reviewed by the security champion."
The result is a rule a developer can follow, a tool can check, and a reviewer can audit. The original line gave none of those.
A sample page, structured
| Section | Content |
|---|---|
| Purpose | Two sentences on why the standard exists |
| Scope | Which repositories and languages it covers |
| Rules | A numbered list, each with a rule, example and enforcement type |
| Exceptions | Who can approve and how it is recorded |
| Ownership | A named owner and a review date |
| Change log | Dated list of rule changes |
Keep each rule to three or four lines. Link to a longer guide for background.
Choosing the first ten rules
Most teams get more value from ten good rules than from sixty. A simple way to pick:
- List weakness types behind your last year of security findings and incidents.
- Add the types from a public list such as the CWE Top 25 that apply to your stack.
- Remove anything the framework already prevents by design.
- Keep the ones where a developer needs a clear instruction.
Review the result with two or three developers before you publish it. They will tell you which rules are unclear or impractical.
Making the standard visible in the pipeline
A standard is more likely to be followed if the tool messages echo it. When a rule fires, the finding should reference the rule number, for example "Standard 4: use parameterized queries." Many tools let you attach custom messages or tags to rules. Even without that feature, a mapping table in the wiki works. The goal is that a developer who sees a finding can find the matching rule and a fix example within a minute.
Reviewing the standard against tool results
Every quarter, check three things:
| Check | Question | Action |
|---|---|---|
| Rules with no tool coverage | Is there a gap? | Add review steps or tests |
| Tool rules with no standard | Are they noise? | Disable or document |
| Rules often overridden | Is the rule unclear or the tool wrong? | Rewrite or tune |
This keeps the standard and the tooling in step, and it shows auditors that the document is alive.
Training and onboarding
Add the standard to onboarding. A thirty minute walkthrough with the ten rules and live examples from your codebase is enough. Refresh it when rules change. People follow rules they understand, and they understand rules they have seen applied in code they work on.
Standards and the SSDF
NIST's Secure Software Development Framework ties code analysis to your organization's secure coding standards, so having a documented standard is part of showing that your practice is coherent. Keep the version history, because it shows how the standard changed in response to real findings.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a failed check names the rule and what the author does next, which is how a standard becomes visible in daily work.
Quick check
Do I need a standard before I buy a SAST tool?
A draft helps. It tells you what to test during a pilot and what you expect the tool to enforce.
Can the tool's default rules be my standard?
They can be a starting point, but a standard should reflect your stack and risks, and you should be able to explain every rule.
Who should own the secure coding standard?
A named person, usually in security or an engineering lead role, with input from developers. The owner keeps the review date and the change log.
Safeguard offers policies, gates and guardrails you can use to enforce decisions in your pipeline, and a free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework version 1.1
- OWASP, Static Code Analysis
- MITRE, 2025 CWE Top 25 Most Dangerous Software Weaknesses
Last reviewed: 19 October 2026.
