Integrating open source
The core rule
When you integrate a free component into a product you place on the market, you carry the full regulatory responsibility for it. Upstream is not responsible on your behalf, whatever the licence.
That follows directly from the Regulation’s architecture: responsibility tracks placing on the market, not writing the code.
The due diligence obligation
The manufacturer must exercise due diligence when integrating components sourced from third parties, including free components, so that those components do not compromise the cybersecurity of the product.
That diligence must be documented, component by component, to be defensible.
Diligence grid
| Criterion | What you check | Source |
|---|---|---|
| Known vulnerabilities | No unfixed known exploitable vulnerability | EUVD, OSV, NVD, upstream advisories |
| Project activity | Release frequency, date of last commit, number of active maintainers | Repository |
| Governance | Backed by a foundation or a steward? Single maintainer? | Project documentation |
| Upstream security policy | Existence of a SECURITY.md, a reporting channel, an advisory history |
Repository |
| Historical responsiveness | Average interval between report and fix on past vulnerabilities | Advisory history |
| Licence | SPDX identifier, family, compatibility with your policy | Licence families |
| Upstream SBOM | Does the project publish an SBOM itself? | Project releases |
| Artefact signing | Are releases signed and verifiable? | Releases |
| Depth | Number and nature of transitive dependencies introduced | Analysis |
A composite score supports the decision to adopt, adopt under watch, or refuse. The completed grid is filed with the product’s diligence file.
This grid is unworkable by hand beyond a few dozen components, and a real dependency graph holds thousands. Six of these nine criteria can be computed automatically: see Assessing an open source component, which covers the tooling, what it captures, what it does not tell you, and the threshold policy to write.
The upstream reporting obligation
Where you identify a vulnerability in an integrated component, including a free one, you must:
- report it to the person or entity manufacturing or maintaining that component;
- address and remediate the vulnerability in your product;
- where relevant, share with the upstream project the fix you developed.
This is an obligation, not a good practice. It requires a tooled process:
- an identified channel to each critical upstream project — security address, private reporting procedure;
- a log of submissions: date, project, vulnerability, content of the report, response received, fix shared;
- a contribution policy allowing your engineers to publish a fix under the upstream project’s licence, without a legal review cycle of several weeks that would make the obligation impossible to meet.
A frequent point of friction. An intellectual property policy that forbids employees from publishing any code makes it impossible to meet this obligation. The two policies must be reconciled explicitly, in writing.
Abandoned components
An unmaintained component inside a product covered by a five-year support period is a regulatory liability: there will be nobody upstream to fix the next vulnerability.
Four strategies, to be decided product by product and documented:
| Strategy | When | Cost |
|---|---|---|
| Replace | A maintained alternative exists | Migration cost, one-off |
| Fork and maintain | No alternative, central component | Recurring, over the whole support period |
| Bring in-house | The component is small and its scope stable | Take-over cost, then maintenance |
| Contribute to reviving it | The project is viable but under-resourced | Recurring, outcome not guaranteed |
“Do nothing and hope” is not defensible before an authority, since the end of upstream maintenance is a public fact and therefore known to you.
The malicious takeover watch point
An abandoned component whose control is taken over by a third party is a documented supply chain attack vector. Monitoring maintainer changes on critical dependencies is part of ongoing diligence — see Supply chain risk.