Zero-day and emergency vulnerability response
one engagement record from CVE drop to verified closure

NVD or a vendor advisory publishes a critical CVE in a third-party library or product the company runs in the deployed estate. Active-exploitation evidence accompanies the publication: a working proof of concept, a public exploit, scanning activity observed in the wild, or in-the-wild compromise reports from incident-response firms. The publication is the start of the response clock, not the end of an awareness exercise.

CISA adds the CVE to the Known Exploited Vulnerabilities catalog. The KEV listing carries the federal civilian remediation date for federal agencies and serves as the de facto enterprise priority signal for everyone else. The KEV addition shortens the queue position on every asset that runs the affected component and triggers the emergency response engagement when the listing carries a 7-day remediation due date or a flag for ransomware campaign use.

A vendor in the supply chain publishes an emergency advisory: a software vendor patches a critical pre-authentication remote code execution, a cloud provider issues a service-side mitigation, an open source maintainer cuts an emergency release, or an OEM ships a firmware patch with active-exploitation evidence. The advisory comes with a fix and a window; the response engagement opens on the receipt of the advisory rather than on the morning standup.

A sector CSIRT (FS-ISAC, H-ISAC, electricity-ISAC, or similar) or a national CSIRT (CISA, NCSC, ENISA member, JPCERT) issues an alert that names the company sector or product class. The alert carries the indicators of compromise, the recommended actions, and the reporting obligations. The engagement captures the alert reference and the obligation deadline so the response is auditable rather than reconstructed from a security-team Slack thread.

A paying customer, a partner, or a downstream consumer escalates a third-party vulnerability that affects the company product or environment. The escalation may include the customer own remediation deadline, a contractual notification obligation, or a regulatory submission timeline. The engagement opens with the escalation reference, the customer contact, and the obligation deadline as structured fields rather than as the most-recent reply in the support inbox.

The internal threat-intelligence function, the SOC, or a third-party feed surfaces an active campaign that targets a vulnerability the company estate is exposed to. The detection may pre-date the public CVE assignment, may carry incident-response context from another company in the same sector, or may surface from a paid threat-intelligence subscription. The engagement opens against the detection rather than waiting for the public confirmation.

SecPortal runs Semgrep SCA against the lockfile and manifest of every connected GitHub, GitLab, and Bitbucket repository on every code scan. When the emergency engagement opens, an immediate code scan pass surfaces every direct and transitive dependency on the affected version range. Findings land on the engagement with the affected package, the version observed, the dependency path, the upstream fixed version, and the file location.

Authenticated scans against verified domains run with stored AES-256-GCM-encrypted credentials so the scanner sees what an authenticated user sees. The authenticated pass catches the affected component on a running system where the version is observable through an admin endpoint, a status API, or a fingerprint banner that requires a session. Findings land on the engagement with the asset reference, the observed version, and the authentication context.

External and continuous scans against verified domains catch the vulnerable component on an internet-facing surface where the version is visible without authentication: a public banner, a TLS handshake, a default error page, an HTTP header. The internet-facing exposure is the highest-priority sub-queue because the attack surface is observable to anyone with a port scanner.

Where the workspace carries asset references on prior engagements (the asset criticality scoring workflow, the asset-ownership mapping, the M&A due diligence record, the prior pentest engagement scope), the emergency engagement inherits the asset list and queries against it. The inherited asset references prevent the response from re-discovering the estate from scratch on every emergency. Note: SecPortal does not run a built-in asset inventory or CMDB sync; the asset references come from the engagements that have already captured them on the workspace.

The default closure path. The named owner ships the upgrade to the fixed version on the affected asset. The activity log captures the commit reference, the deployment timestamp, and the verification scan that confirms the vulnerable component is no longer present.

Where the upstream fix is not yet available or the upgrade carries unacceptable change risk inside the response window, the named owner applies a documented vendor mitigation: a configuration change, a feature flag, a runtime control, or a network-level block. The mitigation lands on the finding with the rationale, the residual risk, and the planned date for the upgrade follow-up.

Where the asset cannot be patched inside the response window (legacy environment, contractual change-freeze, vendor sunset), the residual risk is captured through the security exception register with a hard expiry, a compensating control, a named risk owner, and a named approver. The exception is a deliberate decision against the specific finding rather than a forwarded email.

Where the cost of the upgrade exceeds the benefit (an unused legacy service, a deprecated environment, a system already on the retire list), the response closes the finding by retiring the asset. The asset decommissioning workflow captures the cloud account closure, the DNS removal, the workload migration cutover, or the hardware decommissioning ticket so closure is evidence rather than assertion.

The response runs for two weeks and the team still cannot answer the simple question: how many assets are exposed. The code scan ran but only against the main repository; the authenticated scan was scoped to one verified domain; the asset list is on a wiki page nobody updates; the war-room channel has 600 messages and no consolidated count. Programmes that cannot answer the exposure question on day one cannot brief leadership, cannot prioritise the queue, and cannot prove closure at audit time.

