The Upstream Vulnerability Routing Teardown: SBOM Line to Acknowledged Report

This guide covers one job. You have found a vulnerability in a third-party component your product ships, and you need to get a private report to whoever actually maintains the version you integrate, with a record that proves you did. It is for the engineering managers, technical founders, developer-relations leads and technical sourcers who end up holding that report. It follows one transitive dependency from its SBOM line to an acknowledged report, wrong turns included, and finishes with an evidence log an auditor can read.

What does the upstream reporting duty require?

Article 13(6) of the EU Cyber Resilience Act (CRA) says that a manufacturer who finds a vulnerability in a component integrated in its product, open source included, must report it to the person or entity that manufactures or maintains that component. If the manufacturer wrote a fix, it must share that too. The Commission's guidance limits the duty to the exact version you integrate.

That guidance is C(2026) 5252, and paragraphs 222 to 229 deal with upstream reporting. It says outright that it is non-binding, but it is still the clearest public statement of what regulators expect. Six points in it decide how you route a report:

• Version. Paragraph 223: "Manufacturers are required to report upstream only in respect of the version of the component that they integrate." The project's latest release is not the subject. Your release is.
• Flaw type. The duty covers vulnerabilities in the integrated component itself, "and not vulnerabilities that exist as a result of the integration."
• Duplicates. Check public vulnerability databases, project advisories and issue trackers first, so you do not file a duplicate.
• Channel. Use the maintainer's own policy or channel if one exists, "particularly where premature disclosure of unpatched vulnerabilities could increase cybersecurity risks."
• Fix. If you wrote a fix, share the code or documentation with the maintainer, in a machine-readable format where appropriate.
• Exceptions. You do not need to report when the component no longer has a maintainer, or when you no longer rely on the original maintainer for new versions or security fixes. The second case describes a fork you maintain yourself.

Dates: Article 14 reporting applies from 11 September 2026. Article 13(6) and the other main obligations apply from 11 December 2027. The CRA does not prescribe a format for the record, so this guide gives you one.

If the CRA does not cover you, the procedure stays the same. It is ordinary coordinated vulnerability disclosure (CVD): you report privately to the party that can fix the flaw, and you agree together on when details go public. The CERT Guide to CVD recommends that a reporter "first try reporting the vulnerability directly to the vendor or maintainer of the software in question."

The case: one transitive parser, four candidate owners

The worked case is a composite. I have anonymised the component and describe each party by its role, because the lesson is in the sequence of decisions, not the package name. The day counts are the ones this case took. They are not benchmarks.

A product team found a memory-safety flaw in a small parsing library. The product does not depend on the library directly. It comes in transitively, two levels down, through a logging package. The SBOM line gave three facts: the package name, the version, and a source URL.

Four parties behind that line had a plausible claim to be "the maintainer":

1. The original author. Their name is on the licence header and on most of the early commits.
2. The registry publisher. The accounts allowed to push releases of the package to its registry.
3. The repository owner. The organisation that now holds the upstream repository: a German industrial manufacturer that took the project over.
4. A fork. The SBOM's source URL pointed to it, and it was archived.

A fifth answer stayed possible the whole time: nobody. This split is the hard part of the job. The CERT Guide to CVD and the OpenSSF finder guide list places to look for a contact, but neither tells you which of these parties counts when they disagree.

The routing procedure, SBOM line to closed record

There are nine steps from vulnerable component to closed record: pin, confirm, check, resolve, pick, send, wait, escalate, close. Steps 4 and 5 are where cases go wrong, so each gets its own section below.

How the case went through steps 1 to 3

• Day 0, under an hour. The team pinned the package, version and product release, and copied the SBOM source URL exactly as written. Copying it exactly mattered later.
• Day 0 to day 1. The team wrote the root-cause note. They reproduced the flaw with a minimal harness that called the parser directly, with none of the product's code involved. That made it a component flaw. If it had only triggered because the product's wrapper passed in unchecked input, it would have been an integration flaw: theirs to fix, and outside the upstream duty.
• Day 1, about an hour. The team checked whether the flaw was already known. They searched public vulnerability databases, the project's advisories and its issue tracker for the pinned version. Nothing matched. The search terms, sources and date went into the log, because "not known" is a finding and needs evidence like any other.

