> On 23 Oct 2025, at 19:09, Piotr P. Karwasz <[email protected]> wrote: > > 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. That must be a misunderstanding here somewhere. The CRA talks about products “placed on the market”. I don’t think Open Source counts as that. The CRA also talks about three categories of vulnerabilities - known vulnerabilities - exploitable vulnerabilities - known exploited vulnerabilities
I think that it says that products should not be placed on the market if the product - including dependencies - has known exploited vulnerabliities. The guidelines has not been published of what this means. A possible inspiration can be the Technical implementation guide to NIS2 that was published by ENISA in June - https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance I haven’t read it fully, but I glanced over the parts about vulnerability management and was not very impressed and a bit shocked. But I guess that is another story. My real question here is whether the obligation to place a product on the market without (some level of known) vulnerabilities applies to Open Source? /O > > > 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] >
