What you will take away
- A finding is cheapest at the pull request and most expensive in production.
- Noisy scanners get ignored - start with a short list of rules that block.
- Most real incidents start with dependencies, secrets or misconfigured infrastructure.
Why the end-of-project audit fails
The traditional model runs a penetration test a fortnight before launch. It produces a document, the document produces a scramble, and the fixes are applied under deadline pressure to a codebase designed around different assumptions. Architectural findings - the wrong trust boundary, a session model that cannot support revocation - arrive far too late to act on.
Moving the checks earlier is not about running more tools. It is about the cost curve. A finding at the pull request costs minutes, at staging it costs hours, and in production it costs a disclosure process.
The four checks worth having on day one
- Dependency scanning on every build, with a policy that a known-exploited vulnerability blocks the merge and everything else opens a ticket.
- Secret detection on commit and across history, plus a rotation runbook - detection without rotation is theatre.
- Static analysis tuned down to a handful of high-confidence rules, expanded only once the team trusts it.
- Infrastructure-as-code policy checks, which catch the public storage bucket and the wide-open security group before they exist.
That set covers the majority of real-world incidents we are asked to investigate. Container image scanning and dynamic testing against a running staging environment follow once the basics are green and stable.
Tuning for signal
The fastest way to kill a security programme is to turn on every rule at once. A pipeline that fails on three hundred informational findings teaches the team exactly one lesson: the security step is the thing you rerun until it passes.
A scanner nobody reads is worse than no scanner. It buys the feeling of coverage without the coverage.
Start with rules that block, and keep that list short enough to fit on a slide. Everything else reports into a backlog with an owner and a due date. Review the ratio monthly: if the blocking list never fires it is too narrow, and if it fires on every build it is not tuned.
Threat modelling without the ceremony
Threat modelling has a reputation for week-long workshops and diagrams nobody revisits. In practice, one hour per significant feature covers most of the value: what data does this touch, who should be able to reach it, what happens if the caller is not who they claim to be, and what does an attacker gain by breaking it.
Write the answers next to the design, not in a separate system. The point is that the person implementing the feature has already thought about the abuse case, which is something no scanner will do for them.
Runtime is where the story ends
Pipeline checks cover code and configuration; they do not cover behaviour. You still need audit logging on privileged actions, alerting on authentication anomalies, and a tested response plan that names who decides to take a system offline.
For regulated clients we tie these together so evidence is a by-product of the pipeline rather than a project of its own: the scan results, the approvals and the deployment records are already the audit trail.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