Who maintains the exact version you ship?

The maintaining party is whoever currently controls releases for the version line you integrate and is still using that control. The author, the repository owner and the sponsor are evidence toward that answer. None of them is the answer by default. I found no published method for settling this in CERT/CC's guidance, GitHub's documentation or the CRA guidance, so the signals below are a working rubric, and each one comes with the way it can mislead you.

What each signal proves, and how it lies

• Registry publish rights. Proves who can get a fix to your users. Misleads when an account keeps its rights long after its owner has left. Read the publisher metadata using the registry's own documentation. I have not verified specific registry commands, so check them there.
• Repository ownership. Proves who controls the code and its settings. On GitHub, only the owner can turn on private vulnerability reporting. Misleads after a transfer, or when the owner is an organisation nobody watches.
• Recent releases and commits on your version line. Proves someone is still exercising control. Misleads when the activity is all automated dependency bumps.
• Corporate sponsor. Proves who employs or funds the work, and hints that a security team might exist. Misleads when the sponsor pays for the project but nobody there triages reports.
• Original author. Proves history. As a current contact, it misleads more often than not.
• Fork status. Proves whose code you actually build. If you build from a fork you maintain, or one that nobody maintains, a CRA exception may apply, but only if you write it down.

Wrong turn 1: emailing the author (day 1)

The first instinct was to email the author, using an address taken from old commit metadata. The email went out the same day with full details. Two days passed with no reply. The check that should have come first is the date of the named person's last release and last commit on this version line. Both were years old. A Refolk search on the author's name showed them at a different employer with no visible link to the project. That took a minute, where reading old commit emails would have taken an afternoon. The team classified the author as history.

The email still went into the log as a contact attempt. It also left full details in the inbox of someone with no role in the project, so the mistake cost more than time.

Wrong turn 2: the archived fork (day 2)

The SBOM source URL pointed at the fork, so a teammate sent the report to the fork owner's listed address. The fork owner replied that they had stopped tracking the project. The check that catches this is to compare the SBOM source URL with what the build actually resolves. Here the lockfile resolved to the registry package published from upstream, and the source URL was stale metadata.

If the build really had pulled the archived fork, the answer would change. The team would no longer rely on the original maintainer, the CRA exception would apply, and the job would become patching the fork and documenting the exception.

The resolution (days 2 to 3)

• Repository owner: the manufacturer's organisation, after a transfer.
• Registry publish rights: two accounts. One had published releases on the integrated version line within the past few months, and its commits came from an address on the manufacturer's domain. The other was dormant.
• Verdict: the maintaining party is the manufacturer, reached through the active publisher. The author is history, the fork is irrelevant, and "nobody" is ruled out.

This step took three days, the top of the 1 to 3 day budget I use. No published benchmark backs that budget.

Who holds the security role at the maintainer?

