Since 11 September 2026 the EU's Cyber Resilience Act has had a live reporting obligation, and the rest of the regulation follows on 11 December 2027. One sentence in Article 13(5) already shapes how software teams should treat dependencies: manufacturers "shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product," including free and open source components not made available on the market in the course of a commercial activity.
A policy is how you show that diligence is a habit rather than a hope.
What's affected
Every product that uses open source libraries, base images, SDKs or vendor components, which is nearly all of them. Two related duties sit in the same article. Article 13(6) says that when you find a vulnerability in an integrated component you must report it to whoever maintains it, and address it under Annex I Part II. Annex I Part II point 1 requires an SBOM covering at least the top level dependencies.
The SSDF 1.2 initial public draft (17 December 2025) states the same ideas as tasks. PW.4.4 asks you to verify that acquired commercial, open source and other third party components comply with your own requirements throughout their life cycle. Its examples include regularly checking for publicly known unremediated vulnerabilities and building automatic detection into the toolchain.
How to check if you're exposed
Ask five questions of any repository:
- Is there a list of direct dependencies with an owner who approved each?
- Is there an SBOM per release?
- Does CI fail or warn on known vulnerable components?
- Do you know the end of life date of your runtime and base image?
- Has anyone ever reported a bug upstream?
Each "no" is a gap the policy below closes.
What to do now
Adopt this text, then edit it to match what your team will really do.
Third party component policy
Owner: Head of Engineering Reviewed: 2026-10-18 Next review: 2027-10-18
1. Approval. A new direct dependency needs a pull request that states
its purpose, license, maintainer and known alternatives.
2. Criteria. We do not adopt components that are unmaintained,
have an unacceptable license, or have no identifiable producer.
3. Inventory. Every release has an SBOM in CycloneDX or SPDX,
generated in CI and stored with the release.
4. Monitoring. Known vulnerabilities are checked on every build and
daily for released versions.
5. Response. Critical findings that are reachable from our code are
fixed or mitigated first. Decisions not to patch are written down.
6. Upstream. Vulnerabilities we find in a component are reported to
its maintainers.
7. End of life. Each runtime, framework and base image has a recorded
end of life date. Replacement is scheduled before that date.
8. Exceptions. Approved by the owner, time limited, logged.
Then wire it up. Generate the SBOM in CI, add a vulnerability check on pull requests, and record end of life dates in the repository. Reachability analysis, meaning whether your code actually calls the vulnerable function, helps with item 5 by showing which findings need action first.
How to avoid this trap
- Do not write "all dependencies are reviewed" if you review only direct ones. Say what you actually cover.
- Do not forget the base image and build tools. Both ship components.
- Do not let the policy age. Tie the review date to a calendar entry.
Why it matters
Article 13(8) lets manufacturers weigh "the support periods of integrated components that provide core functions and are sourced from third parties" when setting their own support period. Your promise to customers is only as long as your shortest dependency's support. The inventory behind this policy is how you find that shortest link.
Try it yourself
Pick one repository and answer the five questions above. Then build the dependency inventory and mark the oldest component.
Click through it at your own pace, or open it full screen.
Quick check
Does CRA Article 13(5) cover open source components?
Yes. It names free and open source software components, including those not made available on the market in the course of a commercial activity.
What must you do when you find a vulnerability in an integrated component?
Report it to the person or entity manufacturing or maintaining the component, and address it under Annex I Part II (Article 13(6)).
