Supply Chain Intel (Continuous Watch)

Daily cross-reference of every submitted SBOM against OSV and CISA KEV, prioritized by EPSS exploitability, with formal risk acceptance, OpenVEX attestation, and a branded Exploitability Report.

WASViking^® Supply Chain Intel runs Continuous Watch over every SBOM your organization has submitted. SBOMs land in the inventory once and are re-evaluated every day against the latest advisories. No re-scan or re-submission needed.

This is the page at Inventory → Supply Chain Intel in the portal.

What it does

Continuous Watch cross-references every SBOM you have submitted against OSV and CISA KEV every day. Each vulnerable component becomes a Finding with its own lifecycle.

Three concrete outcomes:

1. Net new advisories published today are matched against every live SBOM you submitted in the past.
2. Existing advisories that change (KEV listing, severity bump, fix released) trigger a fresh alert per the re-notify policy.
3. Status hygiene: a vulnerable component shipped under the same dedupe_key does not produce duplicate Findings; it updates the existing one.

How it works

Sources

Ingestion is incremental: only new and modified advisories are pulled each cycle. Both feeds are public; no customer data leaves your tenant during ingest.

Cadence

Continuous Watch runs daily. Each cycle:

1. Refreshes OSV deltas per ecosystem.
2. Diffs the CISA KEV catalog.
3. Matches every advisory against every active SBOM in your organization.
4. Promotes matches to Findings with category vulnerable_component and source = continuous_watch.
5. Routes alerts per the re-notify policy and the channel configuration.

Severity

WASViking computes a single severity per match in this precedence:

1. CVSS v4 if available, otherwise CVSS v3.
2. GHSA qualitative severity (critical / high / moderate / low) if there is no CVSS.
3. KEV-listed advisories default to at least high even without a CVSS score, because exploitation is confirmed.
4. unknown only if none of the above is available.

Re-notify policy

By design, Continuous Watch is signal-only. A new alert fires only on meaningful state changes for an advisory already in your inventory:

Repeated daily runs that find the same advisory in the same state do not re-fire. Suppressed matches stay suppressed; if an escalation matches a suppressed advisory, the audit log captures it with "escalated while suppressed", but no alert is sent.

Where it lives in the portal

Inventory → Supply Chain Intel is the operator view. The page lists matches with filters by ecosystem, severity, and status (open, acknowledged, suppressed, fixed), a CISA KEV badge, and an EPSS exploitability column. Each row drills into:

• Advisory details (CVE / GHSA / KEV linkage, references, sanitized description).
• Affected component and version range.
• Source SBOM and target.
• Status timeline with operator transitions.
• The risk-acceptance exception panel (approver, expiry, justification, and VEX status) when the match is suppressed.

Exploitability prioritization (EPSS + KEV)

A CVSS severity tells you how bad a vulnerability is in theory. It does not tell you how likely it is to be exploited. Continuous Watch adds that missing signal so your team works the advisories that matter first.

Every advisory carries two exploitability signals:

• CISA KEV flags advisories confirmed under active exploitation in the wild.
• EPSS is the FIRST.org Exploit Prediction Scoring System, a daily probability that a CVE will be exploited within the next 30 days. It is shown as a percentage in the EPSS column, with the exact score and percentile on hover.

The list is ordered by real-world risk: KEV-listed advisories first, then the highest EPSS, then CVSS severity. A recent medium-severity advisory that attackers are already using outranks an old critical that no one has touched. EPSS is keyed to CVEs, so an advisory with no CVE (a GHSA-only entry) shows a dash until a CVE alias appears.

EPSS refreshes daily alongside the OSV and KEV ingest, so the ordering tracks the live threat landscape with no action on your side.

Risk acceptance and exceptions

Not every matched advisory is a problem you need to fix. A vulnerable package may sit in a build-only dependency, or in a code path your application never runs. For these cases the operator accepts the risk, and WASViking^® records that decision the way an auditor expects to see it.

The Accept risk action on the match detail page captures:

• Who approved it. The acting operator is recorded as the approver.
• Why. A written justification is mandatory. The decision is not saved without one.
• Until when. The acceptance carries an expiry date that you set.
• Re-attestation. Before the expiry you can re-attest, which extends the window and records a fresh justification and timestamp.

An accepted risk is not permanent. A daily job reopens any exception whose expiry has passed, so a lapsed acceptance resurfaces for review instead of staying hidden. Every grant, re-attestation, and expiry is written to the audit log.

This is what turns a suppression into a defensible control: a time-boxed, attested decision with a named owner, rather than a checkbox that hides a finding forever.

VEX attestation

When you accept a risk on the grounds that a component is genuinely not exploitable, you can record the reason as a formal VEX statement. VEX (Vulnerability Exploitability eXchange) is the CISA-backed standard for stating, per vulnerability and per component, whether a product is affected and why not.

At the point of accepting the risk you choose one of the five OpenVEX not_affected justifications:

A match with a valid justification is exported as not_affected in the OpenVEX document. A risk you accept without one is exported honestly as affected, so the attestation never overstates your posture. WASViking generates the machine-readable OpenVEX document on demand, so a customer or an auditor can ingest it into their own tooling.

Exploitability Report (PDF)

The Export Exploitability Report button on the Supply Chain Intel page produces a branded PDF that answers the question a regulated customer or auditor actually asks: of the known vulnerabilities in your software, which ones can be exploited and which cannot, with the justification for each.

The report contains:

• A cover with your organization, the generation date, and the scope filters applied.
• A short explanation of what the report is, so a reader without context understands it.
• An executive summary with counts of advisories in scope, affected, not affected, fixed, KEV-listed, and critical.
• A statement table ordered by KEV and EPSS, with the VEX status and the justification for each item.

The report respects the current status and ecosystem filters, so you can scope it to a single project or ecosystem before exporting. It is generated server-side with the same engine as the WASViking^® security assessment report, and is built to drop straight into an auditor binder or a vendor due-diligence response. The same underlying determinations are available as machine-readable OpenVEX for tooling ingestion.

Findings produced

Every match promotes to a Finding under the standard workflow.

Findings inherit the standard Findings workflow, including status transitions and webhook events.

Alert channels

Continuous Watch reuses the platform's alert routing. Configure recipients under Settings → Notification Channels. On each channel modal, enable the Supply Chain Advisory event.

See Webhook events for the full event catalog.

REST API

Public read access for tenant integrations and SIEM ingestion.

Auth scheme is ApiKey wv_live_*. Encrypted IDs on the wire (standard across the public API). See Authentication.

Plan availability

Continuous Watch is a Pro plan and above feature. Free and Starter plans see the SBOM inventory but not the daily ingest or the re-notify pipeline. Per-plan limits:

When you are on Starter, the Supply Chain Intel page shows a disabled state inviting you to upgrade.

What it does NOT do

• No outbound traffic to your repositories. Continuous Watch operates over SBOMs already submitted; it does not pull source.
• No automatic remediation. Matches become Findings; remediation is operator-driven.
• No customer data in the alert payload. Alerts carry the advisory and the matched component, plus an opaque match reference.
• Does not replace the CI/CD gate. The wasviking-sentinel sbom gate runs at build time. Continuous Watch is the after-the-build safety net for advisories published after your last build.

How this fits with the rest of the supply chain story

The capability summary lives at Software Supply Chain.

Set up

Nothing to configure. The watch starts as soon as your organization has submitted at least one SBOM and your plan includes the module (Pro and above). To start submitting, see wasviking-sentinel sbom.