Skip to content

CVE Emergency Response Runbook ("Are we affected?")
Trigger A high-profile vulnerability (Log4Shell-class), a new CISA KEV entry affecting common components, or a compromised package/action (supply-chain event)
Goal Within 15 minutes: list affected, possibly affected and not affected applications with owners, tier and exposure. Then drive verified remediation.
Owner AppSec lead (incident lead may be delegated)

1. First 15 minutes

  1. Identify the vulnerability ID(s) and affected component purl(s)/version ranges (advisory, OSV/GHSA). For a compromised action or tool, identify the repository and tag/SHA window.
  2. Query the platform:
  3. Are we affected? in the UI (or GET /api/v1/vulnerabilities/{id}/affected-applications) once the advisory is in the feeds; CVE, GHSA and OSV ids and their aliases all work;
  4. before any advisory reaches the feeds: Supply chain → Find a component (or GET /api/v1/components?name=<package>), which lists every version in use, by how many applications.
  5. Read the three sets:
  6. Affected: the current SBOM contains a vulnerable version. Note each application's exposure and tier.
  7. Possibly affected: no or stale SBOM. Treat as affected until proven otherwise. These teams must generate an SBOM now (manual workflow_dispatch of aap-security).
  8. Not affected: current SBOM, no match.
  9. Fallback if the platform is unavailable: query Dependency-Track's portfolio component search directly (read-only account), and GitHub dependency-graph / code search for the package name.

2. Next hour

Step Action
Prioritise The risk engine sets priority automatically. KEV + internet-facing → P1. Confirm overrides for internet-facing Tier 1/2.
Notify Platform tickets are created automatically (grouped per component). Additionally, message owners of affected Tier 1/2 apps directly (Teams/email) with the platform link.
SOC vuln.kev_internet_exposed events flow automatically. Ask the SOC to hunt for exploitation indicators on affected hosts (WAF, app logs).
Mitigate Where a fix is not available: WAF rules, configuration mitigations, feature disablement. Record as a compensating control on an exception (time-bound).
Communicate Status update to security leadership every 4h (counts: affected / remediated (verified) / mitigated / possibly affected remaining).

3. Supply-chain variant (compromised package or action)

  1. Identify repos that resolved the malicious version (SBOM / lockfile history) or ran the compromised action during the window (GitHub Actions run history via the API; referenced_workflows and workflow files at the time).
  2. Treat CI secrets accessible to those runs as compromised: rotate them. OIDC-federated credentials limit this; static secrets must be rotated.
  3. Revoke platform evidence produced by compromised tooling in the window (revocation rule) so controls re-evaluate honestly.
  4. Pin to a known-good SHA. Update the allowlist.
  5. The March 2026 compromise of trivy-action is a worked example: check run history, pin by SHA, assess which secrets were exposed.

4. Close-out

Remediation is complete when every affected finding is closed by verification evidence. Possibly-affected apps are resolved to affected or not affected (current SBOM). Write a post-incident review: time to first list, time to 90% verified remediation, apps without SBOMs (feeds KRI-04 and PIP-03 improvements).