Most security programs fail not because the tools are bad but because they are bolted on at the end, where they generate friction, false positives and resentment. A secure software development lifecycle (SDLC) that actually works moves security earlier (shift left) without becoming the thing engineering routes around. This article lays out a practical, opinionated approach: threat modelling at design time, paved road defaults that make the secure path the easy path, layered CI gates, and risk based gating instead of blanket blocking.
The principle: make secure the default, not the chore
Shift left is often misread as shift the blame, where developers are handed a scanner, drowned in findings, and told to fix everything before merge. That approach reliably slows delivery and trains people to ignore security alerts. The better framing is to make the secure choice the default choice. If your platform team ships a paved road (vetted base images, pre configured frameworks with safe defaults, libraries that handle auth and crypto correctly), most vulnerabilities never get written in the first place. Security tooling then catches the exceptions rather than policing every line.
Design phase: lightweight threat modelling
The cheapest vulnerability to fix is the one caught on a whiteboard. Threat modelling does not need to be a heavyweight, multi day ceremony. For most features a thirty to sixty minute session answering four questions is enough: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job.
Practical tips that keep it from becoming theatre:
- Trigger a threat model only for changes that touch trust boundaries, authentication, authorisation, payment, or sensitive data. Routine CRUD does not need one.
- Use a simple data flow diagram and the STRIDE prompts (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a checklist.
- Capture decisions as tickets in the same backlog engineers already use, not in a separate document nobody reads.
- Keep a reusable library of threat models for common patterns so teams start from a template.
Paved road: secure defaults engineers want to use
A paved road is the set of golden paths your platform team supports and secures. When a team uses the paved road, they inherit security for free: hardened base images that are patched centrally, service templates with authentication and structured logging wired in, secret management integrated so credentials never live in code, and infrastructure modules that are compliant by construction.
The strategic value is leverage. Instead of asking hundreds of engineers to remember dozens of controls, you encode those controls once in the road. Adoption follows because the paved road is genuinely the fastest way to ship. Security becomes a property of the platform rather than a tax on the developer.
CI gates: layered scanning that respects developer time
Automated scanning belongs in the pipeline, but layering matters. Run fast, high signal checks early and reserve slower, deeper analysis for later stages so you never block a developer on a long scan.
Pre-commit and local
Secrets detection and basic linters belong at pre-commit, before code even leaves the laptop. Catching a cloud access key before it is pushed is far cheaper than rotating it after it lands in git history.
Pull request / CI
- SAST (static application security testing): tuned to your stack, with rules curated to suppress the noise that erodes trust. A SAST tool that cries wolf is worse than no SAST.
- SCA (software composition analysis): scan dependencies for known vulnerable versions, and pay attention to transitive dependencies, which are where most real exposure lives.
- Secrets scanning: a second net in CI for anything that slipped past pre-commit.
- IaC scanning: check Terraform, Kubernetes manifests and cloud templates for misconfigurations such as public buckets, permissive security groups and missing encryption.
Deeper, asynchronous checks
DAST against a staging environment, container image scanning and licence compliance can run out of band, posting results back to the team without blocking the merge. The goal is fast feedback where it changes behaviour and thorough feedback where time allows.
Risk based gating, not blanket blocking
The fastest way to lose engineering trust is to fail every build on every finding. Mature programs gate on risk. A critical, reachable, exploitable vulnerability in a dependency that is actually called should block. A medium severity finding in dead code, or a false positive, should not. Reachability analysis, severity, exploit availability and exposure (internet facing versus internal) all feed the decision.
Set a clear policy: block on critical and high confidence findings that meet defined criteria, warn on the rest, and track everything so debt does not accumulate silently. Pair the policy with sensible SLAs (for example, criticals fixed in days, highs in weeks) and a frictionless exception process with an owner and an expiry. Exceptions that never expire are how risk quietly piles up.
AppSec champions: scaling the team you do not have
A central security team cannot review every change. The champions model embeds a trained, interested engineer in each team to be the first point of contact, run lightweight threat models, triage findings and escalate the genuinely hard problems. It scales security culture far better than headcount alone, and it keeps decisions close to the people who understand the code.
Takeaways
A secure SDLC that engineers adopt is built on defaults, not gates. Threat model the risky changes, give teams a paved road so most vulnerabilities are never written, layer your CI checks so feedback is fast and deep in the right places, and gate on risk rather than blocking on noise. Champions spread the load and the culture. Done well, security stops being the team that says no and becomes the team that makes shipping safe code the path of least resistance. Basalt Cyber helps organisations design and stand up programs like this; learn more on our services page.
FAQ
Where do we start if we have nothing? Start with secrets scanning and SCA in CI. They are low effort, high value, and rarely controversial. Add SAST and threat modelling once the basics are smooth.
How do we stop SAST noise from killing adoption? Curate the ruleset to your stack, suppress known false positives, and only gate on a small, high confidence subset. Treat the rest as advisory.