PSIRT product security incident response
one record from intake to coordinated disclosure

Reports submitted through the published security.txt address or the vulnerability disclosure programme intake form. Each report is the start of a structured PSIRT case, not the end of an email thread. The disclosure inbox is the front door for unsolicited researcher reports under ISO 29147 and the CISA Secure-by-Design VDP commitment.

Triaged reports passed across from HackerOne, Bugcrowd, Intigriti, or a private bug bounty programme. The platform handles the researcher relationship and the bounty payout; the PSIRT case carries the engineering work, the fix verification, the CVE request, and the advisory publication. The handoff lands as an intake event with the bounty platform reference captured as a structured field.

A finding from a third-party pentest, a product security review, or an internal red team that lands against the company own product. The case opens against the product record with the original engagement linked, so the chain of custody from the pentest engagement through to the published security advisory is reconstructible at audit time rather than reassembled from memory.

SAST, SCA, secret scanning, authenticated DAST, or external scanner findings that meet the promotion criteria for PSIRT handling (production product code, severity threshold, customer-facing impact, supplier dependency in the affected version range). The promotion captures who approved the case opening, the scanner source, the original finding identifier, and the rationale for promotion.

A vulnerability reported by a paying customer, a partner, or a downstream consumer through the support escalation path. The case captures the escalation reference, the reporter contact, the affected customer environment, and the urgency that drives the response SLA. Customer escalations carry both engineering and customer-success watchers from intake.

A security advisory from an upstream supplier (an open source maintainer, a vendor library, a cloud provider, or another OEM) that requires the company to issue its own advisory to its own downstream consumers. The case captures the upstream advisory reference (CVE, GHSA, CVE.org JSON link), the affected component in the company product, and the propagation status across product lines.

A notification from a sector CSIRT, national CSIRT, or a regulator (CISA, ENISA, NCSC, sector-specific CSIRTs) that mentions the company product or a class of vulnerability the company product is exposed to. The case captures the source, the obligation deadline, and any information sharing constraints attached to the notification.

A disclosure that affects multiple vendors at once, run through a coordinator like CISA, JPCERT, CERT/CC, or a sector ISAC. The case captures the coordinator, the coordination identifier, the embargo terms, and the named contact, so the company contribution to the multi-vendor advisory is auditable rather than reconstructed from a coordinator email thread.

The disclosure inbox, the bug bounty platform, and the engineering ticket queue each carry a partial copy of the case. State drifts between the three; the published advisory does not match the engineering fix; the CVE references the wrong version range. PSIRT failure modes that look operational are usually the symptom of a missing single source of truth.

The PSIRT analyst decides "working as designed" or "duplicate of a known case" inside an email thread that nobody else can find six months later. When the same report arrives a second time, the second analyst rediscovers the issue from scratch and the response time looks worse than the first round. The audit trail starts at the published advisory rather than at the report.

Engineering merges the fix on the latest release branch and considers the case closed. The supported back-branches do not get the fix, the published advisory references the wrong fixed-in version, and the customers running the supported back-branch find out at the next pentest. PSIRT verification has to test against the full supported version range, not against the head branch alone.

The CVE request waits until the day before the advisory is supposed to publish, the CNA queue takes longer than expected, the advisory ships without the identifier, and the consumers cannot match the advisory to the entries in their own vulnerability scanners. The CVE request is parallel to fix work, not serial after it.

The drafter rewrites the affected version range, the CVSS vector, and the proof of concept from a stale email rather than from the case record. The advisory contradicts the engineering fix on a small but load-bearing detail, the consumers have to ask for clarification, and the next advisory inherits the same drift. AI-assisted drafting against the structured case record removes the gap between the case and the published artefact.

A researcher publishes the disclosure on the embargo date through their personal blog, a journalist files first, or the upstream supplier posts before the company does. The downstream consumers learn from the third party rather than from the company own channel. PSIRT readiness includes the publication channel, the notification list, and the embargo coordination, not just the engineering fix.

The time from intake to first acknowledgement, distributed across cases. Sub-3-business-day acknowledgement is the disclosure community baseline. The distribution shows whether the programme is meeting the bar consistently or whether one or two slow weeks per quarter pull the average down.

The time from acknowledgement to triage decision, plus the share of cases by decision (confirmed, working as designed, duplicate, insufficient information). A decision mix dominated by working as designed signals a documentation gap; a mix dominated by duplicates signals a findings catalogue gap.

The share of confirmed cases where the fix landed on every supported version range, not only on the head branch. Verification coverage below 100 percent on supported back-branches is the leading indicator that customer-found regressions are coming.

Median and 90th percentile time-to-disclose for KEV-listed, critical, high, and medium severity cases. The bands are observable against external SLA anchors (CISA BOD 22-01 for KEV-listed, EU CRA Article 13 for actively exploited, ISO 30111 for general CVD). Outliers are visible on the case record before the embargo date rather than after.

The share of confirmed cases that received a CVE before the advisory published, the share with the CVE referenced in the published advisory, and the median lag from triage decision to CVE issuance. CVE coverage below 100 percent on shipped advisories signals a CNA-channel bottleneck the programme can budget against.

The vulnerability disclosure programme handles the public intake, the researcher relationship, and the policy commitments. Reports that originate there open as PSIRT cases on the workspace.

The generic incident response workflow covers SOC-side events; the security advisory request workflow covers consultancy advisory hours. PSIRT is the third workflow that sits between them, focused on product-vulnerability response.

Confirmed PSIRT cases follow the same remediation tracking and retesting workflow as pentest findings, with verification against the supported version range before the advisory publishes.

The PSIRT case carries the audit trail that audit evidence retention depends on. ISO/IEC 30111, ISO/IEC 29147, EU CRA Article 13, and SOC 2 CC7.1 questions answer from the case record rather than from a reconstruction of inboxes.

The published advisory matches the engineering fix on every load-bearing detail because both read from the same case record. The CVE references the verified affected and fixed version ranges. The downstream consumers get the same source the engineering team built the fix against.

Named reporter, named PSIRT analyst, named engineering owner, named approver, intake channel, triage decision, CVSS vector, fix verification, CVE identifier, advisory text, and timestamped state changes all live on the case record. ISO 30111, ISO 29147, EU CRA Article 13 and 14, CISA SbD VDP, and SOC 2 CC7.1 audit answers come from one source.