The compliance audit flagged software that's no longer supported
A compensating control buys you one cycle. HeroDevs puts the software back under support and ships the evidence with every fix, so it stops being something you have to answer for.
.webp)
Unsupported open source software carrying vulnerabilities is grounds to withhold certification
Your assessor found a package that nobody maintains anymore, and wants to know who patches it and how fast. There is no answer, because end-of-life open source no longer receives security patches from its maintainers and no upstream fix is coming.
The cost is not having the certification at all, which impacts business continuity.
What breaks when upstream patches stop
Security
CVE open, no fix
Compliance
No evidence to show
Roadmap & budget
Migration inserted, speed unplanned
.webp)
How much unsupported software would an assessor find?
Get a report of every end-of-life dependency across your repositories, direct and transitive.

The Problem
Every path to clearing the assessment carries a cost
Write a compensating control
Mitigate around the package and submit a risk acceptance. The assessor decides whether it is enough. You are betting the certification on someone else's judgement, every cycle.
Migrate under a deadline you didn't set
Answers the question properly, and costs a migration nobody budgeted for. Breaking changes across every call site, other packages pinned to the major you are leaving, and a full regression pass, scheduled around an assessment rather than your roadmap.
Have AI patch it
Fast, and increasingly expected. But the assessor is not asking whether the code is fixed, they are asking who maintains it. An AI-generated patch answers neither question, and now nobody has reviewed the code either.
The Solution
Move to a HeroDevs-supported version and clear the audit
A HeroDevs-maintained release replaces the flagged package
A secured release inside the line you already run, maintained for as long as you run the software.
The evidence ships with the fix
Every remediation delivers a VEX statement and a signed attestation, mapped to the frameworks you already report against.
New vulnerabilities keep getting patched
New CVEs against covered packages are patched under a 14-day CVE SLA, so the same question does not come back next cycle.
Why HeroDevs?
19M+
package versions tracked
1,000+
vulnerabilities remediated
900+
enterprise customers secured by HeroDevs
We maintained our security posture without compromising our strategic roadmap, all while achieving substantial cost savings compared to a full migration.
Markus Wolf, Architect @ Statista
Everything you need to clear the audit, documented and filed for you
.webp)
What security and compliance teams ask
Get answers to some of our most commonly asked questions.
Of course, if you can't find the answer you're looking for, feel free to contact us.
A VEX statement per remediation, stating whether the CVE affects the delivered package, plus a signed attestation. Both land in a compliance folder in your repository alongside the code.
SOC 2, PCI DSS, HIPAA, FedRAMP, CRA, DORA, GDPR and more. The same evidence serves all of them; you are not producing a separate artifact per framework.
It resolves it. What the assessor flagged was that the software is unsupported. Once it is supported and patched under an SLA, that is no longer true.
That depends on how long you expect them to hold. Compensating controls are accepted at an assessor's discretion, and the longer the same exception runs, the harder that discretion is to win.
Covered packages fall under our 14-day CVE SLA.
Yes. The same evidence answers a customer questionnaire, and a supported component removes the objection rather than explaining it.
Something not covered here? Talk to an expert.