Read an independent review by asking five things: who paid for it, what exactly was tested, how correct answers were defined, whether the test can be repeated, and whether the findings fit your own stack. A review that cannot answer these is an opinion, not evidence.
Start with who paid and who benefits
Independence is a spectrum. A reviewer may be funded by readers, by advertisers, by affiliate commissions, by a vendor, or by nobody. None of these is automatically disqualifying, but each changes how you read the result.
Look for a disclosure near the top of the piece. The US Federal Trade Commission says a material connection, such as free or discounted products or any financial relationship, should be disclosed in a way that is hard to miss and placed with the endorsement itself. A note buried in an About page or at the foot of a post is not what the FTC describes as adequate. If you cannot find any disclosure, treat that as information.
Ask what was actually tested
Many reviews describe features. Fewer describe behavior. Check whether the reviewer ran the tool or only read the product page. Check the version, the date, the configuration, and the targets. A scan of one sample app tells you about that app.
Write down the sample. Was it a purpose-built test application, a real open source project, or code the reviewer wrote? Each answers a different question, and none answers how the tool behaves on your repositories.
Ask how correct was defined
A scanner result is only meaningful against a known answer. Good reviews say which vulnerabilities were present on purpose, who confirmed them, and how a finding was counted as right or wrong. Without that, a count of findings is just a count.
Look for both kinds of error: findings the tool missed and findings it raised that were not real. A review that reports only the first or only the second is half a review.
Ask whether you could repeat it
A fair test is repeatable. The reviewer should name the inputs well enough that a reader could run the same test and get similar results. Be careful with reviews that give scores but no method. Also be careful with results that were run once, since scanners can vary with configuration, rule updates and network conditions.
Match it to your situation
Even a careful review is generic. Your languages, frameworks, build system and team size matter more than a headline score. Use the review to build a shortlist and a list of questions, then test the shortlist yourself. Our guide to running your own bake-off covers that step.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and note what evidence the tool shows. That is the same evidence you should expect a reviewer to show you.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates. If you want a candidate to include in your own test, there is a free scan at gold.safeguard.sh/scan.
Quick check
Is a vendor-funded review always useless?
No. It can still contain accurate methods and data. It needs more scrutiny, and a clear disclosure, because the funder has an interest in the outcome.
What is the single most useful question to ask?
How did the reviewer know which findings were correct? If there is no answer, the numbers cannot be trusted.
Sources
Last reviewed: 19 October 2026.