Finding the maintaining party is not the same as finding a person who will triage your report. When the maintainer is a company, look for a named product-security or PSIRT owner (a product security incident response team handles vulnerability reports for a vendor's products). At German manufacturers, expect to come up short.

The US employer list comes from a 25-person sample: Apple 4, HP 4, Meta 3. In Germany's 22 the leaders are SAP with 5, Dräger with 4 and Rolls-Royce Power Systems with 2. An OSPO (open source program office) is the team that manages a company's open-source use and contributions. Germany's single OSPO title belongs to someone at OASIS, a standards body, not a manufacturer. In Germany, product-security titles outnumber OSPO titles 22 to 1. For routing, this means an upstream maintainer inside a German industrial company will often have no named security owner, and you may have to find the person before you can find the channel.

In the case, the team used Refolk to find the manufacturer's product-security people. They used those names for one purpose only: asking for the preferred private channel.

Which private channel do you use, and in what order?

Start with the maintainer's own published security channel, once you have confirmed it works. Next comes GitHub private vulnerability reporting, if it is enabled. Then a security.txt contact whose domain matches the vendor's. Then a public request for a security contact that contains no details. After about two weeks of silence, go to a coordinator. No single public source ranks all of these together, so this order is my assembly from GitHub's documentation and the CERT Guide to CVD.

Private vulnerability reporting (PVR) is a GitHub repository feature that lets a reporter open a private advisory draft that only the maintainers can see. GitHub's order is to check the repository's security policy first. Without a policy or PVR, you follow the instructions in the security policy or open an issue asking the maintainers for a preferred security contact. The sources disagree in one place: GitHub also says PVR works without following SECURITY.md. My rule is that if SECURITY.md names a channel other than PVR, you use that channel, because it is the maintainer's stated preference and matches the CRA guidance's "maintainer's own policy or channel."

How often each rung exists

Most of the time the top rung is missing. The table shows that how often it exists depends heavily on which population you sample.

GitHub ships PVR disabled by default, and 76.1% of projects leave it that way. You can read a repository's PVR state with gh api repos/OWNER/REPO/private-vulnerability-reporting.

security.txt: useful, rare, and often someone else's

security.txt is a file in the /.well-known/ folder of a domain that names the domain's security contacts. BSI TR-03183-3 lists it among intake mechanisms, alongside CVD and CSAF (I am citing this secondhand). Adoption varies too much across populations to rely on, and the rows below come from different samples, so do not average them.

Even when the file exists, check it before trusting it. Of the files found on the top 1M domains, only 44% meet RFC standards. 13% have passed their expiry date, and 45% have no expiry at all. 60.3% of files point to contacts on identifiable platforms. A file whose Contact domain matches the vendor's domain is a strong signal. A file that points at a platform usually reaches a hosting abuse desk. Among large Spanish companies, none of the 28 in banking and insurance published one.

How the case went through step 5 (days 3 to 4)

• The upstream repository had no SECURITY.md.
• The PVR endpoint returned enabled: false.
• The manufacturer's domain had a security.txt, but its Contact sat on a hosting platform's domain. The team treated it as a weak signal and sent no details there.
• Wrong turn 3. A developer drafted a public issue titled "Security contact?" and pasted in the stack trace "to help them triage." A second reviewer caught it. The issue was rewritten from the template below and posted.
• At the same time, the team sent a short contact request with no details to the active publisher account and to the named product-security lead.
• Day 4. The active publisher replied, and the owner turned PVR on. The team filed the full report through PVR with the version, the reproduction harness and their patch, and captured the delivery timestamp. Only the title and description are mandatory in the PVR form. Fill in the rest anyway.

Hello maintainers,

I have a potential security issue to report in this project and would like to send it privately.

Could you tell me your preferred private channel, or enable private vulnerability reporting on this repository?

I will not post any details here.

Thanks,
<name>, <organisation>
<contact address>

What do you do when the maintainer does not respond?

Allow about two weeks of silence after confirmed delivery, then bring in a coordinator such as CERT/CC or CISA. This is the trigger in the CERT Guide to CVD. Before you escalate, confirm that the silence came from the maintaining party and not from a departed author or a stale fork.

Know the timelines before you hand a case over:

• CERT/CC generally targets publication of the details 45 days after its initial contact attempt with the vendor.
• CISA may also disclose at 45 days.
• Non-responsive vendor. When no embargo was set, CERT/CC treats a vendor as non-responsive once at least six weeks have passed since the vendor's last response.
• Ninety days is often called a de facto norm, but only secondary sources say so. Do not quote it as policy.
• CVE "CNA of last resort". I have not verified how this procedure works. Check the CVE program's own documentation before you count on it.

In the case, the manufacturer acknowledged on day 9 and confirmed a fix was planned for the version line the product ships. Without that reply, the escalation date would have been day 18, two weeks after the day-4 delivery, and the team would have logged a coordinator case ID.

If the resolution step ended with "nobody", the escalation path is different. A component with no maintainer falls under the CRA exception. You document the finding, patch your own copy, and decide whether a coordinator should still hear about it so other users find out.

How does this go wrong?

Most failures are routing mistakes, not missing channels: a channel that is listed but dead, a contact that belongs to the hosting platform, a report sent to the wrong party, or details posted in public. Reporter behaviour causes more leaks than missing policies do. 285 of 302 PyPI security policies name a private channel, yet 787 security-related issues were filed publicly as GitHub issues across 58 repositories.

1. The "security contact?" issue leaks. GitHub allows the issue, but it is public immediately and should contain nothing about the bug. Looks like: a helpful stack trace or a version-specific hint. Check: a second person reviews the text before it is posted.
2. SECURITY.md points to a disabled PVR form. Looks like: a clean policy that sends you to a form that will not accept anything. Check: query the PVR endpoint before sending.
3. security.txt reaches the host, not the vendor. 60.3% of files point to platform contacts. Looks like: a responsive address that turns out to be an abuse desk. Check: does the Contact domain match the vendor's domain?
4. Expired security.txt. 13% are past their expiry date. Check: read the Expires field before using the contact.
5. Reporting on a fork you no longer track, or reporting an integration bug. Neither falls under paragraph 223. Looks like: case 2's teammate mailing the fork owner. Check: compare against the SBOM source URL, what the lockfile resolves, and your root-cause note.
6. Duplicate report. The maintainer may already know. Check: search databases, advisories and the issue tracker first, and log the search.
7. The departed author or archived repo trap. No public method exists to detect this reliably. Looks like: an inbox that accepts mail and never answers. Check: the date of the named person's last release and last commit on your line. Treat silence past the two-week CERT/CC threshold as the trigger to escalate.

What goes in the evidence record?

No authority mandates a field list. Keep one log entry per report covering the version, the root-cause finding, the awareness search, every contact attempt with its channel and timestamp, the acknowledgement, and any exception you relied on. Practitioner sources recommend an "upstream-report log" with a field like "Upstream maintainer informed: <yes, date, channel / not needed: maintainer aware>."

The exceptions are where records matter most. The CRA removes the duty when there is no maintainer or when you have forked, but only a record makes that visible: without it, the absence of an upstream report looks like an omission. The duty rewards documentation, not effort.

Report ID:
Product and release:
Component, version, source URL (as in SBOM):
Build resolves to (lockfile source):
Root-cause note: component flaw / integration flaw, link
Awareness search: sources, terms, date, result (already known: link / not known)
Maintaining party: named party / no maintainer / we forked
Evidence for maintaining party: publisher, repo owner, last release on our line, sponsor
Channel verification: PVR API enabled true/false; security.txt Contact domain and Expires
Contact attempts: date, time, channel, recipient, details included yes/no, outcome
Delivered: timestamp, channel, fix or patch shared yes/no
Upstream maintainer informed: yes, date, channel / not needed: maintainer aware
Acknowledged: date, by whom, fix status
Escalation: coordinator, date, case ID
Exception relied on: none / no maintainer / no longer rely on original maintainer, evidence
Closed: date, by

Keeping the routing current

Channels decay, so check them again for every report instead of reusing last quarter's answer. A repository's PVR setting can change, a security.txt can expire, publish rights move between accounts, and the person who answered last time may now work somewhere else.

Three habits keep this cheap. First, store the evidence behind each routing decision, not just the decision, so the next report starts from facts you can recheck. Second, when a component's sponsor or active publisher changes, re-run the resolution step before the next report rather than after a bounce. Third, for corporate maintainers without a named security owner, which in Refolk's index describes much of German industry, keep the names of whoever gave you a private channel, and confirm they still hold the role before you use them again.