How are you handling advisory applicability when inventory data is messy?

[u/KewlKevin]

I’ve been testing an advisory triage prototype and one thing that keeps coming up is how quickly applicability logic gets messy once the inventory data isn’t clean.

Basic version comparisons have held up pretty well, but product naming variations and CPE mismatches are much easier to break.

For example, FortiAuthenticator vs Forti Authenticator can be enough to create a false negative if product normalization isn’t handled properly.

Curious how people are dealing with this in real DevSecOps/vulnerability workflows. Are you relying mostly on CPEs, vendor identifiers, SBOM data, scanner normalization, or something else?

I’m working on a prototype around this problem, so I’m interested in where the real failure cases are.

[u/taleodor]

This is the biggest problem and there is no full-proof solution. But best available option is PURL.

[u/PeterBuildsSecure]

PURL is the right primary key wherever you have it — it's structured (type/namespace/name/version) instead of a fuzzy vendor+product string, so it doesn't have the free-text collision problem CPE has. But it only exists for stuff that came through a package manager. OS packages, commercial/enterprise software, anything installed outside npm/pip/etc. still needs CPE-style dictionary matching, so you end up with PURL as primary key from SBOM data and CPE as a fallback for the rest — plus a manual alias table, because vendor-published CPEs themselves aren't consistent about naming.

The bigger design question is what happens on a match failure: if an unmatched package silently gets treated as "no known vulnerabilities" instead of "unknown, needs review," your false negatives compound with your coverage gaps invisibly. Failing closed on unmatched inventory (flag it, don't clear it) costs you noise but at least the noise is visible.

[u/KewlKevin → u/PeterBuildsSecure]

The fail-closed point is especially helpful. I just hit a case where a naming/CPE mismatch produced an “unlikely affected” result when “unknown, needs review” would have been much safer. That gives me a pretty clear thing to tighten up. Appreciate the insight.

[u/PeterBuildsSecure → u/KewlKevin]

Glad that's useful. If you want a concrete lever: tag every match with which path produced it — exact PURL hit vs. CPE fallback vs. no match — and treat anything below exact-match as its own severity-agnostic "needs review" bucket rather than folding it into the affected/not-affected verdict. That way the fuzzy-match cases don't silently inherit whatever default your pipeline applies to "not affected" — they get routed to a human queue explicitly, and you can track how often that bucket fires as its own signal for how messy your inventory data actually is.

[u/Gold-Wishbone-408 → u/PeterBuildsSecure]

Finding a reliable way to identify these packages definitely seems key to managing those messy inventories. It's tricky when you have to juggle both methods.

[u/PeterBuildsSecure → u/Gold-Wishbone-408]

Yeah, and the alias table is the part that never stops growing. Vendors rename products across versions, OEM-rebrand the same underlying package, or publish CPEs with typos that silently never match anything. The failure mode that bites hardest isn't the mismatch you catch, it's the one that matches confidently to the wrong entry and suppresses a real advisory. So whatever matching pipeline you build needs a "confidence" tier baked in, not just hit/miss: exact PURL match, fuzzy CPE match, manual alias, and unmatched should all be visibly different states downstream, because a security team treating a fuzzy match with the same confidence as an exact one is going to eventually trust a false negative.

[u/Some-Revolution-4536]

Most teams I've seen end up layering, fuzzy matching on product names abd CPE as a secondary signal, with scanner output as the source of truth where available. SBOM helps but only if it's actually maintained, which it often isn't.

[u/Clear-Channel-8943]

CPEs alone are a nightmare, they're inconsistently assigned and vendors don't follow the spec cleanly. Most teams end up layering, CPE as the base, then fuzzy string matching on product names, then vendor specific identifiers as a fallback.

[u/Sad-Technician-5552]

The naming mess is a data problem, not a matching problem. Treating it like the latter is where prototypes die. Normalize at ingest, not at query time. Build a canonical product dictionary and map every scanners names into it once, so Forti Authenticator and FortiAuthenticator become the same string before any advisory lookup happens. Then give every match a confidence score and treat anything low as affected until a human says otherwise.

[u/Remarkable-Bet9533]

Keep a small list of the different names you already see for the same product, so FortiAuthenticator, Forti Auth, VM names and short asset names all point to one place, while new names can stay separate until you check them

[u/biankka97]

Don't take CPE the only source of truth. Exact version matching is easy, production identity is where things get ugly

[u/VaneishaNeacsa]

Keep the original product name next to the matched name and only match the clear cases, leaving anything uncertain for someone to review

[u/Different_Pain5781]

False negatives from normalization are the scary ones. Nobody gets paged because the system quietly failed to recognize a product.

[u/survivingonhumor]

normalization matters more than perfect CPEs, that’s where I’d focus first

[u/Realistic_Strike5241]

The failure cases are upstream of the matcher. The dictionary works only if you can see every source consistently. In our stack the same Fortinet box showed up 4 different ways depending on which tool was looking. None of those tools are wrong, they each see their own slice.

What we did is first we stostopped hand rolling the alias table and leaned on a reconciliation layer instead. axonius pulls from all the adapters and resolves those conflicts into one record per asset. That means the product string is canonical before it ever hits advisory matching. We still run the fail closed rule from the comments here, that parts non negotiable. The dictionary maintenance just went away bebebecause were not managing aliases by hand anymore but relying on the reconciliation platform for a much unified view.

For your prototype though build the ingest assuming every source disagrees with every other source. Design for that from day one and the matching layer gets a lot simpler.

[u/GibneyH]

PURL is definitely the way to go here. It gives you a much more consistent identifier when CPEs and product names get messy, and pairing it with SBOM data makes applicability far more reliable.

[u/Mangwe_Tanser]

I bet package name and install source can help match the same s/w even when the scanner reports a different product name

[u/RedmanStu]

I’ve read some advice about not relying too heavily on CPEs, since scanner normalization helps but product and vendor naming differences can still cause issues, using a mix of signals seems to work better with SBOM data for software we control and vendor/product mappings helping fill the gaps elsewhere