Secure Development: Threat Modelling, Code Review and the Pipeline
Security bolted on at the end is a penetration test report nobody has time to act on. Where to intervene in the lifecycle, and what code review can and cannot find.
GuardsArm Team
Security Experts
The usual model is to build the thing, test it at the end, and receive a list of findings when the release date has already been committed. Most of that list is then accepted as risk, because fixing an architectural flaw a week before launch is not a realistic ask.
Moving security earlier is not about buying scanners. It is about intervening at the points where a decision is still cheap to change.
Where to intervene
Threat modelling is the highest-value activity and needs no tooling. Sit with the design and ask: what are we building, what can go wrong, what are we doing about it, and did we do a good enough job. An hour on a new feature catches the authorisation flaw that no scanner will ever find.
What code review can and cannot find
Secure code review is effective for a specific set of problems and blind to another.
| Finds well | Finds poorly |
|---|---|
| Injection where input reaches a sink | Broken authorisation logic |
| Hardcoded secrets | Business logic flaws |
| Weak cryptographic choices | Race conditions |
| Missing input validation | Design-level trust failures |
| Unsafe deserialisation | Anything requiring system-wide context |
The right-hand column is where the serious findings live. An attacker changing an identifier in a request and reading another patient's record is not a coding error a reviewer spots in a diff — it is a design question, which is why threat modelling matters more than review volume.
Make review practical: review high-risk changes rather than everything, give reviewers a checklist tied to your own threat model, and treat it as knowledge transfer rather than gatekeeping.
Pipeline gates, chosen carefully
Every gate is friction. Friction that developers consider unreasonable gets bypassed, and then you have neither the control nor the visibility.
| Check | Block the build? |
|---|---|
| Secret detected in the commit | Yes — unambiguous and urgent |
| Critical dependency vulnerability, reachable | Yes |
| Known-exploited vulnerability in a dependency | Yes |
| High-confidence SAST finding in new code | Yes |
| Medium/low SAST findings | No — report, track, fix on a schedule |
| Any finding in legacy code untouched by this change | No — separate backlog |
| DAST findings | No — too slow and noisy for a build gate |
Dependencies are most of your code
Your own code is a minority of what ships. Dependency scanning belongs in the build, and the results need prioritising by reachability — a vulnerability in a function you never call is not the same as one in your request path. See supply chain security.
For healthcare applications
Anything touching PHI carries specific obligations that generic secure development guidance omits:
- Authorisation testing is the priority. The most common serious finding in clinical applications is one patient's record reachable by changing an identifier. Test it deliberately for every endpoint.
- Audit logging is a feature, not a cross-cutting afterthought. Record-level access must be logged in a form that satisfies the Security Rule — build it in, and test that it captures what it should.
- Non-production must not hold real PHI, or must be protected as production.
- De-identification, where used, needs verifying rather than trusting a library's defaults.
Where to start
Threat model one upcoming feature that touches patient data. An hour, a whiteboard, and the four questions. It requires no procurement and it will surface something — and it is the fastest way to show the team that security work at design time is cheaper than a finding later.
GuardsArm reviews secure development practices and tests clinical applications for authorisation flaws that scanners miss. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on this topic
Talk to the GuardsArm team about how these services apply to your environment.
