Vendor advisory triage that never defaults to safe

The problem

Network vendors publish security advisories in different shapes and with very different levels of machine readability. Tracking several of them usually means a spreadsheet, some mailing lists, and an assumption that anything not flagged is fine.

That assumption is the failure mode. An ambiguous advisory and a vendor with no feed look the same: an empty cell. The question that matters per advisory is narrower. Is there fixed software, only a workaround, or neither?

What was built

A web application that ingests advisories for seven network, security and network-visibility vendors through five connector types, and answers that question for every advisory.

• Ingest. Hourly and on demand. Vendors are fetched concurrently and in isolation; a source whose fetch fails records its own error, and the run is marked partial when others succeed.
• Classification. Each advisory lands in one of five resolution classes, derived in a single module so every connector classifies the same way.
• Enrichment. CVSS from the advisory or from NVD, membership in the CISA Known Exploited Vulnerabilities (KEV) catalog, and an EPSS exploit-probability score per CVE.
• Prioritization. The default sort puts KEV-listed advisories first regardless of score, then severity, then CVSS, then recency.
• Remediation tracking. A per-advisory “remediated” flag, held separately from the vendor’s “fix exists” signal, recording who set it and when, with an audit log entry for each change.
• Exports. Word and Excel reports that apply exactly the filters on screen.

Class	Meaning
Fixed software	A fixed release exists; name, version and link shown, labelled when the download needs an entitled vendor account
Fixed and workaround	Both exist; the fix leads
Workaround only	No fixed build yet; the mitigation text is shown
No fix	Neither exists, and the record says so explicitly
Cloud-managed	The fix is delivered through the vendor’s cloud console, not a downloadable image

Design decisions

Probe the sources before writing code. Every vendor endpoint was probed live before the connectors were written, and the initial specification was corrected in six places. Each source turned out to be bespoke:

• Palo Alto Networks publishes no CSAF provider metadata, and its per-advisory documents are CSAF 2.1 VEX with no remediation section. Its native JSON index carries fixed versions and workarounds, so it is the primary source.
• Fortinet’s CSAF documents carry fixed builds as free text inside the remediation details, not in the product status tree.
• Arista’s CSAF has no download links; hotfix artifacts appear only on the HTML advisory page.
• Two vendors have no usable advisory feed, so NVD is authoritative for both. A keyword search for one returned only other vendors’ CVEs, so results are filtered on the CPE vendor field.
• The CSAF remediation category set is exactly five values, not the six the specification assumed. Anything outside the set is logged and skipped.

Unknown is never clean. When a source cannot be parsed confidently, the result can never be “fixed”. It falls to workaround-only, if mitigation text was found, or to no-fix, with a note to verify against the vendor advisory. NVD-only vendors are classified this way by design, because NVD carries no structured remediation.

One query layer. The API, the screen and both exports share one filter and sort implementation, so a report matches what the operator saw.

Single-flight without extra infrastructure. The hourly job and the manual “run check now” both take a database advisory lock. A second request returns the run already in progress instead of starting another, and the design lets only one instance ingest if several instances run.

Evidence and limits

• 26 automated tests pass, covering the CSAF parser, resolution logic, each connector type, enrichment, the API, both exports, and idempotency: two back-to-back runs create no duplicate records. Connector tests mock HTTP, so the suite runs offline.
• Version 0.1.0 is feature-complete and not deployed. Multi-instance operation and failover are designed but have not been exercised.

Known limits, stated rather than hidden:

• Fortinet discovery reads the vendor’s RSS feed of roughly the latest 50 advisories; crawling full history is outside the hourly job.
• Arista advisories without a published CSAF document are not ingested.
• For NVD-only vendors every item reads “no fix” with a pointer to the vendor page. NVD is not real-time; vendor notices can lead it by days.
• An advisory document that fails to parse at all is logged and skipped, not shown; ambiguity is flagged only once a record has been read.
• EPSS is displayed per CVE but does not affect the sort order.
• NVD lookups to fill missing descriptions and scores are capped at 200 per run.
• Download links are deep links, not software fetches. Where the vendor requires an entitled account, the link is labelled.

Where it applies

Payer and CMS contractor security programs. NIST 800-53 SI-5 covers receiving security advisories; SI-2 covers timely flaw remediation. An export listing each advisory, the vendor’s actual remediation state, and who marked it remediated and when is evidence for both, drawn from standing records rather than assembled before a review. Open items with no patch are listed, not absent.

Semiconductor and advanced-manufacturing suppliers. Where production networks run on this class of equipment, patch windows are scarce and a workaround is often the only near-term option. Separating workaround-only and no-fix advisories from fixed ones supports the patch-management practice IEC 62443-2-3 describes and the flaw-remediation and advisory-monitoring requirements in NIST 800-171 3.14.1 and 3.14.3. It is also the answer a customer security questionnaire wants when it asks how vendor advisories are tracked.

Fractional security leadership. One ranked view, known-exploited items first and unknowns marked as unknown, works as a standing item in a weekly risk review. The method carries to any vendor set: probe each source, classify conservatively, and keep the remediation record separate from the vendor’s claim.

Independent work by Wade Blackwell. Each write-up is written from scratch for this site, without client, employer or personal data. Names, hostnames, addresses and configuration detail are left out on purpose.