The team treats the wave of newly-published critical CVEs as one undifferentiated emergency, races to patch the loudest first, and burns the engineering team on findings that are not reachable, not exploitable in the deployed environment, or already mitigated by an existing control. The KEV-EPSS-CVSS-asset-criticality layer is bypassed in the panic and the actual fire (the one CVE that is on KEV with a 7-day due date and an internet-facing crown jewel) waits in line behind a wave of unreachable mediums.

Engineering merges the upgrade, the war-room channel celebrates, the named owner marks the finding closed, and the response engagement closes without a verification scan. Three weeks later the next scheduled scan reports the same CVE on the same asset because the deployment did not pick up the new lockfile, the runtime image was not rebuilt, or a transitive pin still pulls the vulnerable version. Closure on plan accumulates findings that pass the audit window and reopen at the next scan.

The response runs through an impromptu Slack channel, the war-room minutes are bullet points in a doc nobody version-controls, the verification screenshots are attachments in DM threads, and three months later the auditor asks for the timeline of the response. The reconstruction takes a week and produces something that looks plausible rather than something that proves what actually happened. Audit-grade evidence has to land on a record while the response runs, not after.

The CISO updates the board from a deck the security-program-management lead built. The product VP updates the customer-facing teams from a memo the support lead drafted. The compliance team updates the audit committee from the spreadsheet the GRC lead maintains. The engineering lead updates the engineering org from the war-room channel. Four reports, four different numbers, no shared source. Leadership starts to mistrust the response because the numbers do not match.

The engagement closes when the patch lands, the team moves on to the next quarterly priority, and the lessons-learned never feeds the next response. The next emergency CVE inherits the same operational gaps: the same exposure-assessment lag, the same prioritisation mistakes, the same verification gap, the same audit-trail reconstruction. Programmes that close without a post-mortem stay at the same maturity tier across response cycles.

The time from emergency trigger (CVE publication, KEV addition, vendor advisory, sector CSIRT alert) to the engagement holding a complete exposure picture across the estate. Sub-24-hour time-to-exposure-known is the operational baseline for KEV-listed CVEs; longer windows signal that the exposure-detection layer (code scans, authenticated scans, external scans, inherited asset references) is not aligned with the trigger sources the response actually opens against.

The time from exposure-known to the prioritised queue holding a defensible ordering across affected assets, plus the share of findings by prioritisation tier (KEV-listed crown-jewel internet-facing on top, CVSS-only non-reachable at the bottom). A queue dominated by undifferentiated "all critical" findings signals a prioritisation gap; a queue with a sharp top tier signals the KEV-EPSS-CVSS-asset-criticality layer is doing its job.

Median and 90th percentile time-to-verified-closure for KEV-listed, critical, high, and medium severity findings inside the engagement. The bands are observable against external SLA anchors (CISA BOD 22-01 for KEV-listed federal civilian estate, the published vulnerability SLA policy for the workspace) so SLA-breach risk surfaces before the SLA actually breaches.

The share of closed findings on the engagement that carry a verification scan as evidence of closure rather than a written assertion. Verification coverage below 100 percent on closed findings is the leading indicator that the next scheduled scan will reopen findings the response thought were done.

The number of findings closed via the exception register, the distribution of expiry windows, and the share of expiries that get renewed versus remediated. A high renewal rate signals the exception path is being used to defer the work rather than to capture genuine compensating-control situations. The signal feeds the next budget cycle and the next roadmap conversation.

The steady-state remediation tracking and patch management coordination workflows cover planned cadence. Emergency response bypasses the cadence on the affected assets and folds them back in once the engagement closes.

The incident response workflow covers confirmed compromises; PSIRT covers vendor-side product vulnerabilities. Emergency response sits between them, focused on the consumer-side third-party CVE.

The vulnerability prioritisation workflow holds the queue model the emergency engagement applies on each finding. Exceptions land in the vulnerability acceptance and exception management workflow with hard expiry and named approver.

The engagement carries the audit trail that audit evidence retention depends on, and the metrics that security leadership reporting reads from. ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.3 and 11.3, and CISA BOD 22-01 questions answer from the engagement record.

Leadership, engineering, GRC, customer success, and legal all read the same numbers because they read from the same engagement record. The exposure count, the verified-closed count, the open count, and the residual-risk count match across every briefing.

Named on-call lead, named asset owners, named approver on exception decisions, trigger event reference, exposure timestamps, prioritisation rationale, response decision per finding, verification scan evidence, and closure timeline all live on the engagement. ISO 27001, SOC 2, PCI DSS, and CISA BOD 22-01 audit answers come from one source.

Every closed finding carries a verification scan, a documented exception with hard expiry and named approver, or an asset retirement record as evidence. The next scheduled scan does not reopen findings the response thought were done.

The closed engagement feeds the post-mortem with the time-to-exposure-known distribution, the time-to-verified-closure distribution, the verification coverage, and the exception expiry distribution. The next emergency CVE inherits a sharper playbook.