Ask three pentesters on the same team which proxy, fuzzer, or exploitation framework they used to confirm an issue, and you will often get three different spellings of the same answer. One writes “Burp,” another writes “Burp Suite Pro,” a third types “burpsuite.” None of them is wrong, yet none of them is consistent. When that text lands on a finding, the inconsistency follows the work into reports, into client deliverables, and into any later attempt to measure how the team operates.
A security tool catalog solves that quietly. Instead of letting every analyst describe their instruments in free prose, PMAP maintains a shared, named list of the tools your practitioners actually use. When someone documents a finding, they pull from that list rather than retyping it. The catalog is small in surface area and large in payoff, because it turns an open text box into a controlled vocabulary that every engagement can rely on.
This article explains what the tool catalog is, how it is structured, and how it connects to the findings your team produces. It is a deliberate companion to the broader story of running assessments at scale, which is covered in the pillar guide on security assessment management. If you run a pentest practice or a consulting firm and you want your methodology to be repeatable rather than personal, the catalog is one of the unglamorous building blocks that makes repeatability possible.
What a Tool Catalog Is For
In PMAP the tool catalog is a global list of security tools. A tool is a named instrument. It might be a scanner, an exploitation framework, a proxy, a utility, or any other security product that a practitioner reaches for during an engagement. The catalog exists so that those instruments have one canonical name and one canonical record, rather than living as scattered strings inside individual findings.
The link to real work is direct. When an analyst or pentester documents a finding, the finding model carries a used_tools[] field. That field records which instruments were used to discover or validate the issue. The tool catalog provides the canonical list that populates that selection. The catalog does not own the finding, and the finding does not own the catalog. The two domains stay separate, and the catalog simply supplies the vocabulary that the finding consumes.
Two groups interact with it. Platform administrators maintain the catalog. They add tools, classify them, and retire the ones that fall out of use. Security analysts and pentesters read from it and select entries when they author findings. That division keeps authorship clean. Practitioners are not inventing new tool names mid-engagement, and administrators are not policing free text after the fact. The list is curated once and consumed many times.
It helps to be precise about what the catalog is not. It is not a scan engine, and it does not connect to your scanners to pull results. It has no dependency on scan data or tenant data at all. It is a reference list, nothing more and nothing less, and that narrow scope is exactly why it is dependable. A reference list that tries to do everything tends to do nothing well.
A Platform-Global, Shared Reference
The most important structural fact about the catalog is that it is platform-global. There is no company_id on the tool model and no tenant scope filter applied to it. Every tenant on the platform shares the same catalog. A tool added once is visible everywhere, and there is no per-company copy to drift out of sync.
For a multi-tenant practice this is a deliberate design choice rather than an oversight. A penetration testing firm that runs engagements for many clients does not want a separate Nmap entry for each customer. The instruments a team uses are a property of the team, not of any single client. Keeping the catalog global means the vocabulary your practitioners share is genuinely shared, and a finding written for one client reads the same way as a finding written for another.
The trade-off is worth stating plainly so you can plan around it. Because the catalog is global, you cannot scope a tool to a single company through this domain. If your business needs client-specific tooling lists, that distinction lives in how you organize findings and projects rather than in the catalog itself. For most assessment teams this is the right default, because the value of the catalog comes from everyone drawing on the same controlled list. A controlled vocabulary only controls anything when it is universal.
Globality also keeps maintenance honest. There is exactly one place to add a tool, one place to rename it, and one place to retire it. When a new framework enters your standard kit, an administrator adds it once and every engagement across the platform can reference it immediately. The single source of truth is literal here, not aspirational.
Classifying Tools by Category, Vendor and Tag
A flat list of names would still be an improvement over free text, but the catalog goes further by giving each tool a small set of classification fields. These fields are what turn a list into something you can search and reason about.
Each tool carries an optional category field for grouping. The category is how you separate a scanner from a proxy from an exploitation framework, so that a hundred-entry catalog does not collapse into an undifferentiated wall of names. Category is the coarse axis of organization, and it is the field most teams reach for first when they want to narrow a long list to a relevant subset.
Each tool also carries an optional vendor field that records the vendor or author of the tool. Vendor attribution matters for two reasons. It disambiguates tools that share a generic name, and it lets a team answer questions about who builds the instruments they depend on. If you are documenting your toolchain for a client or for an internal review, vendor attribution is the difference between “we used a scanner” and “we used a named product from a named vendor.” That specificity is often what a reviewer is actually asking for.
The third classification axis is tags. Every tool can carry a tags[] array, and the catalog list endpoint supports filtering by a single tag for fast subset retrieval. Tags give you a flexible, cross-cutting way to describe tools that does not fit neatly into a single category. A tool can be in the scanner category and still carry tags such as web, authenticated, or cloud, which lets you slice the catalog along whatever dimension a particular engagement cares about. Where category answers “what kind of thing is this,” tags answer “what is this useful for,” and the two together cover most of how practitioners actually think about their kit.
Tag Filtering That Stays Exact
It is worth being precise about how tag filtering behaves, because the behavior shapes how you should name your tags. Tag lookup uses an exact match against the tag array. A filter on a tag matches a tool only when that exact tag string appears in the tool’s tag list. There is no partial or substring matching for tags.
The practical consequence is that tag discipline pays off. If half your tools are tagged web-app and the other half are tagged webapp, a filter on either tag will return only half the set, and the gap is invisible until you go looking for it. Because the match is exact rather than fuzzy, a small tagging convention agreed up front saves a great deal of confusion later. Pick a spelling, write it down, and keep to it. The exactness is a feature, not a limitation, but it is a feature that rewards consistency and punishes drift.
Exact matching also keeps filtering fast and predictable. There is no guessing about what a query will return, and there is no surprise where a filter on sql quietly also pulls in nosql or sqlmap. The tag you ask for is the tag you get, which is precisely the property you want from a vocabulary that other people’s findings depend on.
Linking Tools to Findings With used_tools
The catalog earns its keep at the moment a practitioner documents a finding. The finding model consumes the catalog through a used_tools[] string array. When an analyst records how they discovered or validated an issue, they list the instruments they used, and those instruments come from the catalog.
The shape of this relationship is worth understanding because it explains why the catalog can stay so simple. The finding stores tool names as a free-text string array. The catalog is the canonical source that populates the picker behind that array. In other words, the catalog supplies the controlled list, and the finding records the practitioner’s selection from it. The two are connected by name, and that loose coupling is intentional. It means the catalog can evolve without breaking historical findings, and findings can carry tool references without holding a hard dependency on a catalog record.
This design gives you the consistency benefits of a controlled vocabulary without making the catalog a single point of failure for finding authorship. A practitioner is guided toward canonical names, which is where the value lives, while the finding itself remains a self-contained record of what was used. When you later read a finding, the tools listed on it mean the same thing they meant on every other finding, because they were drawn from the same shared list.
For a pentest team this is the difference between deliverables that look authored by one methodology and deliverables that look authored by whoever happened to be on the engagement. Standardizing the tools your team documents on every finding is a small habit with an outsized effect on how professional and how comparable your output becomes. It is also the kind of standardization that pays compound interest, because every engagement that uses the shared vocabulary makes the next engagement easier to read.
Retiring a Tool Without Losing History
Tools fall out of favor. A framework gets deprecated, a proxy is replaced by a newer one, or a utility simply stops being part of your standard kit. The naive response is to delete the old entry from the catalog. That is exactly what you should not do, and the catalog gives you a better option.
Every tool carries an is_active boolean. New tools are always created as active. When a tool should no longer appear as a current choice, an administrator sets it to inactive rather than deleting it. This soft-disable retires the tool from active use while keeping historical references intact. The point is preservation. Findings authored months ago may reference a tool that your team no longer uses. If you hard-deleted that tool, you would not erase the string on those old findings, but you would lose the catalog record that gives the string its context. Soft-disabling keeps the record in place, so the history stays coherent.
The catalog does also support a hard delete for cases where an entry was created in error and was never used. The judgment call is straightforward. If a tool was ever referenced on real findings, retire it with the active flag and leave the history alone. If it was a mistaken entry with no consequence, delete it. The active flag is the right tool for the common case, and deletion is the exception you reach for rarely.
Retirement through the active flag also keeps the working catalog clean without rewriting the past. Practitioners authoring new findings see the current, relevant set of tools, while anyone auditing older work still finds every instrument accounted for. You get a tidy present and an honest record at the same time, which is exactly what a methodology-driven team needs when a client or a regulator asks how a finding was reached two years ago.
URL and Website Metadata for Documentation
Beyond classification, each tool can carry a small amount of reference metadata. The catalog supports optional url and website fields, intended for linking to tool documentation or download pages.
These fields are modest, but they close a real gap. When a newer analyst sees an unfamiliar tool referenced on a finding, the website or documentation link turns the catalog entry into a starting point for learning rather than a dead end. It also helps when you are preparing client-facing material and want to point a reader to the authoritative source for a given instrument. The metadata is optional precisely because not every tool needs it, and the catalog does not force you to fill in fields that add no value for a particular entry.
Think of these links as the difference between a name and a reference. A name tells you what was used. A documentation link tells you where to go to understand it. For a growing team, that second piece is part of how institutional knowledge gets passed along without a senior practitioner having to explain the same tool a dozen times. The catalog quietly becomes a teaching surface in addition to a vocabulary.
Where the Tool Catalog Sits Versus the Vendor Marketplace
This is the distinction that matters most, because it is the one most easily confused. PMAP has two different things that both involve the word “tools,” and they do entirely different jobs.
The tool catalog described here is a documentation reference. It is a platform-level list of named instruments that practitioners cite on findings. It does not connect to anything, it does not pull results, and it does not run scans. It is vocabulary.
The vendor marketplace is something else entirely. That is the integration layer, where PMAP connects to live security products such as Nessus, Tenable, Qualys, Snyk, Jira, and GitHub through configured connectors that pull results, sync tickets, and import assets. Those connectors are operational. They move data between PMAP and external systems on a schedule or on a trigger. If you want the full picture of how PMAP connects to live vendors across categories, that is the vendor marketplace, and it is a separate story from this one.
The clean way to hold the difference in your head is this. The vendor marketplace is about machines talking to machines. The tool catalog is about humans naming the instruments they used by hand. A connector to Tenable imports vulnerabilities automatically. A catalog entry for a manual exploitation framework records that a human used it. Both belong in a mature assessment platform, and they do not overlap. Conflating them leads to the wrong expectations in both directions, so it is worth keeping the line bright. The catalog will never scan your network, and the marketplace will never be the place where a pentester records the proxy they ran by hand.
How the Tool Catalog Supports Assessments at Scale
Step back and the catalog stops looking like a minor feature and starts looking like an enabler of methodology. Assessment work at scale lives or dies on consistency. A finding written by one analyst should be readable, comparable, and trustworthy alongside a finding written by another, and the tools cited on those findings are part of what makes them comparable.
The catalog contributes to that consistency in a few concrete ways. It gives every practitioner the same controlled vocabulary, so tool names mean the same thing across engagements. It classifies tools by category, vendor, and tag, so the catalog stays navigable as it grows. It preserves history through soft retirement, so old findings remain coherent even as your kit evolves. And it stays narrowly scoped, so it is dependable rather than fragile. None of these properties is dramatic on its own. Together they are the difference between a tooling reference you trust and one you have to second-guess.
For a consulting or pentest firm, this is the foundation that lets a team grow without losing its voice. New analysts inherit the established vocabulary instead of inventing their own. Engagement deliverables read consistently because they draw on the same instruments named the same way. And when a client asks how a finding was reached, the answer is specific and standardized rather than improvised. If you want to see how this fits into planning and running engagements end to end, the pillar guide on security assessment management puts the catalog in its operational context, and the companion pieces on planning a pentest project and on PMAP for pentest and consulting firms show the same discipline applied across an engagement.
The tool catalog will never be the headline feature of a platform demo. It does not need to be. It is the kind of quiet infrastructure that you stop noticing precisely because it is working, and a methodology-driven team feels its absence far more than its presence. Standardize the instruments your practitioners cite, retire the old ones without erasing the past, and let every finding speak the same language. That is the whole job, and the catalog does it well.
Ready to standardize your tooling? Standardize the tools your team documents on every finding. Explore PMAP assessment management to see how the catalog fits the larger workflow.
Frequently Asked Questions
What is the security tool catalog in PMAP?
It is a global list of named security tools, including scanners, exploitation frameworks, proxies, and utilities, that practitioners reference when documenting their work. Each tool is a canonical record with a name, optional category, vendor, tags, and documentation links. When an analyst authors a finding, they select instruments from this catalog rather than typing free text, which keeps tool references consistent across every engagement.
How is the tool catalog different from the vendor marketplace?
The tool catalog is a documentation reference. It is a platform-level list of named instruments that practitioners cite on findings, and it does not connect to any external system. The vendor marketplace is the integration layer, where PMAP connects to live products such as Nessus, Qualys, Jira, and GitHub through connectors that pull results and sync data. In short, the catalog is human-authored vocabulary, while the marketplace is machine-to-machine integration. They serve different purposes and do not overlap.
Is the tool catalog shared across all tenants or scoped per company?
It is platform-global. There is no company identifier on the tool model and no tenant scope applied, so every tenant on the platform shares the same catalog. A tool added once is visible everywhere, which gives a multi-tenant practice a single shared vocabulary rather than a separate list per client. The trade-off is that you cannot scope a tool to a single company through this domain, so client-specific distinctions live in how you organize findings and projects instead.
How are tools linked to findings?
Findings carry a used_tools[] string array. When a practitioner documents how they discovered or validated an issue, they list the instruments used, and those names are drawn from the catalog. The catalog supplies the canonical list that populates the picker, and the finding records the selection as a string array. This loose coupling means the catalog can evolve without breaking historical findings, while practitioners are still guided toward consistent names.
Can I retire a tool without deleting it?
Yes. Every tool has an active flag, and new tools are created as active. To retire a tool that is no longer part of your standard kit, an administrator sets it to inactive rather than deleting it. This soft-disable removes the tool from current choices while keeping historical references intact, so older findings that cite the tool stay coherent. A hard delete is available for entries created in error, but the active flag is the right approach whenever a tool was ever used on real findings.
How does tag filtering work in the catalog?
Each tool carries a tag array, and the list endpoint filters by a single tag using an exact match. A filter returns a tool only when that exact tag string appears in the tool’s tag list, with no partial or substring matching. This makes tag filtering fast and predictable, and it rewards a consistent tagging convention. If two tags differ only by spelling, such as web-app versus webapp, a filter on one will miss the other, so agreeing on tag names up front keeps your catalog reliable.
Who maintains the tool catalog?
Platform administrators maintain it. They create, classify, update, and retire catalog entries. Security analysts and pentesters read from the catalog and select tools when they author findings, but they do not curate it. This division keeps authorship clean, because practitioners draw on a controlled list during engagements while administrators manage the vocabulary itself in one central place.
