Vulnerability audit and security evidence validation. MC CRA Engine checks the libraries your software uses, flags the security advisories potentially relevant to the analysed versions and reports the published fix versions, when available. Every check leaves a trail that can be verified.
It helps prepare the work required by the Cyber Resilience Act, but it does not certify compliance.
Knowing whether a library used in your product has known security issues, and which version fixes them.
Having, for each component, a clear picture of what was found, what is excluded and why, and what remains to be checked.
Being able to show how component vulnerabilities are handled, with dated evidence tied to the analysed version.
Three steps, from the list of components to the report.
It starts from the list of libraries used by the software and their versions, in the standard format called SBOM.
For each library, security advisories are looked up in the public OSV database. Python and PHP components are tested on real cases today; JavaScript is being tested.
Each result reports the source, the date of the lookup and the digital fingerprint of the data used, so the check can be repeated and compared.
They can also be used separately.
Compares the software components with public security advisories and separates what is only potential from what really affects the product, flagging when this cannot be determined.
Checks that the collected evidence is intact, of known origin and tied to the analysed version.
For each analysed component: known vulnerabilities found in the consulted sources, references to the evidence, justified exclusions and published fix versions, when available. Upgrade indications require a compatibility check and testing; no change is applied automatically.
The installed version falls within those indicated by the advisory: it needs to be assessed.
The available evidence confirms that the conditions stated in the advisory are present in the product. It does not imply that exploitation was performed.
The advisory does not affect the analysed version or configuration, and the reason is written down.
The information needed to decide is missing: this is stated clearly, instead of giving a result.
Results of the 28 October 2026 test on two real libraries, computed on the data archived on that date.
In the offline comparison on LiteLLM 1.82.3 and Symfony http-foundation 2.0.4, based on the OSV responses archived during the D2 test, the fix version references match those reported by CRA Evidence in all 29 advisory groups compared.
CRA Evidence is a third-party open source tool, used as the term of comparison; the D2 test is the comparative test run on 28 October 2026. The result concerns the fix version references: it does not prove the applicability of the vulnerabilities nor an overall validation of the product. The 29 groups correspond to the 20 LiteLLM vulnerabilities and the 9 Symfony ones, after grouping equivalent identifiers.
The European Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to handle vulnerabilities during the lifecycle of their products. Reporting obligations apply from 11 September 2026, the main obligations from 11 December 2027. MC CRA Engine helps prepare this work, but it does not certify compliance.
Technical note. The versions suggested in the test are results based on the data archived on 28 October 2026, not recommendations updated to the publication date. The source consulted is the public OSV.dev database. MC CRA Engine analyses components with public advisories, not the code written by the user. The independent review of the work that introduced the fix suggestions was not completed.
