To inventory your security tools, build one sheet with a row per tool and columns for owner, what it scans, who actually uses it, where it runs, contract end date and what it produces. Source the rows from finance records, SSO app lists and CI configs, not from memory. Consolidation decisions come after this list exists.
Why start here
Most teams that think about consolidation already own more than they remember. A scanner bought for one project, a trial that turned into a subscription, a free plugin a team installed years ago. Until those are visible, any plan to replace several tools with one is a guess.
Where to find the tools
Ask three sources, because each misses something the others catch.
- Finance: card statements and purchase orders show paid tools, including ones security never approved.
- Identity: the SSO or OAuth app list shows tools people log in to or have granted repository access.
- Engineering: search CI files, pre-commit configs and IDE extension lists for scanner commands and plugins.
A fourth source is repository settings. Webhooks and installed apps on your code host often reveal a tool nobody listed.
What to record per tool
| Column | Why it matters |
|---|---|
| Owner (a named person) | Someone must approve any change |
| What it checks | Dependencies, code, containers, infrastructure files, secrets, running apps |
| Where it runs | IDE, pull request, CI, scheduled, production |
| Who reads the output | A tool nobody reads is a candidate to cut |
| Last time a finding led to a fix | Usage evidence, not licence counts |
| Contract end and notice date | Sets the earliest clean exit |
| Export options | Decides how hard leaving will be |
Keep the sheet small. If a column takes more than a few minutes per tool to fill, drop it.
Mark usage honestly
Licence counts say little. Look for the last pull request where a finding from that tool changed what a developer did. If you cannot find one, note it as unproven rather than unused, and ask the owner.
What to do with the result
Group tools by what they check. Two tools in one group are an overlap to examine. A group with no tool is a gap. Then move on to a coverage matrix, covered in our post on checking coverage before you retire a scanner.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the dependency inventory and notice how one list per project makes duplicates easy to spot. Your tool inventory should work the same way.
Quick check
How often should the tool inventory be refreshed?
Review it at least once a year and again whenever a contract nears its notice date. Add a line to your vendor onboarding checklist so new tools land in the sheet on day one.
Who should own the sheet?
The security or AppSec lead, with finance and engineering confirming their parts. One owner keeps it from going stale.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
