Fast, Deep, or Proactive: Choosing the Right Scan for the Moment
Not every scan should look the same, and treating them as if they should is where a lot of security tooling goes wrong. A scan running as a pre-merge check has completely different constraints than a scan run once before a major release, and both of those are different again from the kind of scanning a security team wants running quietly in the background all the time, looking for things nobody asked it to look for yet. A platform that only offers one scan speed forces every one of those situations into the same box, which usually means either CI gets slow enough that developers start looking for ways around it, or thorough analysis gets skipped because nobody wants to wait for it.
Safeguard addresses this directly with three scan modes: Fast, Deep, and Proactive. Each is built for a different point in the development lifecycle, and understanding when to reach for which one is most of what it takes to use them well.
Fast: quick feedback in CI
Fast mode is built for the moment where speed is the whole point. When a developer opens a pull request, or a pipeline runs a pre-merge check, the goal is to surface anything urgent before the change lands, without making the developer wait so long that the check becomes something to route around. This is the mode for continuous integration and pre-merge gates: the scan that runs every time, on every change, quickly enough that it fits naturally into a developer's normal workflow rather than becoming a bottleneck they learn to dread.
The tradeoff here is one every security team recognizes intuitively even if nobody says it out loud: a scan that must return quickly cannot do everything a slower, more exhaustive scan can do. Fast mode is the right tool when the goal is catching known, well-understood issues before they merge, not when the goal is exhaustive research into a codebase's less obvious vulnerabilities. That is a reasonable and deliberate tradeoff, not a shortcoming, because the alternative, a CI gate that takes twenty minutes, is a gate that teams will find ways to bypass.
Deep: full transitive analysis before it matters most
Deep mode is built for the moments where thoroughness matters more than turnaround time: a full transitive analysis, suited to a pre-release scan where the team wants to know, as completely as the platform can determine, what is actually in the software before it ships. This is the mode for a release gate, a periodic full-codebase audit, or any moment where the organization has decided that the extra time is worth it because the stakes of missing something are higher than the stakes of waiting a bit longer for the answer.
A team might run Fast mode on every single commit throughout a sprint, and then run Deep mode once, deliberately, before a release goes out or before an audit. That combination, quick checks constantly plus one thorough pass at the moments that matter most, mirrors how most mature engineering organizations already think about testing in general: unit tests on every commit, a fuller regression suite before a release.
Proactive: continuous background research
Proactive mode is different in kind from the other two, because it is not tied to a specific commit or release at all. It is built for continuous background research and a zero-day discovery posture: the scanning that happens on its own schedule, independent of whether anyone just pushed code, looking for the kind of issue that a point-in-time scan would never catch because it did not exist as a known problem at the moment the last scan ran.
This is the mode that fits a security team's ongoing posture rather than a specific developer action. A team is not going to sit and wait on Proactive mode the way they wait on a CI check. It runs in the background, continuously, and its value shows up over time as new findings surface between the moments when someone would have otherwise thought to look.
Choosing based on where you are, not just what you want
The honest way to think about these three modes is less "which one is best" and more "which moment am I in." A developer pushing a small change wants Fast. A team about to cut a release wants Deep. A security function responsible for the organization's ongoing posture wants Proactive running continuously in the background, independent of any single change. Most mature Safeguard deployments end up using all three at once, each doing the job it is suited for, rather than trying to make one mode serve every purpose.
That layered approach, quick checks constantly, thorough checks at the moments that matter, and continuous background research running underneath both, is a more realistic model of how security scanning should fit into a real engineering organization than a single scan speed ever could be. It respects that a developer's time in CI is not the same resource as a security team's time reviewing a pre-release report, and it does not ask either one to pretend otherwise.
If you are trying to work out where Fast, Deep, and Proactive scanning fit into your own pipeline and audit cadence, safeguard.sh is a good place to start scoping that out.
