Before buying a security scanner, make sure five things exist: an inventory of repositories, protected main branches with required review, multi-factor sign-in on core systems, a named owner for findings, and a tracker where findings land. A scanner without these produces reports that nobody acts on.
Why order matters
A scanner is a source of work. If the surrounding system cannot absorb work, the scanner adds frustration instead of safety. Teams often buy a tool in a panic after a customer question and then find that nobody can say which repositories to point it at.
The five preconditions
1. An inventory
You cannot scan what you have not listed. Pull the repository list from your source host, mark which ones are deployed, and note the language or build system. Unknown repositories are the first thing to chase.
2. Protected branches and review
Findings are most useful at pull request time. That works when pull requests are mandatory. GitHub's documentation lists settings such as required pull request reviews and required status checks, and notes that rules do not apply to admins by default unless you choose to enforce them. A gate that admins can skip silently is not a gate.
3. Multi-factor sign-in
An excellent scanner does nothing about a stolen password to the source host. Turn on multi-factor sign-in for identity, source control and cloud first.
4. A named owner
Someone must decide what to do when a critical finding conflicts with a deadline. See the post on who owns security with no security team for a simple split.
5. A tracker
Findings need a home with status and owner fields, whether that is your issue tracker or the tool itself. If you cannot say how a finding gets closed, you are not ready to open one.
A quick readiness table
| Precondition | Test | Ready? |
|---|---|---|
| Inventory | Can you list every deployed repo from a document, not from one person's memory? | |
| Branch protection | Does a direct push to main fail for everyone? | |
| Multi-factor | Is it enforced, not just offered? | |
| Owner | Does the name appear in the handbook? | |
| Tracker | Can you show one finding's history? |
Try it yourself
This demo walks through a vulnerability management workflow from finding to fix. Click through the stages and note where an owner and a status are needed. Those are the fields your tracker must support.
Click through it at your own pace, or open it full screen.
What to ask the vendor once you are ready
Ask how findings are deduplicated, how ownership is assigned, how noisy rules can be tuned, and what happens to a finding after a fix merges. Run any trial on one real repository, with real developers, before committing.
Safeguard covers dependency scanning, reachability analysis and policies and gates, and the free scan gives a first look at one repository without a commitment.
Quick check
Is it wrong to buy a scanner first?
Not wrong, but it often wastes the first months. If you buy first, treat the preconditions as the first project.
Which precondition matters most?
Ownership. Without someone who can decide, the other four stall at the first conflict with a deadline.
Sources
Last reviewed: 19 October 2026.
