SDLC Best Practices

The cost of fixing a security flaw rises sharply with how late it’s found: a design flaw caught in a whiteboard session is a conversation; the same flaw caught in production is an incident. Secure SDLC is the practice of moving that discovery earlier. The trap is treating it as a set of gates to pass rather than a set of decisions to make, at which point it becomes theater engineering learns to route around.

In this subsection:

• Threat Modeling: the data-flow diagram and its trust boundaries, STRIDE, attack trees, PASTA, and the threat library that decides which branches deserve the effort.

Threat modeling, and when it’s actually worth it

Threat modeling asks four questions about a design: what are we building, what can go wrong, what are we doing about it, and did we do a good job. The methodologies (STRIDE, PASTA, attack trees) are structured ways to answer the second, and they get their own page. What stays here is the decision that comes first.

The honest part is when it’s worth it, because threat modeling every user story is how the practice dies:

• Worth it: new trust boundaries, authentication and authorization changes, anything handling money or sensitive data, new external interfaces, cryptographic decisions.
• Not worth it: internal refactors with no boundary change, UI-only work, low-risk CRUD behind existing controls.

The prioritization instinct applies: spend the modeling effort where the blast radius is largest, and let the rest go. A lightweight, frequent practice on the things that matter beats a heavyweight one that happens twice a year because it’s too expensive to do more often.

Security requirements and abuse cases

Most requirements describe what the system should do for a cooperative user. Abuse cases describe what it must not do for a hostile one, and writing them is where a lot of design- stage security lives.

User story: A user can reset their password via an emailed link.

Abuse cases: An attacker cannot trigger resets for other users’ accounts; cannot reuse a consumed link; cannot use an expired one; cannot enumerate valid emails through response differences; cannot race two links.

The abuse cases become the security acceptance criteria, testable and specific enough that “done” means something. This is the same discipline as abuse cases in red-team objectives, applied at design time instead of against production.

Design review gates

A design review gate is a checkpoint where a design is examined for security before it’s built. It works only if two things are true: it’s lightweight enough that people bring designs voluntarily, and it adds value rather than just friction. A gate that reliably finds nothing gets optimized away, correctly.

Make it collaborative rather than adversarial. A review that helps engineers ship safely gets used; one that blocks them gets circumvented, and circumvented security is worse than absent security because it looks present. The output is decisions and follow-ups, not a sign-off.

Secure code review

Distinct from automated scanning: a human reading code for the flaws tools miss: authorization gaps, business-logic errors, misuse of crypto, the fail-open path. Where to concentrate finite attention:

• Trust boundaries: where untrusted data enters, where privilege changes.
• Authentication and authorization: the highest-value and least automatable.
• Anything handling secrets, money, or personal data.
• The security-relevant diff, not the whole codebase: review changes, at the boundary.

The reviewer’s advantage over a scanner is understanding intent. A tool sees code; a reviewer sees what the code is trying to do and where that intent has a hole.

Shift-left versus shift-everywhere, honestly

“Shift left” — move security earlier — is directionally right and frequently overstated into a myth: that finding everything early removes the need for later controls. It doesn’t, and believing it creates blind spots.

The honest version is shift everywhere. Different flaws are catchable at different stages, and no single stage catches all:

• Design catches architectural flaws: threat modeling. Nothing downstream catches a fundamentally broken trust model cheaply.
• Code catches implementation flaws: review and SAST.
• Build catches dependency and pipeline risk: SCA and CI security.
• Runtime catches what everything before it missed: DAST, detection, and the pentest.

Shifting left is about adding early stages, not deleting late ones. A design flaw is cheapest at design and a configuration flaw may only be visible at runtime, so you need coverage across the lifecycle, and the real skill is matching the check to the stage where it’s cheapest and most reliable.

How it looks in practice

A working secure SDLC leaves its artifacts in the tools engineering already uses, and that’s the test for whether it’s real:

• The worth-it triage runs itself. The ticket template carries a short risk screen (new trust boundary, auth change, sensitive data) and a yes routes the design to a threat model. Nobody decides per-story whether modeling applies; the template does.
• Threat models live beside the code, as markdown in the repository, updated when the diagram they describe changes. A model in a wiki nobody reopens is a record of a meeting, never a control.
• Abuse cases sit in the acceptance criteria of the same story, so “done” includes the hostile-user behavior and the tests that pin it.
• The review gate is a standing half-hour, cheap enough that teams bring designs early and voluntarily. The version that requires scheduling ceremony is the version that gets routed around.

Where this connects

The requirements this produces are secure-coding practices made explicit, and its abuse cases are pentest scope written early. Secure SDLC is also a control requirement in GRC frameworks, where the risk is that it becomes a documented process that satisfies an auditor and changes no code.