Reporting a Vulnerability in Somebody Else's Code

A vulnerability in an open-source library inside your product is your vulnerability to report. The duty follows the product to market rather than the code to its author, so integrating somebody else's component transfers the obligation to whoever ships it.

‍

The reporting is the visible half. The harder consequence is that the same regulation requires remediation across the product in its entirety, and the party who wrote the component may have no obligation to help you.

‍

Who Owes What to Whom?

‍

The relationship is one-directional, which is the structural fact everything else follows from.

‍

A manufacturer placing a product on the market carries the reporting duty, the remediation duty and the support commitment. A non-commercial open-source maintainer supplying code outside commercial activity carries none of them. Where the component was placed on the market commercially, its maker carries its own duty independently, so both parties report separately rather than one relieving the other. Assessing a supplier rarely reaches this level of obligation detail.

‍

You Also Owe the Maintainer a Report

‍

Article 13 requires the manufacturer to report the vulnerability to the person or entity maintaining the component, and where the manufacturer has developed a fix, to share that fix upstream. A maintainer with no obligation to you receives a notification and a patch from you, which is a reasonable design for ecosystem health and an asymmetry worth understanding before it applies.

‍

What Does Remediation in Its Entirety Mean?

‍

You cannot scope out the code you did not write, which is the provision that changes how open-source dependency management has to work.

‍

The essential requirements apply to the product as a whole, including every integrated component. Where a maintainer does not produce a fix, is no longer active or has stopped supporting the component, pointing upstream is not a response. The obligation remains, and the available options are disabling the affected functionality, replacing the component, or writing the patch yourself.

‍

Which Converts a Technical Position Into a Legal One

‍

An unmaintained dependency was previously technical debt to be addressed when convenient. Under this regime it is a component whose future security work has been assigned to you by default, and the assignment is enforceable. Integration now implies stewardship rather than consumption, which what a component inventory does not establish covers from the AI side.

‍

What Happens When the Dependency Is End of Life?

‍

The worst version of this, and it is common enough to be the planning case rather than an edge case.

‍

A framework reaching end of life means the maintainers have stopped issuing security fixes. A new vulnerability in that framework, actively exploited, starts the 24-hour reporting clock exactly as any other would, and there is no upstream patch coming at any point. The manufacturer reports on time and then faces a remediation obligation with no external route to satisfying it.

‍

How Does That Interact With the Support Period?

‍

Badly, since the support commitment has a floor of five years. A product built on components with shorter remaining lifespans than the support period it carries has a commitment the dependency stack cannot underwrite, and the shortfall arrives partway through rather than at the start. Pricing a weakness while it stays open is the arithmetic that applies.

‍

Which Dependencies Create the Exposure?

‍

Not the vulnerable ones, which is the useful reframe. The exposure sits in the unmaintained ones regardless of their current vulnerability status.

‍

A component with a known vulnerability and an active maintainer will receive a patch, so the cost is an update cycle. A component with no known vulnerability and no active maintainer is a future obligation with no external supplier, and its cost arrives whenever a vulnerability is discovered rather than now.

‍

Which Makes Upstream Health a Measurable Input

‍

Counting dependencies whose upstream project shows no recent activity produces the population where you are the maintainer of last resort. The figure is derivable from public repository data and it is the input a cost estimate needs, since each such component carries a probability of requiring internal patching over the support period, and cyber risk quantification turns that population into a funding case.

‍

Where Does the Upstream Duty Not Apply?

‍

Two situations, and knowing them prevents wasted effort on components where the requirement is already satisfied.

‍

Where the component no longer has a maintainer, there is nobody to report to and the duty falls away, leaving the remediation obligation intact. Where the manufacturer has forked the component and no longer relies on the original project for versions or fixes, the same applies since the relationship has ended. Both are narrow and both are worth documenting when they apply, because the absence of an upstream report otherwise looks like an omission.

‍

Does a Pull Request Satisfy It?

‍

Probably, for a project that still exists but has been quiet. Filing an issue or submitting a change through the project's normal process is the mechanism the requirement contemplates, and a documented attempt through the available channel is a considerably better position than silence. Where a fix is shared it should go out in a way compatible with the component's own license.

‍

What Should the Contract Say?

‍

For commercial components, two things, and both are easier to obtain than the visibility they replace.

‍

Notification of actively exploited vulnerabilities within a window short enough to leave you time to report, since a supplier notifying on a monthly cycle makes a 24-hour deadline unreachable regardless of your own capability. Then a stated support commitment at least matching the period you have committed to your own customers, since a component going unsupported partway through your support window transfers the work to you.

‍

What About Components With No Contract?

‍

Which is most of them, and the substitute is selection rather than negotiation. Upstream project health becomes a procurement criterion for open-source dependencies in the same way financial stability is for suppliers, assessed when the component is chosen and substitution is still cheap rather than after a product has shipped on it, and diligence on something you are about to acquire applies the same reasoning to a different object.

‍

Does This Change Which Components You Choose?

‍

It should, and the criterion is different from the one most teams apply. Dependency selection has historically weighed functionality, license and popularity.

‍

Popularity is a weak proxy for what matters here. A widely used component with a single unresponsive maintainer carries more future obligation than a less popular one with a funded team behind it, and download counts reflect neither. What matters is whether somebody will still be issuing security fixes in five years, which is a governance question about the project rather than a technical question about the code.

‍

What Should Be Assessed at Selection?

‍

Four things, all visible publicly. Whether the project has more than one active maintainer, since a single point of failure upstream becomes your obligation. Whether it has a security disclosure process, since without one your upstream report has nowhere to go. Its release cadence over the last two years. Then whether any organization funds the work, since volunteer maintenance is the least predictable input in the stack.

‍

Does That Argue Against Open Source?

‍

No, and reading it that way would be a mistake. A commercial supplier can discontinue a product, change terms or fail, and the contractual remedy is frequently worth less than it appears. The difference is that open-source project health is publicly observable while a supplier's roadmap is not, so the assessment is easier on the open-source side, and dependency you cannot diversify away applies to both.

‍

What Should Be Established First?

‍

Four things, and the first two are the ones that make everything else possible.

‍

A component record per shipped product version, since neither reporting nor remediation can be determined without knowing what is inside, and the reachable surface is defined by the same record. The maintenance status of each significant dependency, which identifies where you are already the maintainer of last resort. Whether any product carries a support commitment longer than its dependency stack can underwrite. Then which suppliers have notification timing in contract, since the fastest internal process cannot outrun the slowest supplier. Other clock-based regimes create the same dependency.

‍

Integration Is Now Stewardship

‍

A vulnerability in a component you did not write is yours to report, and the reporting is the visible half of it. Remediation applies to the product in its entirety, so where a maintainer has stopped or never existed commercially, pointing upstream is not a response and the options reduce to disabling, replacing or patching yourself. The obligation runs one way, since you owe the maintainer a report and a fix while a non-commercial maintainer owes you nothing. An end-of-life dependency is therefore the planning case rather than an edge case, particularly against a support commitment with a five-year floor. The exposure also sits in unmaintained components rather than currently vulnerable ones. Kovrr's cyber risk quantification prices the population where you are the supplier of last resort.

‍

To see what your unmaintained dependency population would cost across a five-year support commitment, book a demo with our risk experts.