How it is created — SDL-STD-020 Secure Coding Standard

1. Why this artifact exists

"Secure implementation" is the phase where a lifecycle policy most easily becomes decorative. Requirements and threat models produce documents that someone reads; implementation produces thousands of commits that nobody reviews against a policy PDF.

So the useful coding standard is not the comprehensive one. It is the one short enough that a developer has actually read it, and specific enough that most of it is enforced by the pipeline rather than by memory. Every rule should be answerable: is this checked automatically, checked in review, or neither? A rule in the third category is a preference, and it belongs in a style guide.

The second job is subtler. An assessor asking how you know your product ships without known exploitable vulnerabilities wants to see a chain: a rule, a gate that enforces it, and a record that the gate ran. A standard with no gates behind it breaks that chain at the first link.

2. Inputs

• The language and toolchain you actually use, and the RTOS. A standard written for hosted C is wrong for bare-metal firmware in specific ways — the heap rule alone.
• Your existing static-analysis tooling, because the rules you can enforce today are the rules worth writing today.
• The threat model's attack surface inventory: the parsers on a trust boundary are the code the rules most need to constrain.
• Your defect history. The rules that pay for themselves are the ones that would have caught something you already shipped.
• The credential policy, so the "no hard-coded secrets" rule points at the mechanism that replaces them.

3. Steps

1. Adopt an existing subset rather than writing rules from scratch. MISRA C:2012 for embedded C. Then state the category treatment — mandatory enforced, required enforced with deviations, advisory aspirational — because adopting MISRA without saying which categories bind means nothing.
2. Define the deviation procedure before anyone needs one. In-code marker, register entry, technical reason, containment, approver. Then ban blanket suppressions: a file-level pragma is how a codebase drifts back to unchecked in about six months.
3. Exclude third-party code explicitly. You are not going to reformat Zephyr or mbedTLS, and a standard that implies you will is a standard that gets ignored on its first contact with a vendored tree. Govern those through the component policy instead.
4. Write the banned list as pipeline checks. If a banned function can be committed and merged, it is not banned. Compile with warnings as errors — that single line removes a whole class of arguments about whether a warning matters.
5. Ban the heap in steady state on embedded targets, and say why: fragmentation surfaces in year three, in a customer's plant, not in your test rack.
6. Scan for secrets across branch history, not just the diff. A key removed in a later commit is still in the history, and history gets cloned. Wire the hit to a rotation assessment, because finding the secret is only half of it.
7. Write the crypto rule as a prohibition with a named alternative. "No home-grown cryptography, use mbedTLS" prevents the quick XOR that someone will otherwise write for a config blob at 5pm.
8. Name the trust boundary explicitly in the input-validation rule and tie it to the fuzzing targets. This is the rule that connects the coding standard to the threat model, and it is the connection that makes both documents worth having.
9. Add the small rules that only matter in security code: fail closed with a single generic error, constant-time comparison on secrets, no secrets in logs at any level, zeroise key material with a barrier the compiler cannot optimise away.
10. Finish with the reviewer's brief. Four questions about untrusted input, trust transitions, failure paths and attack surface. Without it, security review means whatever the reviewer had time for that afternoon, which is usually style.

4. Done when

• Every rule states whether it is enforced by pipeline or by review.
• The MISRA category treatment is explicit, and deviations require a marker, a reason, a containment and a named approver.
• Banned constructs fail the build rather than the reviewer's patience.
• Secret scanning covers branch history and triggers a rotation assessment on a hit.
• The parsers named in the threat model are the fuzzing targets named here.
• Security-relevant changes have a defined additional approver and a written reviewer's brief.

5. Common mistakes

Adopting MISRA without saying which categories bind. Deviation by blanket suppression. Applying the standard to vendored third-party trees, which guarantees it is ignored. Scanning only the diff for secrets. Banning constructs the pipeline does not check, so the ban lives on trust. And writing a comprehensive standard nobody finishes reading — length is not rigour, and an unread rule enforces nothing.

6. In TRA Studio

The essential requirement about shipping without known exploitable vulnerabilities is one that teams routinely mark as covered by "we do code review". Assign it instead to the specific activities that produce records — the static-analysis stage, the dependency scan, the review approval — because those are what you will be asked to show. A requirement mapped to a practice has no evidence behind it; a requirement mapped to a pipeline stage has one per build.