The PSIRT playbook nobody writes down

Every automotive OEM has a PSIRT. Most of them have a formal vulnerability response process document. A few of them have published it. None of those documents describe what actually happens when a real disclosure arrives at 11pm on a Friday.

We have been around for enough of those Fridays to know that the gap between the documented process and the working process is large, and that the working process is where the programmes actually succeed or fail. This post is an attempt to write down the part that does not usually get written down. It is not a critique of any specific PSIRT. It is field notes from observation.

If you run an automotive PSIRT, most of this will be familiar. If you are a security engineer trying to understand why your disclosure has been sitting in the OEM's queue for two months, this is the structural answer.

The shape of a real disclosure

A real vulnerability disclosure to an OEM usually arrives through one of three channels. Researchers email a generic psirt@ alias. Auto-ISAC routes a disclosure from another member. A bug bounty platform forwards a report. In all three cases, the initial intake is a security analyst reading an email and trying to decide whether the claim is plausible.

The first decision is whether to take the disclosure seriously. This is harder than it sounds. PSIRT inboxes attract a lot of noise: penetration test demonstrations, theoretical attacks on cryptography that nobody actually deployed, claims that turn out to be the documented behaviour of a feature. A good triage analyst can rule out about sixty percent of incoming reports inside an hour. The remaining forty percent need someone to reproduce, which is where the structural problems start.

Stage 01 — Triage and the reproduction problem

The seventy-two hour target for triage is achievable in principle and is rarely achieved in practice. The reason is the reproduction problem. A vulnerability report describes a behaviour on a specific vehicle, with specific firmware, in a specific configuration. The PSIRT analyst has to find a vehicle that matches that configuration, get it powered up, get the diagnostic tooling attached, and run the reported steps. This takes a day to a week, depending on how exotic the configuration is and how cooperative the engineering team is.

The teams that do this well have a small fleet of dedicated reproduction vehicles in a known configuration, with a documented process for branching to other configurations as needed. The teams that struggle borrow a development vehicle whenever they can, which means triage time is gated by whatever else the development fleet is doing.

Once reproduction is confirmed, the next two questions are exposure and severity. Exposure is the count of vehicles in the field running the vulnerable configuration. Severity is the CVSS-style scoring, modified for automotive context. The OEM-specific CVSS adaptations matter here: a vulnerability that requires physical access to the OBD port scores very differently than one that is remotely exploitable over Bluetooth. Most OEMs use a modified CVSS 4.0 with automotive adjustments documented in their CSMS.

Stage 02 — Notify, and the question of who

The notification clause inside UNECE R155 §7.3.7 requires the manufacturer to notify the type-approval authority of cyber incidents affecting the approved type. The clause does not specify a deadline. National implementations have started to specify deadlines, with seventy-two hours being a common figure borrowed from GDPR. The working assumption inside most OEM PSIRTs is that they have fourteen days to notify the regulator after triage confirms a real vulnerability.

The list of who gets notified is longer than the regulator. Auto-ISAC gets a notification because the OEM is probably a member. The lead Tier 1 supplier on the affected ECU gets a notification because they will probably need to ship the fix. Internal stakeholders — the platform team, the OTA team, the legal team, the comms team — get notifications because they will all have work to do. Tier 2 suppliers may or may not be in the loop, depending on the OEM's contracts.

The notification stage is where most disclosure timelines start to slip. The slip is rarely the PSIRT's fault. It is usually the fault of an unrelated organisation in the notification list that has not been told the OEM's PSIRT process exists, and now finds out about it from a phone call asking them to drop everything. This is a process maturity problem and the only fix is rehearsal: tabletop exercises that walk the notification list end to end, on cadence, until the muscle memory exists.

Stage 03 — Build and the dependency tree

The third stage is building the fix. This stage looks simple from the outside and is enormously complicated in practice. The simple version is: identify the affected code, fix it, sign the new firmware, ship it. The complicated version is that the affected code is probably written by a Tier 1, owned in source by a Tier 2, integrated by the OEM, and dependent on a chain of other modules with their own version constraints.

A real example. A vulnerability in a Bluetooth stack on an infotainment ECU gets reported. The Bluetooth stack is licensed from a Tier 2 vendor. The infotainment ECU is integrated by a Tier 1. The integration into the vehicle is done by the OEM. The OTA pipeline is run by the OEM, but uses signing keys held in an HSM operated by a different Tier 1. The fix involves a patched Bluetooth stack, but the patch requires a new version of the Bluetooth stack's API, which means the infotainment ECU integration has to be rebuilt, which means the integrating Tier 1's regression suite has to be re-run, which means scheduling time on their hardware-in-the-loop rigs.

