PSIRT: what a product security incident response team does

What is a PSIRT?

A Product Security Incident Response Team (PSIRT) is the function that handles security vulnerabilities in the products a company makes and sells. FIRST defines it as an entity that focuses on "the identification, assessment and disposition of the risks associated with security vulnerabilities within the products", including offerings, solutions, components and services.

In practice a PSIRT:

• runs the channel through which researchers, customers and partners report vulnerabilities;
• watches for vulnerabilities in the third-party and open-source components inside its products;
• triages each report: is it real, which products and versions does it affect, how severe is it;
• gets the owning engineering team to fix it, on a schedule that matches the risk;
• publishes advisories and coordinates disclosure with finders and downstream vendors;
• reports metrics to leadership and trains the people who build the products.

Most of the work happens after release. FIRST notes that most product vulnerabilities are reported as quality escapes once a product is on the market, though a PSIRT adds value earlier too, in design reviews and threat modeling.

Where a PSIRT sits in the organization

The difference from other security teams is the focus on products. An enterprise CSIRT protects the company's own systems and networks; a PSIRT protects the customers who run the company's products. The two share skills and often a reporting line, and they meet when an incident in the company's own infrastructure, such as a compromised build system, reaches a product. The full comparison is in PSIRT vs CSIRT.

FIRST describes three operating models:

• Distributed: a small core PSIRT sets policy and coordinates, and security representatives in each product team do the triage and fixes. It scales across a large, varied portfolio, but the people doing the work do not report to the PSIRT.
• Centralized: a larger PSIRT with its own program management, triage and remediation staff, reporting to a senior executive for product security. It suits smaller companies or a uniform portfolio and costs more as the portfolio grows.
• Hybrid: a mix of the two, chosen by company size, portfolio and development strategy.

Whatever the model, FIRST stresses independence: the PSIRT should report to an executive who confirms its authority, so it can take an objective position on vulnerabilities in the company's own products.

The FIRST PSIRT Services Framework

The PSIRT Services Framework, published free by FIRST and now at version 1.1, is the reference most PSIRTs build their service catalog on. It sets out operational foundations (mandate, stakeholders, budget, policies) and then six service areas:

Service area	What it covers
1. Stakeholder ecosystem management	Internal stakeholders, the finder community, downstream vendors and customers, incident communications, recognizing finders, stakeholder metrics
2. Vulnerability discovery	Intake of vulnerability reports, finding unreported vulnerabilities, monitoring product components for vulnerabilities, identifying new vulnerabilities, discovery metrics
3. Vulnerability triage and analysis	Qualifying reports, working with established finders, reproducing vulnerabilities
4. Remediation	Remedy release management plan, remediation, incident handling, release metrics
5. Vulnerability disclosure	Notification, coordination, disclosure through advisories, disclosure metrics
6. Training and education	Training the PSIRT, development and validation teams and other stakeholders; feedback mechanisms

One service is worth singling out because it has become a large share of the work: monitoring for product component vulnerabilities. Its first function is an inventory of product components, a list of the vendors, products and versions included in each product, which FIRST calls "essential to quickly identify affected products for inherited vulnerabilities". In modern software that inventory is a software bill of materials (SBOM).

The PSIRT process at a glance

Two ISO/IEC standards describe the process. ISO/IEC 30111:2019 covers how a vendor handles vulnerabilities internally. ISO/IEC 29147:2018 covers how it receives reports from outside and publishes remediation information. 30111 is meant to be used with 29147, and the phases it describes give a useful outline:

1. Preparation. Policy, roles, a published way to report vulnerabilities, a scoring method, an inventory of what ships.
2. Receipt. Take in reports from researchers, customers, partners and your own testing, and from advisories for components you use. Acknowledge the finder.
3. Verification. Confirm the vulnerability, reproduce it, score it and determine every affected product and version. Record products that are not affected too, and why.
4. Remediation development. The owning team builds and tests a fix or a mitigation. The PSIRT tracks it against the agreed timeline.
5. Release. Ship the fix and publish the advisory, coordinated with the finder and with downstream vendors who embed your product.
6. Post release. Watch for problems with the fix, answer customers, and feed root causes back into development.

Each stage, with what to record and who owns it, is covered in the vulnerability management lifecycle. For deciding which findings come first, see vulnerability prioritization, with exploitation signals from EPSS and the CISA KEV catalog. A vulnerability exploited before a fix exists is a zero-day, and the PSIRT runs it as an incident. Getting from advisory to a fixed, shipped build is covered in CVE remediation.

Disclosure and advisories

Disclosure is the part of the PSIRT that customers see. The usual practice is coordinated vulnerability disclosure: the finder reports privately, the vendor fixes, and both publish on an agreed date, with the finder credited. It starts with a public vulnerability disclosure policy that says how to report, what finders can expect and how long products are supported. See coordinated vulnerability disclosure.

A good advisory tells a customer, without a phone call:

• which products and versions are affected, and which are not;
• the CVE ID and a severity score;
• the fixed version, or a mitigation if there is no fix yet;
• who found it.

Large customers increasingly want advisories in a machine-readable form they can match against their own asset inventory automatically. CSAF is the OASIS standard format for advisories, and VEX is the way to state that a product is not affected by a vulnerability in one of its components, which saves both sides a ticket.

PSIRT metrics and maturity

The framework puts metrics in every service area. Common ones:

