Emerging vulnerability and CVE watch
a continuous read from the public CVE feed against the deployed estate

The external scanning surface fingerprints the technologies running on verified domains (web servers, application frameworks, runtimes, JavaScript libraries, content management systems, cloud services). The fingerprint result maps to CPE prefixes through the CPE mapper so each verified domain carries a structured component picture rather than only a hostname.

A new CVE matches the verified domain when the affected CPE prefix matches the fingerprinted component and the version falls inside the affected version range from the CVE configurations. Partial-scope matches (component matches but version is unclear) produce a deferred-action record rather than a confident finding so the audit reads how confident matches were separated from uncertain ones.

The code scanning SCA surface inspects the package manifests on the connected GitHub, GitLab, and Bitbucket repositories. Each manifest entry resolves to a package identifier and version against the language ecosystem (npm, PyPI, Maven, NuGet, RubyGems, crates.io, Go modules).

A new CVE matches the repository when the affected package identifier matches an entry in the manifest at a vulnerable version. Transitive dependencies count when the lockfile shows the vulnerable version is actually resolved; lockfile reads against the deployed branch rather than against an unmerged feature branch so the watch reads against what actually shipped.

The engagement record holds the in-scope asset list with named owners, criticality classifications, and the relationship to the connected repositories and the verified domains. The asset inventory is the bridge between the upstream CVE signal and the named recipient who carries the work forward.

Fitness matches against the verified domain or the connected repository project onto the asset inventory so the routing knows which named owner is on the hook. Assets with no clear owner promote to the unowned-asset queue rather than disappearing into the determination log; the audit reads which assets were checked and which were not.

The local CPE mapper converts technology fingerprints into CPE prefixes; the local CVE configurations table holds the affected CPE configurations for every synced CVE. Both layers are read locally rather than against the live NVD CPE search so the fitness assessment runs offline against the watch cycle cadence.

The fitness logic walks the CVE configurations tree (AND, OR, child nodes) and resolves whether the local component-and-version reference falls inside the affected configuration. Configurations that depend on a specific operating environment (a particular OS, a particular cloud, a particular build flag) are evaluated against the engagement-recorded environment rather than treated as universal matches.

The team imports the NVD feed daily and posts a Critical and High summary in Slack. Nobody runs the fitness assessment against the deployed estate; nobody knows which CVEs actually affect the verified domains and the connected repositories. The fix is making fitness assessment a structured action that produces a determination record on the engagement, not an informational post in a chat channel.

The watch reads against whatever the last scan saw and ignores the engagement-recorded asset inventory. A new CVE for a runtime the estate uses but the scanner does not fingerprint reliably never enters the shortlist. The fix is feeding the fitness assessment from technology fingerprinting, package manifests, and the engagement asset inventory together so the in-scope read does not depend on a single source.

A team stamps EPSS percentile and KEV status against the watch determination at first ingest and treats the values as static. Six months later the shortlist orders against six-month-old probabilities and misses CVEs that have since been KEV-listed. The fix is refreshing EPSS on the daily FIRST feed and KEV on the catalog refresh cadence so the live shortlist reads against the live signals.

Vendor PSIRT mail lands with a single engineer; the watch determination has no record of the advisory. When the next scan finds the underlying issue the watch reads as if the programme had no early signal. The fix is naming the advisory recipient on the engagement, capturing the advisory artefact in document management at ingest, and treating the advisory as a first-class source alongside the NVD feed.

The watch cycle produces a shortlist and discards the rest. An auditor asks why CVE-X did not produce work; the team reconstructs the reasoning from memory three months later. The fix is logging every reviewed CVE with the fitness assessment result (in-scope, partial-scope, out-of-scope, deferred-action) so the determination chronology reads as policy-driven rather than analyst-driven.

The watch program produces watch-only findings that route through a separate triage flow with a separate SLA. The named owner is on the hook for two queues that disagree on severity, deadline, and priority. The fix is creating findings on the same engagement record with the same SLA tier logic and the same routing rules; the watch is an intake source, not a parallel programme.

The originating source (NVD CVE ID, vendor PSIRT bulletin reference, KEV catalog entry, GHSA identifier, ISAC bulletin reference, CERT alert reference), the ingest timestamp, the analyst who logged the determination, the source link, and the document management reference for the upstream artefact. Provenance is the root of every later audit and re-evaluation read.

The result the fitness assessment produced: in-scope (confident match), partial-scope (uncertain match), out-of-scope (no match) with rationale, or deferred-action (not in-scope today but tracked for early signal) with the early-signal rationale. The result is a named field so the watch shortlist reads against a queryable taxonomy rather than against free-text notes.

The action the watch produced: new finding created with the finding identifier and the calibrated severity, open finding accelerated with the finding identifier and the priority delta, no action taken with the rationale, or deferred-action record with the named workstream that will clarify the picture. The finding identifiers cite explicitly so the routing layer does not have to guess scope.

The watch records the calibrated severity that the deployed configuration justifies (base CVSS layered with temporal and environmental adjustments) and the SLA tier the routing inherits. The source severity from the upstream feed is preserved alongside the calibrated severity so the calibration is reproducible at audit.

The named analyst who logged the determination, the named recipient owner on the affected asset, and the access scope that applies to the determination (especially for privileged sources where TLP:AMBER or TLP:RED handling notes constrain onward routing). The team management surface scopes engagement access to the named handlers so privileged material does not leak through the watch view.

The trigger events that re-fire the watch determination between scheduled cycles: a new vendor advisory against the same CVE, a new KEV listing, an EPSS percentile shift past the policy threshold, an asset inventory change that promotes the CVE from out-of-scope to in-scope, or an explicit operator request. The trigger ladder is recorded on the engagement so the re-evaluation cadence reads as policy-driven.

The per-finding enrichment workflow attaches CVE, CVSS calibration, EPSS percentile, KEV status, CWE, and vendor advisory references to findings that already exist on the engagement record. The watch program is the upstream discipline that decides whether a newly published CVE should produce a new finding in the first place; enrichment is the downstream discipline that attaches references to findings the watch and the scanners have already created.

The zero-day and emergency response workflow is the incident-style response to a single high-impact event with active exploitation against the deployed estate. The watch program is the continuous, lower-tempo discipline that runs every week against the rolling CVE window so the programme has fewer surprises and so the inevitable surprises start from a documented baseline rather than from cold discovery.

The threat-intelligence-driven prioritisation workflow layers CTI signals onto existing findings to accelerate prioritisation and re-route the SLA tier. The watch program is the upstream intake discipline that converts new CVE publications into findings against the estate before the SLA tier conversation begins. Both workflows run on the same engagement surface but they answer different questions: watch decides what enters the queue; prioritisation decides where it sits.

The dependency vulnerability triage workflow operates per-finding from SCA output against connected repositories. The watch program is broader: it ingests CVEs the SCA scanner has not yet caught (because the scan cadence has not fired, because the package version was published since the last scan, or because the source is a vendor PSIRT or a GHSA that the SCA tool does not cover) and produces findings against the estate before the next scan would have found them.