Thirty to forty-five days for this stage is realistic if everyone in the dependency tree is awake and prioritising. Sixty to ninety days is what we actually see when the dependency tree has not been mapped in advance. The single most useful thing an OEM PSIRT can do is keep an up-to-date dependency map for every connected ECU on every active platform. Most do not. The ones that do recover from a real disclosure roughly three times faster than the ones that do not.

Stage 04 — Rollout and the canary problem

A fix that has been built, signed, and tested still has to reach the fleet. The over-the-air rollout is its own engineering problem, and it is the stage where most teams underestimate the time required.

The standard pattern is a staged rollout. One percent of the fleet gets the fix first, monitored for forty-eight hours. If no regressions appear, the rollout expands to five percent, then twenty percent, then full fleet. The total duration is forty-five to ninety days depending on the cohort sizes and the connectivity profile of the affected vehicles. Some vehicles are parked for weeks. Some only connect when they reach a charger. The long tail of a rollout is where the assumed "fixed" fleet diverges from the actual fixed fleet.

The canary problem inside automotive rollouts is that the canary cohort is rarely representative. The early cohort is biased toward connected, recently-driven, well-maintained vehicles. The vehicles you most want to validate against are the ones that drive infrequently, have older firmware, and have a partial telematics record. Those vehicles show up in the late cohort, which means the regressions they trigger arrive after the rollout decision has already been committed at scale.

The working solution is to define the canary cohort by something other than recency of activity. Vehicle age, geographic distribution, drive-style profile. A canary cohort that includes a deliberately old, deliberately infrequently driven, deliberately diverse population catches the long-tail issues earlier. Most OEMs are evolving toward this kind of structured canary design but it is not yet standard.

Stage 05 — Disclosure and the coordination problem

Once the fleet rollout has reached a sufficient threshold — usually around ninety percent of the affected vehicles — the OEM coordinates public disclosure. CVE issuance through a CVE Numbering Authority, a public advisory on the OEM's security site, and a coordinated release with the researcher.

The coordination with the researcher is where careful PSIRTs distinguish themselves. The researcher has invested time in finding and reporting the issue. Their incentive is recognition. The OEM's incentive is a quiet, controlled disclosure with the patched fleet as the headline. These incentives are not the same but they are compatible if both sides talk early.

The PSIRTs that maintain good researcher relationships do three things consistently. They acknowledge the report within twenty-four hours, even if the substantive triage takes weeks. They keep the researcher informed about progress, with rough timelines, even when the news is "we are still working on it." They credit the researcher in the disclosure, with the researcher's preferred attribution. The PSIRTs that get adversarial relationships with researchers are usually the ones that fail at one or more of these steps.

What we have learned

After watching this play out across a few different OEMs, a few patterns are consistent enough to call structural rather than incidental.

The PSIRTs that ship faster do not have more analysts. They have better runbooks. A runbook that tells you exactly which Tier 1 owns which ECU on which platform, and who to call after hours, and what the regression-test bench looks like, saves more time than a larger team. We have seen four-person PSIRTs outperform twelve-person PSIRTs on disclosure timelines because the smaller team had spent six months writing down what they were doing.

The PSIRTs that maintain credibility with regulators are the ones that over-notify. The regulator would rather hear about something that turns out to be a false alarm than hear about a real issue late from a journalist. Building a working relationship with the type-approval authority means having low-stakes conversations with them on cadence, so that when a high-stakes conversation has to happen, the channel is already open.

The PSIRTs that handle the worst cases best are the ones that have rehearsed. Once a quarter, a tabletop exercise that walks through a simulated disclosure end to end, with the actual people in the actual roles. It feels like a waste of time until the day you need it, and then it is the difference between a controlled response and a chaotic one.

And finally, the part that gets said least often. The PSIRTs that succeed long-term are the ones that have authority. A PSIRT that can pause an OTA campaign on its own authority responds faster than one that has to convince a product manager. A PSIRT that can require a Tier 1 to accept a patch responds faster than one that has to negotiate. The org chart and the budget and the reporting line all matter as much as the technical capability.

The version that does get written down

None of this is in the formal PSIRT document. The formal document describes the workflow in clean terms: receive, triage, notify, remediate, disclose. The working document, the one that lives in the team's shared notebook and gets updated after every real incident, describes the failure modes and the workarounds. It includes the names of the Tier 1 contacts, the after-hours numbers, the regression-test passcodes, the OTA campaign keys, the regulator's preferred email format.

If your PSIRT has both documents, you are running a mature programme. If you have only the formal one, you are running a programme that will struggle on its first real Friday-night disclosure. The path to maturity is just to write down what you actually do, one incident at a time, until the working document is thicker than the formal one.

---

This piece is part of an ongoing series on operational vehicle security. We work with OEM PSIRT teams on runbook design, disclosure coordination, and the regulator-facing evidence pipeline required by UNECE R155.