• time to acknowledge a report, to triage it, and to release a fix, by severity;
• open vulnerabilities by product, severity and age;
• share of fixes delivered within the remediation targets you published;
• vulnerabilities found internally versus reported from outside;
• advisories published, and corrections to advisories.

FIRST's companion PSIRT Maturity Document arranges the services into three levels:

• Level 1, basic: executive sponsorship, stakeholders, budget and policies; a way to receive reports; a triage workflow; documented fixes; advisories that use CVE and CVSS and credit the finder.
• Level 2, intermediate: a charter and organizational model, baseline metrics, a product registry with dependency mapping, a formal remedy plan, a system to notify stakeholders, and training for the team.
• Level 3, advanced: direct engagement with the finder community, monitoring product components for vulnerabilities, discovery and release metrics, advanced incident handling and playbooks for industry coordination.

The movement between levels is from reactive to proactive.

How to build a PSIRT: start small

1. Get a written mandate from an executive, with the authority to ask product teams to fix things.
2. Publish how to report a vulnerability: a security contact address, a web form or a security.txt file, and a short disclosure policy.
3. Define triage and scoring: who decides whether a report is valid, how severity is scored, and the remediation targets per severity.
4. Know what you ship. For each product version, the components and versions inside it. Without this, every new CVE in a popular library turns into days of asking engineering teams.
5. Name an owner per product who receives findings and schedules fixes.
6. Write an advisory template and publish the first one, even for a small issue.
7. Measure a few timelines from the start, so you can show improvement.

The PSIRT team page looks at the role from the product security lead's side, and industrial vendors can map these steps to IEC 62443-4-1, whose secure development lifecycle requirements include defect management and patch management.

Regulations that expect a PSIRT

A PSIRT used to be a mark of a mature vendor. Several frameworks now ask for its outputs. NIS2 Article 21(2)(e) lists "vulnerability handling and disclosure" among the measures essential and important entities must take. In the US, section 524B requires medical device makers to submit a plan to monitor, identify and address postmarket vulnerabilities, including coordinated vulnerability disclosure, along with an SBOM. And the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents to authorities, starting with an early warning within 24 hours; see what is the CRA.

The tooling a PSIRT needs

Need	Why
Report intake and case tracking	Every report gets an owner, a status and a timeline
Inventory of what ships	An accurate SBOM per product version, including transitive dependencies
Continuous monitoring	New CVEs matched against the components in every released version, not only the next one
Triage and routing	Findings go to the team that owns the fix, with the context to act
Affected and not affected statements	VEX records which products a vulnerability affects and why the others are not affected
Advisory publishing	Human-readable advisories, and machine-readable CSAF for large customers

Few products cover every row; PSIRT tools compared shows which tool does what. The inventory is where most PSIRTs struggle. A scanner that reads lockfiles after the fact lists development dependencies that never ship and misses packages the build downloaded outside the package manager, so the answer to "are we affected?" starts with doubt.

CRACI takes that inventory from the build itself. It runs GitHub Actions builds on its own runners and records the packages each job actually fetched, including transitive dependencies, packages restored from CI caches and dependencies no lockfile lists. Each SBOM carries a completeness state and exports as CycloneDX or SPDX. Monitored SBOMs are re-evaluated continuously as new vulnerabilities are published, build history shows which past builds contained a vulnerable dependency, and the inventory view shows which software versions are deployed to which products. Security teams triage findings and send them to the teams that own the fix, and CRACI supports VEX. See vulnerability tracking and CRACI for PSIRT teams.

PSIRT: frequently asked questions

What does PSIRT stand for?

PSIRT stands for Product Security Incident Response Team. FIRST defines it as an entity within an organization that focuses on the identification, assessment and disposition of the risks associated with security vulnerabilities in the products, offerings, solutions, components and services the organization produces or sells.

What is the difference between a PSIRT and a CSIRT?

A PSIRT handles vulnerabilities in the products a company ships to customers. An enterprise CSIRT handles security incidents in the company's own systems and networks. The two work together, for example when a breach of the build infrastructure affects a product. See PSIRT vs CSIRT.

What is the FIRST PSIRT Services Framework?

A free guide from FIRST, the Forum of Incident Response and Security Teams, that lists the services a PSIRT may provide. Version 1.1 groups them into six service areas: stakeholder ecosystem management, vulnerability discovery, vulnerability triage and analysis, remediation, vulnerability disclosure, and training and education. A companion maturity document arranges the services into three levels.

Which standards describe the PSIRT process?

ISO/IEC 30111:2019 covers how a vendor handles vulnerability reports internally, from preparation and receipt through verification, remediation development, release and post release. ISO/IEC 29147:2018 covers the interface with the outside world: receiving reports and publishing remediation information. 30111 is intended to be used with 29147. IEC 62443-4-1 sets secure development lifecycle requirements, including defect and patch management, for industrial automation products.

Does a small company need a PSIRT?

It needs the function, not necessarily a department. FIRST's maturity document starts with executive sponsorship, named stakeholders, a budget, a few policies, a published way to report vulnerabilities, a triage workflow, documented fixes and advisories that credit the finder. One or two people with a written mandate can run that.

What tools does a PSIRT need?

At minimum: a way to receive reports, a case tracker, a vulnerability scoring method, an inventory of which components ship in which product versions, monitoring of those components for new vulnerabilities, a way to record whether each product is affected (often as VEX), and a way to publish advisories, increasingly in CSAF.