Hi Mark,
On 23.10.2025 14:03, Mark Thomas wrote:
> There is currently an expectation in the CRA that a product will not be
> released if there are known (by the maintainer) security vulnerabilities
> in that product.
I may have missed a specific reference, but could you point me to a
source or legal interpretation where the CRA defines “known
vulnerabilities” as including vulnerabilities only internally known to
the maintainer (i.e. not publicly disclosed and not known to be
exploited)? While resolving all vulnerabilities before release is
desirable, as you noted, this may be impractical for software with a
regular release cadence.
> Dirk asked me to document these so he can raise them with the EU.
> Feel free to add additional scenarios and/or comment on these ones.>
> There is a general expectation behind all of these that the projects
> are following open development as well as producing open source. If
> development is not open, a parts (but not all) of the issues
> described below can be avoided.
I can think of two additional scenarios that may be relevant:
A. Projects overwhelmed by security reports
A project may receive dozens of vulnerability reports in a short
period. It may prioritize fixing the most critical first, addressing
medium and low severity later. While fixing everything immediately
would be ideal, it is also important to avoid long-term retention of
undisclosed vulnerabilities.
B. Vulnerabilities of unclear exploitability
The CRA refers specifically to the absence of “known exploitable
vulnerabilities”. There are realistic situations where a maintainer
might know about a vulnerability, but not know about its
exploitability:
- A vulnerability may be publicly known but unresolved for technical
reasons (e.g. upstream dependency requires Java 8 but the project
must remain on Java 7). Additionally the exploitability of such a
vulnerability may still be unknown.
- Conversely, projects should reasonably be able to publish releases
*with* “known vulnerabilities” if those vulnerabilities are
verified to be non-exploitable in their context.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
