Can You Trust a Closed-Source Security Scanner?

It is a fair worry. You are about to run a binary you cannot read inside your build, and it is a security tool, which means it touches all of your source. “Trust us” is not an answer, and you should not accept it as one. The good news is that trust in a closed-source tool is not a vibe. It is a checklist, and a serious vendor can meet every item on it.

What a trustworthy closed-source scanner owes you

Four things, concretely:

• A signed bill of materials. You should be able to see every component inside the tool and verify that the list was not tampered with. A software bill of materials answers “what is actually in this binary,” and a signature answers “and who says so.”
• Complete third-party attribution. Every open-source component the tool depends on should be named, with its license. No anonymous code riding along.
• No surprise copyleft. A tool you embed in a commercial pipeline should not carry a license that reaches back into your build. You should be able to confirm that, not hope it.
• Local, offline analysis. Your source is the most sensitive thing you own. A scanner worth trusting analyzes it on your machine and does not need to phone home to do its job.

If a closed-source vendor cannot produce those four, the objection to closed source is correct and you should walk. If it can, the objection dissolves.

How TheAuditor meets each item

We built to that checklist on purpose, because we are closed source and we know the burden of proof is on us.

• The bill of materials is signed and it ships. Every release includes a CycloneDX software bill of materials, GPG-signed. You can list what is inside the artifact and verify the signature before you run anything.
• Third-party components are fully attributed. The complete license inventory travels with the release, on the order of roughly 130 components, each named with its license. There is no unattributed code in the binary.
• No copyleft obligation reaches into your codebase. We removed the last unconditional copyleft dependency. The one stricter-licensed component that still ships carries an explicit exception permitting closed-source use, and the license inventory is how you confirm that for yourself rather than taking our word.
• Analysis runs offline. The engine does its work locally. Your source never has to leave your machine for the scan to complete. aud full --offline is not a special mode, it is how it is meant to run.

Each of those is an artifact you can inspect, not a promise in a sales deck.

Closed source as a feature, not an apology

Here is the turn. Once the bill of materials is signed, the attribution is complete, the copyleft obligation is gone, and the analysis is local, closed source stops being the liability and starts being the point. The implementation is a trade secret, which is exactly what keeps the engine ahead of the checkers it competes with, and none of that secrecy costs you the supply-chain hygiene an open tool would give you. You get the auditability without the vendor having to publish the one thing that makes the tool worth buying.

The right question was never “open or closed.” It was “can you prove what is in the box, and does it keep your code to itself.” A closed tool can answer both, and this one does.

Honest scope note

Signed provenance tells you what is in the binary and that its supply chain is clean. It does not, by itself, prove the analysis inside is any good. That is a separate claim, and we keep it separate on purpose: coverage is measured against an independent yardstick at BenchProctor, not asserted here. Trust the SBOM for supply-chain questions and trust the benchmark for accuracy questions. Do not let either stand in for the other.

Where this sits

TheAuditor is the ground-truth layer for Code Reality Labs: closed engine, open supply chain, proven honest by BenchProctor. TheAuditor 5.0 is in final commercial release preparation and ships when its hardening checks pass. Subscribe on the main site for launch news.