To check whether a component still gets security fixes, look for a recent release, a published security contact or advisory process, a visible track record of fixing reported issues, more than one active maintainer, and a stated support policy. If you find none of these, treat the component as unmaintained and plan a replacement.
Why this check belongs before design freeze
The Cyber Resilience Act recitals say that when integrating components, manufacturers should check whether a component receives regular security updates and whether it is free from vulnerabilities in the European vulnerability database (Recital 34). Whatever your legal position, the engineering reason is stronger: a component that stops getting fixes becomes your problem, in a product you cannot easily change once it is in the field.
Six signals
| Signal | Where to look | Worry if |
|---|---|---|
| Recent release | Release page, tags | Nothing for a long time |
| Security process | Security policy file, contact | None published |
| Fix history | Past advisories and how fast fixed | Reports sit unanswered |
| Maintainer depth | Contributors, commit authors | One person, inactive |
| Support statement | Docs, roadmap | No end of life date given |
| Known issues now | Public vulnerability databases | Open issues with no fix |
No single signal decides it. A tiny library with one careful maintainer can be better than a big one nobody owns. What you are looking for is evidence that someone will react when a flaw is reported.
An afternoon process
- List the components in your SBOM that handle untrusted input: networking, parsing, crypto, update logic.
- Score each on the six signals above, with a short note.
- For anything weak, write the fallback: replace, fork and maintain, or isolate.
- Set a review date, usually every six months, and put it in the calendar.
- Record the result next to the SBOM entry so the decision is visible.
What to do with a weak component
You have three honest options. Replace it with a maintained alternative. Take it over and own the fixes, which means budgeting engineering time. Or reduce its exposure, for example by running it with fewer privileges or removing the feature that uses it. Doing nothing is a fourth option, and the record should say you chose it and why.
Why vendor blobs need a different approach
For a vendor binary, you cannot read the code. The signals become the vendor's published advisories, their support dates and their answer when you ask directly. Ask in writing how they notify customers of security fixes and how long a given SDK version is supported. Keep the answer.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each component shows its version and known issues.
Safeguard's dependency scanning can flag known vulnerabilities in the open-source packages of your app and backend repositories, a starting point for the check above.
Quick check
Is a library with no recent release always unsafe?
No. Stable code may not need releases. Look for an open issue backlog and whether security reports get answers.
Do vendors have to tell us about security fixes?
Not necessarily. Ask for it in your contract or support terms, and confirm how notices are sent.
Sources
Last reviewed: 19 October 2026.
