SSVC decisions

SSVC, the Stakeholder-Specific Vulnerability Categorization from CISA and the CERT Coordination Center, answers one question for a finding: how urgently does this organisation need to act? The answer is one of four decisions.

Decision	Meaning
Track	No action now. Reassess if new information arrives. Remediate in the standard update cycle.
Track*	Specific characteristics warrant closer monitoring. Remediate in the standard update cycle.
Attend	Needs attention from supervisory-level people. Remediate sooner than the standard cycle.
Act	Needs supervisory and leadership attention. Remediate as soon as possible.

Open Configuration › SSVC Decisions (/resolve/ssvc) to see your open findings counted by decision, the Act and Attend findings, and the policy.

The four decision points

The decision table is the CISA Coordinator decision table 2.0.3, published by the CERT Coordination Center. It has 36 rows and is fixed. Vulnetix works out the four decision points for each finding:

Decision point	Values	Default
Exploitation	none, poc, active	active when the finding is in a known-exploited catalogue or has an active or weaponized exploit; poc when a public proof of concept exists
Automatable	no, yes	yes when the CVSS score is at least 9.0 or the EPSS probability at least 0.7
Technical impact	partial, total	total when the CVSS score is at least 9.0 or the package is malware
Mission and well-being	low, medium, high	from the repository’s criticality: low, medium and high map to themselves, critical to high, and an unclassified repository to medium

The defaults are approximations of CISA’s definitions from the signals Vulnetix holds. Automatable is defined by whether an attacker can automate the whole kill chain, and a finding does not carry its CVSS vector, so the default reads a critical score or a high EPSS as automatable. If you hold better information, tighten the expression.

Your policy

Without a policy of your own, the Resolve Platform decides with the defaults. The CLI scan and the remediation plan then keep their older decision. A policy changes four things:

1. Signals. The expressions that turn a finding into the decision points. They are CEL over the finding variables, including the repository’s labels, owner and criticality. An expression that cannot be evaluated holds for nothing, so the decision point takes its lower value and the decision is still made.
2. Mission and well-being by criticality. For example, treat a medium repository as high.
3. Cells you read differently. A mapping rule changes the outcome of every table cell whose decision points are among the values it lists. A decision point left out matches any value. The last matching rule wins.
4. Rules that decide. An override has a CEL condition and an outcome. It is applied after the table and the mapping, and the first that holds sets the outcome. A decision shows which rule set it.

Each outcome also has a priority (low, medium, high or immediate) and a window in days, where 0 is the standard update cycle.

apiVersion: vulnetix.com/v1
kind: SsvcPolicy
metadata:
  name: default
spec:
  automatable: cvss >= 8.0 || epss >= 0.5
  missionWellBeing:
    unclassified: high
  mapping:
    - exploitation: [active]
      technicalImpact: [total]
      missionWellBeing: [medium, high]
      outcome: Act
  overrides:
    - name: card data in scope
      when: labels['pci'] == 'in-scope' && severity in ['critical', 'high']
      outcome: Act
  outcomes:
    act: { priority: immediate, dueDays: 3 }
    attend: { priority: high, dueDays: 14 }

The document names only what differs from the defaults. Download as code on the page produces it, and SsvcPolicy is a Platform IaC kind: one per organisation, named default. Deleting it returns the organisation to the defaults.

A policy is checked when it is saved or planned: unknown values are refused and every expression is compiled against the finding variables. A stored policy that no longer compiles is not applied; the Resolve Platform decides with the defaults, the scan and plan keep their older decision, and the page says so.

The API

Route	Does
GET /v1/ssvc/policy	Your stored policy, the effective policy with defaults filled in, and the 36-row table.
PUT /v1/ssvc/policy	Replaces the policy. Owner or admin.
DELETE /v1/ssvc/policy	Returns to the defaults. Owner or admin.
POST /v1/ssvc/decide	One decision, from a finding’s signals or from the four decision points.
GET /v1/ssvc/summary	Your open findings, most severe first (at most 5000), counted by decision, with the 25 most urgent Act and Attend findings. Cached for 60 seconds.

Decisions are made when you read them, so a policy change shows at once and nothing is stored per finding.

In the CLI scan and the remediation plan

The VDB API decides SSVC under your policy in two more places, so vulnetix scan and the remediation plan agree with the Resolve Platform for an authenticated organization:

• POST /v2/cli/sca, which a scan calls. The decision is the vulnetix:ssvc property of each CycloneDX vulnerability, and the SSVC outcome shown beside a finding.
• GET /v2/vuln/{id}/remediation-plan, in response.ssvc. The plan takes an optional ?repo=owner/name; a scan uses the repository it runs in (the CI repository, else the git remote).

Both decide with the shared SSVC engine over your stored SsvcPolicy, with mission and well-being from the repository’s criticality. The signals they hold are the same variables a policy expression reads:

finding variable	In a scan	In the remediation plan
kev	CISA, VulnCheck or EU KEV	CISA or VulnCheck KEV
exploitMaturity	The strongest exploit source: poc, active or weaponized	active or poc, as the plan reads exploitation
exploitCount	Exploit records for the CVE	ExploitDB, Nuclei and VulnCheck XDB references
cvss, severity, epss	The enriched scores	The same scores
malicious	The malicious-package flag	Not known here
labels, owner, criticality	The repository’s asset record	The asset record of ?repo

When the old decision stands

The policy applies only when your organization has stored one. The scan and the plan keep the decision they made before policies existed when:

• there is no stored SsvcPolicy, even though the Resolve Platform would decide with the defaults. Store a policy, even one with only the defaults you want, to have the scan and plan follow it;
• the credential is the community credential, or the organization has no Resolve Platform record;
• the database migration 20261228010000_ssvc_policy has not been applied;
• the stored policy cannot be read or no longer compiles. The API logs it, and the Resolve Platform page says so.

The old scan decision is Act for a KEV listing, Attend for an EPSS of at least 0.5 or three exploits, Track* for an EPSS of at least 0.1 or any exploit, else Track. The old plan decision is Act for active exploitation with a critical score, Attend for active exploitation, Track* for a critical score, else Track. A repository without a RepositoryAsset record, or a database without that table, does not cause a fallback: the policy still decides, with the repository unclassified, which reads as medium.

What the response adds

Nothing existing changes meaning: vulnetix:ssvc, and ssvc.decision, priority, exploitation, automatable and technicalImpact in the plan, are the same fields and now hold the policy’s decision. A decision made under a policy adds fields beside them. A decision made the old way carries none.

CycloneDX property on a scan	Field of response.ssvc on a plan	Meaning
vulnetix:ssvc:priority	priority (existing)	low, medium, high or immediate, from the policy’s outcome
vulnetix:ssvc:source	source	table, mapping or override
vulnetix:ssvc:rule	rule	The override rule’s name, when an override decided
vulnetix:ssvc:dueDays	dueDays	The outcome’s window in days, left out for the standard update cycle
vulnetix:ssvc:exploitation, :automatable, :technicalImpact, :missionWellBeing	missionWellBeing (the other three exist)	The four decision points. The plan spells them in upper case.
	policy	tenant

Decisions under a policy differ from the old ones by design. The table needs mission and well-being, so a finding in a repository you have not classified is decided as medium, and the signals are the policy’s, not the old ladder’s. A plan answered under a policy is cached per policy and repository.

Before the database migration

The policy needs the database migration 20261228010000_ssvc_policy. Until it is applied, the Resolve Platform decides with the defaults, the CLI scan and the remediation plan keep their older decision, the page says so, and saving or applying a policy is refused with the migration’s name.