Most of the zero-days my team has surfaced in the last year have been in transitive dependencies maintained by individuals or small open-source projects. The people on the other end of the disclosure email are not corporate security teams with on-call rotations. They are part-time maintainers with day jobs, and the way you write the first email determines whether the bug gets fixed in a week or sits unread for a month. Coordinated disclosure with upstream maintainers in 2026 is, more than anything, a relationship problem dressed up as a technical one.
The technical problems are mostly solved. The pipeline produces a defensible report. The artefact bundle includes the path, the hypothesis, the disproof, and the payload. What remains is the human interaction, which is the part the industry has historically underinvested in, and which the rise of automated discovery makes more important rather than less. If the volume of disclosures from your organisation goes up by an order of magnitude, the relationship discipline has to scale with it.
This piece is what I have learned about that discipline.
Start by understanding who you are writing to
The maintainer of a transitive dependency is rarely a security professional. They are often the original author of the package, sometimes a successor who took it over from a retired author, and occasionally a small team. Their dominant experience with security disclosure is receiving low-quality reports from drive-by reporters who never read the code. Many of them have stopped reading vulnerability emails carefully because the signal-to-noise has collapsed.
Your first email is competing for attention against that history. The way to win the attention is to demonstrate, in the first paragraph, that you have actually read the code and that the report has real grounding. The artefact bundle from the engine-plus-Griffin AI pipeline does this work for you, but only if you put it in the email rather than gating it behind a portal or a PDF attachment that the maintainer has to download.
I include the package name, the version range, the entry point in the consumer's code, the inter-procedural taint path with line numbers, the CWE class, and the proof-of-concept payload directly in the email body. The maintainer can read the entire technical case in three minutes without leaving their inbox. The link to the full report comes after, for the maintainer who wants more depth.
Be explicit about the disclosure window
The first email should propose a disclosure window and explicitly invite the maintainer to negotiate it. Do not assume that 90 days is universal. Some maintainers want longer because they are juggling other priorities. Some want shorter because they have a fix ready and want to ship.
The phrasing I use is something like: "We propose a 90-day coordinated disclosure window, ending on [date]. We are happy to extend if you need more time, or to compress if you are ready to ship a fix sooner. Tell us what works for your release cadence." This frames the disclosure as a collaboration rather than a deadline imposed by an outside party.
The negotiation that follows is informative. A maintainer who responds quickly with a counter-proposal is engaged. A maintainer who responds with a question about the technical claim is engaged and skeptical, which is fine. A maintainer who does not respond at all needs follow-up, ideally through a different channel.
Provide a private channel
The maintainer needs a way to talk to you securely. PGP-encrypted email is the historical convention, although in practice most maintainers do not have a working PGP setup. A signal channel, a Keybase chat, a private GitHub Security Advisory thread, or even a dedicated email account that you control can all work. The point is to provide an option and let the maintainer pick the one they are comfortable with.
In practice the most-used channel I have seen in the last two years is the GitHub Security Advisory feature, because it integrates with the maintainer's existing workflow and has a clear paper trail. The PGP fallback exists for maintainers who insist on it, which is a small but non-zero population.
What to do when the maintainer is uncertain
A common response from a maintainer who is genuinely engaged is "I am not sure this is exploitable in practice." This is the right instinct. They are pushing back on the report, and the way you respond determines whether the conversation produces a fix or stalls.
The response that works is to share the proof-of-concept payload and the verification trace. Walk them through the path the trace covers. Acknowledge the parts of the exploitation chain that depend on the consuming environment (which the pipeline cannot verify) and the parts that are intrinsic to the package (which the pipeline did verify). Most maintainers, given a verifiable trace, will run it themselves and convince themselves of the bug.
If the maintainer remains unconvinced after seeing the trace, accept the disagreement. Document it. The bug may genuinely depend on consumer-side conditions that make it exploitable in your environment but not universally. That outcome is fine, and it can still be disclosed honestly with the consumer-side caveats.
Coordinating the patch
Once the maintainer has accepted the report, the next step is the patch. Some maintainers ask the reporter to propose a fix. Others prefer to write the fix themselves. Both are reasonable. If you propose a fix, write it as a regular pull request against the package, with tests covering the bug. The PR should not refer to the security implications publicly; it should look like a routine bug fix until the embargo lifts.
If the maintainer writes the fix, your role is to verify it. Re-run the pipeline against the patched version of the package and confirm that the path is no longer reachable. Provide the verification trace as evidence that the patch is effective. This closes the loop on the technical content and gives the maintainer confidence to release.
Coordinating the public release
The release of the patched version, the publication of the security advisory, and the assignment of a CVE identifier should happen close together in time. Coordinated release reduces confusion downstream, because users searching the CVE find the advisory, the advisory points at the patched version, and SCA tools pick up the vulnerable version range automatically.
Plan the release a week in advance. Agree on the date with the maintainer. Prepare the advisory text together. Submit the CVE request to the appropriate numbering authority (GHSA can issue identifiers for GitHub-hosted projects, MITRE handles others). Time the maintainer's release notes, your own blog post (if you write one), and any social media to land within a few hours of each other.
This level of coordination feels like overhead, and it is. The reason to do it is that the alternative is a patchy, confusing rollout where users hear about the vulnerability before the fix is available, or hear about the fix without understanding the severity. Coordinated release is the discipline that makes the disclosure useful to the ecosystem rather than just to your own organisation.
After the disclosure lifts
Once public, the disclosure becomes a public record of how the bug was found, what it affected, and how it was fixed. The maintainer can credit your team in the release notes. The advisory becomes part of the public CVE corpus. Future SCA scans pick up the vulnerable version range automatically. Other downstream consumers patch on their own timelines.
This is the moment when the upstream pipeline that produced the finding starts feeding back into the conventional CVE-driven ecosystem. The bug you found has now been published, named, and indexed. It is no longer a zero-day. It is a known vulnerability that the rest of the ecosystem can defend against on schedule.
How Safeguard Helps
Safeguard handles the operational layer of coordinated disclosure. Each finding from the engine-plus-Griffin AI pipeline ships with a draft maintainer email, a private communication channel, and the artefact bundle inlined. The platform tracks the negotiation, the embargo timing, the patch verification, the CVE assignment, and the coordinated public release as a single integrated workflow. Your security team gets the discovery and the disclosure operations together, and the maintainers on the other end get reports that respect their time and demonstrate the technical care that gets bugs fixed quickly.