Most vulnerability management programmes are very good at finding problems and surprisingly poor at remembering how they were fixed. A scanner reports the same misconfigured TLS cipher across forty hosts, three different engineers research the same remediation from scratch, and six months later a fourth engineer repeats the work because nobody could find what the first three wrote down. The detection side of the programme scales. The knowledge side leaks.
PMAP treats remediation knowledge as a first-class asset rather than a by-product of triage. The platform ships a dedicated remediation knowledge base, a curated and platform-global library of fix guidance that lives independently of any single scan, finding, or tenant. Each entry is keyed to the identifiers that analysts actually search by, CVE and CWE, carries a CVSS severity cap for prioritised browsing, and stores its guidance in both Turkish and English. This article explains why that library exists, how it is structured, and how a team turns it into one authoritative playbook that everyone draws from.
If you want the wider context first, this feature sits inside PMAP’s enrichment story. Our pillar on vulnerability intelligence and enrichment covers how raw findings become triage-ready, and the solution library is the part of that story that answers the question every remediation owner eventually asks, namely “so how do I actually fix this”.
Why Remediation Knowledge Keeps Getting Lost
Remediation knowledge is expensive to produce. Working out the correct, tested, environment-aware fix for a vulnerability class often involves reading vendor advisories, confirming the patch path, checking for breaking changes, and writing it up clearly enough that the next person can follow it. That effort is real engineering time. Yet in most programmes the output of that effort lands in places that are almost designed to lose it.
It lands in a finding comment that nobody reads again once the finding closes. It lands in a ticket that gets archived. It lands in a private document on one engineer’s drive, or in a Slack message that scrolls away within a day. Each of these locations binds the knowledge to a single incident instead of to the vulnerability class it actually describes. When the same class of vulnerability reappears, the knowledge is technically somewhere in the organisation, just not anywhere a triaging analyst can reach in the moment they need it.
There is a second, quieter cost. When fix guidance is scattered, it drifts. Five copies of “how to remediate this CVE” end up with five slightly different recommendations, and a remediation owner has no way to tell which one is current. Inconsistent guidance is arguably worse than no guidance, because it erodes trust in the whole process.
The structural fix is to stop attaching remediation knowledge to incidents and start attaching it to vulnerability classes, in one place, maintained by the people who own that knowledge. That is precisely the model PMAP’s solution library implements. Guidance that NIST frames as part of disciplined patch and remediation management in NIST SP 800-40 Rev. 4 works far better when the organisation has a single, durable home for the procedures it produces.
A Platform-Global Library, Not Per-Finding Notes
The most important design decision in PMAP’s solution library is also the least visible one. Solutions carry no tenant identifier. There is no company_id on a solution record, and no scope filter is applied when the list or browser is queried. Every authenticated user reads the same full library regardless of which tenant they operate in.
That choice is deliberate, and it is what separates a knowledge base from a pile of notes. The correct way to remediate a given CWE weakness does not depend on which business unit found it. A path traversal fix is a path traversal fix. By making the library platform-global rather than tenant-scoped, PMAP ensures that the work one team does to author a high-quality playbook becomes immediately available to every other team, instead of being walled off inside a single tenant’s silo.
This is the practical antidote to the duplication problem described above. When a security engineer in one part of the organisation writes the definitive remediation for a vulnerability class, that entry is not a private artefact. It is a contribution to a shared catalog that the next analyst, anywhere in the platform, will surface the moment they search for the matching CVE or CWE. The expensive part of remediation knowledge, the authoring, happens once and is reused everywhere.
It is worth being precise about what platform-global means operationally. It means the library is read-shared across tenants by design, and it means curation is a deliberate, centralised activity rather than something that happens accidentally inside individual findings. Platform administrators curate the global catalog, manage stale entries, and can export the full library for audit. The result is a single source of truth that does not fragment as the organisation grows.
Authoring Bilingual Fix Guidance
Remediation only works if the person executing it understands it. In organisations that operate across language boundaries, a single-language playbook quietly excludes part of the team or forces ad-hoc translation that introduces its own errors. PMAP handles this at the data model level rather than as an afterthought.
Every solution carries three text fields that work together. There is a locale-neutral description, which is the one required field on the record and serves as the short, language-independent summary of what the solution addresses. Alongside it sit two separate rich-text bodies, content_tr for Turkish guidance and content_en for English guidance. These are not machine translations of each other. They are independently authored fields, so a security engineer can write the full procedure properly in each language rather than relying on an automated pass that may mangle technical instructions.
In the create and edit modal, the bilingual content is presented as a tabbed editor, one tab for Turkish and one for English, so an author can move between the two versions while keeping the rest of the record, the identifiers, severity, and tags, in one place. When a remediation owner later opens the detail drawer for a solution, both content_tr and content_en are shown, so the reader can work in whichever language they are most comfortable with.
The design encourages, but does not force, full bilingual coverage. Only description is mandatory at creation. The localised bodies are optional, which means a team can start with English-only guidance and backfill Turkish content later without being blocked. PMAP exposes whether both bodies are populated as a library health metric, so a programme that wants complete bilingual coverage can measure its progress toward it rather than assuming it.
CVE and CWE Keyed Lookup From a Finding
A knowledge base is only as good as the path from a problem to its answer. The whole point of authoring remediation guidance is that an analyst staring at a finding can retrieve the right playbook in seconds, not minutes of manual searching. PMAP builds that path on the two identifiers analysts already have in front of them.
Each solution stores a cve_ids[] array and a related_cwe[] array. When an analyst is triaging a finding that carries a CVE identifier, they filter the library by that exact CVE and the matching solution comes back. When a finding is described by a weakness category instead, they filter by CWE. The matching is exact-match against the array, implemented with an ANY(column) comparison, so a query for CVE-2024-1234 returns every solution that lists that CVE in its identifier array. The same applies to CWE codes such as CWE-79 for cross-site scripting.
If you want a refresher on what these identifiers actually represent and how they relate, the MITRE CWE list is the canonical reference for weakness categories, and the NVD maintains the authoritative CVE records. PMAP does not redefine these standards. It uses them as the join key between a finding and its remediation, which is exactly what they are good for.
One operational detail matters here. The array filters accept a single value per parameter. A query filters by one CVE, or one CWE, or one tag at a time, not a set of them in a single call. In practice this matches how analysts work, since a finding is usually being matched against one identifier at a time, but it is worth knowing when you design a lookup workflow. Multi-value filtering means multiple requests, one per value.
This identifier-keyed lookup is what makes the library feel like part of triage rather than a separate reference site you have to leave the workflow to consult. The remediation owner assigned a finding looks up the fix by the same CVE or CWE that defines the finding, and the authoritative guidance is right there.
Severity-Driven Browsing With max_cvss
Not every remediation lookup starts from a specific finding. Sometimes a team wants to browse the library to understand its coverage, to find the most critical remediations to prioritise authoring effort around, or to review what guidance exists before a remediation campaign. For that browsing mode, the question is not “which solution matches this identifier” but “which solutions matter most”. PMAP answers it with a severity cap on every record.
Each solution carries a max_cvss field, the highest CVSS score associated with the vulnerability class it addresses. CVSS, maintained by FIRST in the CVSS specification, is the industry-standard way to express vulnerability severity as a number from 0.0 to 10.0, and PMAP uses that number to order the library for browsing.
The dedicated solutions browser returns its results ordered by max_cvss DESC NULLS LAST. In plain terms, the most severe remediations surface first, and entries with no recorded CVSS score fall to the end rather than disrupting the ranking. An analyst opening the browser sees the critical-severity fixes at the top without any manual sorting. This is a small thing that compounds, because over a large library the difference between “scroll to find what matters” and “what matters is already at the top” is the difference between a tool people use and one they avoid.
Severity is also surfaced visually. On the solutions list, the Max CVSS column is colour-coded so the reader can scan it at a glance, with scores of 9 and above shown in red, 7 and above in orange, 4 and above in yellow, and lower scores in green. The same severity context appears as a badge on the detail drawer and on each row of the browser. The library does not just store severity. It uses severity to shape how the team encounters the knowledge.
It is worth noting where the line sits. PMAP uses CVSS here for ordering and prioritisation inside the library, not to teach CVSS itself. The deeper explanation of how CVSS, CWE, and CVE scores are constructed and what each one means belongs in its own dedicated material. Within the solution library, CVSS is simply the lever that puts the right playbook first.
Linking a Solution to a Vuln Template
A remediation solution does not exist in isolation. In PMAP, the upstream side of enrichment is the vulnerability template library, where Smart Match auto-links raw findings to templates that carry CVE and CWE arrays, MITRE technique references, and structured metadata. The solution library connects to that world through an optional link.
Each solution can carry a related_template_id, an optional foreign key that points to a VulnDB vulnerability template. When set, this link does two useful things. First, every time the solution is read, PMAP resolves the template’s display name into a related_template_name field that is returned with the record and shown in the detail drawer. The reader sees not just the fix guidance but the canonical template it corresponds to, which anchors the remediation to a known vulnerability definition. Second, the link makes the relationship navigable, so a team can move between “what is this vulnerability” and “how do I fix it” along an explicit connection rather than a guessed-at one.
The link is resolved live rather than copied. If the linked template is later deleted from the template library, the solution row is not cascaded away with it. Instead, on the next read, related_template_name simply resolves to null. The solution remains a valid, standalone remediation record. This is the right behaviour, because a remediation playbook for a vulnerability class retains its value even if a particular template definition is retired.
This connection is the bridge between two halves of PMAP’s enrichment model. The template and matching side is covered in detail in our piece on Smart Match and the vuln template library, which explains how findings get linked to templates in the first place. The solution library is the other end of that bridge, the place where the fix guidance for the matched template actually lives.
The Solutions Browser in the Query Builder
The solution library is reachable from two surfaces, and the second one is where it meets the analyst’s daily work. The primary surface is the dedicated Solutions page, a full management view with the list, filters, the detail drawer, and the authoring modal. The secondary surface is a Solutions Browser tab embedded directly in the Query Builder, at /query?tab=solutions.
The Query Builder is where analysts go to interrogate findings, and putting a solutions browser tab there means remediation guidance lives next to the data it remediates. The browser tab exposes CVE ID, CWE ID, and keyword inputs. The analyst enters an identifier or a search term, clicks Browse, and the enriched browser endpoint returns matching solutions ranked by severity. Each result shows the title, a description excerpt, the max CVSS badge, the CVE and CWE pills, an affected-assets count, and a linked-templates count, with skeleton rows shown while the query loads.
That linked-templates count is computed on the fly. For each solution in the browser results, PMAP runs a correlated subquery against the vulnerability templates table to count how many templates the solution relates to, so the analyst can see at a glance whether a solution is tied into the template library or stands alone. It is honest about its current limits, too. A second count, linked findings, is present in the response structure but returns zero in the current implementation, a deliberate placeholder for a future direct finding-to-solution linkage rather than a number to read into today.
The practical effect is that an analyst working through a backlog in the Query Builder never has to leave the page to find a fix. The same screen that surfaces the problem surfaces the remediation, ordered so the most severe guidance is first.
Sparse Updates and Safe Curation
A knowledge base that is hard to maintain stops being maintained. PMAP designs the editing path so that keeping the library current is low-friction and low-risk, which matters because curation is an ongoing activity, not a one-time load.
The core safeguard is the sparse update. When an editor saves a change to a solution, PMAP writes only the fields that were actually provided in the request. Every other field keeps its previous value. Concretely, if an engineer opens a solution only to bump its max_cvss after a re-score, the update touches max_cvss and the updated_at timestamp, and nothing else. The carefully written Turkish and English content, the CVE arrays, the template link, all of it is preserved untouched. There is no risk that a small edit silently blanks a field the editor did not mean to touch, because missing fields are never interpreted as “clear this”.
Creation has exactly one hard rule. The description field is required, and a create request with an empty description is rejected with a clear error. Everything else, title, localised content, identifiers, severity, tags, and the template link, is optional. This keeps the barrier to authoring low while guaranteeing that every record in the library has at least a meaningful summary, so nothing in the catalog is a blank shell.
Curation at scale is supported by the management surface. The Solutions page offers full-text search across title and description, multi-select with bulk delete behind a confirmation dialog, and CSV export of the catalog for audit or sharing with external reviewers. Lookups by missing UUID behave predictably, returning a clean not-found response rather than an ambiguous error, which keeps the API safe to script against for housekeeping tasks. The whole domain is synchronous with no background jobs, so an edit takes effect immediately and there is no eventual-consistency window to reason about.
One honest limitation is worth flagging for anyone designing a workflow around the page. Filter state on the Solutions page is component-local and is not preserved across navigation or a session refresh. A carefully constructed filter is not remembered once you leave the page, so deep, repeated browsing is better done through the browser surface than by relying on the list page to hold your place.
How PMAP Keeps One Authoritative Playbook
Pulling the threads together, the solution library is PMAP’s answer to a problem that is operational, not technical at its root. The problem is that organisations keep paying to rediscover knowledge they already produced, because that knowledge was attached to incidents instead of to the vulnerability classes it describes.
PMAP’s design choices each address one facet of that problem. Making the library platform-global ensures authoring effort is reused across the whole organisation instead of being trapped in a tenant. Keying entries to CVE and CWE arrays means the guidance is retrievable along the same identifiers a finding already carries, so lookup is a single filter rather than a search expedition. Ordering the browser by max_cvss puts the most consequential remediations in front of the people prioritising work. Authoring guidance in both Turkish and English keeps the playbook usable across language boundaries. Linking solutions to vulnerability templates connects the “what” of a vulnerability to the “how” of its fix. Sparse updates and a low authoring bar keep the whole thing maintainable over time.
The outcome is a single, authoritative, durable playbook that grows more valuable with every entry, instead of a knowledge layer that leaks as fast as it is filled. That is the difference between a programme that finds vulnerabilities and one that actually closes them efficiently. The solution library is where PMAP turns hard-won remediation knowledge into a reusable asset, and it is one half of the enrichment model described in our vulnerability intelligence and enrichment pillar, the half that finally answers the analyst’s last question.
> See it in context. A shared remediation library cuts the time it takes to close a finding because the right fix is already written. Explore how PMAP builds yours and start centralising fix guidance your whole team reuses.
Frequently Asked Questions
What is a remediation solution library?
It is a platform-global, curator-maintained catalog of fix guidance. In PMAP, a solution is a remediation record that describes how to fix a class of vulnerability, identified by CVE IDs, CWE codes, or free text, and it lives independently of any single scan, finding, or tenant. Security engineers author entries with bilingual rich-text guidance, a CVSS severity cap, and an optional link to a vulnerability template, and analysts and remediation owners draw from the same authoritative library while triaging findings.
How do I find the right fix guidance from a finding’s CVE?
You filter the library by the finding’s CVE identifier. Each solution stores a cve_ids[] array, and PMAP matches your CVE exactly against that array, so a lookup for a specific CVE returns every solution that lists it. You can do this from the dedicated Solutions page or from the Solutions Browser tab inside the Query Builder, where you enter the CVE ID and click Browse. CWE-keyed lookup works the same way against the related_cwe[] array when a finding is described by a weakness category rather than a CVE.
Why are solutions ordered by CVSS in the browser?
So the most critical remediations surface first without any manual sorting. The solutions browser orders its results by max_cvss DESC NULLS LAST, which means the highest-severity solutions appear at the top and entries without a recorded CVSS score fall to the end. The intent is prioritisation, since when you are browsing the library you usually want to see the most consequential fixes first. Severity is also colour-coded on the list view, so you can scan it at a glance.
Can a solution link to a vulnerability template?
Yes. Each solution can carry an optional related_template_id that points to a VulnDB vulnerability template. When the link is set, PMAP resolves the template’s name into a related_template_name field on every read and shows it in the detail drawer, so the reader sees the fix guidance alongside the canonical template it corresponds to. The link is resolved live, so if the template is later deleted, the solution remains valid and related_template_name simply resolves to null.
Is the solution library shared across tenants?
Yes. Solutions are platform-global. They carry no company_id, and no tenant scope filter is applied to list or browser queries, so every authenticated user reads the same full library regardless of which tenant they operate in. This is deliberate, because the correct way to remediate a vulnerability class does not depend on which business unit found it, and sharing the catalog means authoring effort done once is reused everywhere.
Does editing a solution risk overwriting fields I did not touch?
No. Updates are sparse. When you save a change, PMAP writes only the fields you actually provided and refreshes the updated_at timestamp, while every other field keeps its previous value. Missing fields are never interpreted as a request to clear them, so a small edit such as adjusting the CVSS cap cannot accidentally blank the bilingual content or the CVE arrays. The only hard rule is at creation, where the description field is required.
Can I author remediation guidance in more than one language?
Yes. Every solution carries two separate rich-text bodies, content_tr for Turkish and content_en for English, alongside a shared locale-neutral description. These are independently authored rather than machine-translated, so guidance reads correctly in each language, and the detail drawer shows both so a remediation owner can work in whichever language they prefer. Only the description is mandatory, so you can start single-language and backfill the other body later.
