We also see projects that have a number of outstanding security issues that they are aware of, but choose to do a release that fixes some now, with the rest to follow in some future release. This overlaps some of your categories - for example if there is some issue where the fix is complex, but the overall severity of the issue is very low the project may delay that fix rather than delay a release to include all the fixes. Similarly if there was an issue reported today under active exploit a project may well decide to do an immediate release for to address that issue, even though they are aware of and currently in the progress of fixing, other security issues. So we do not want to introduce some rule that projects must not make new releases that have unfixed security issues as that could cause delays in getting fixes out for the issues that actually matter.
Regards, Mark On Thu, Oct 23, 2025 at 1:04 PM Mark Thomas <[email protected]> wrote: > Following on from a discussion at Code & Compliance... > > 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. However, there are some scenarios where OSS releases > may be made without disclosing a known security vulnerability. > > 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. > > > 1. Embargoed issue > > Consider the case where the following are all true: > - the project is affected by a reported issue and that issue has an > embargo for 3 months time > - the project has a regular monthly release cycle > - the nature of the issue and/or fix is such that project can't silently > fix the issue with essentially disclosing the issue and breaking the > embargo > > If the project stops releases until after the embargo it is effectively > declaring there is a security issue under embargo. > > If the project continues monthly releases, it has to release without > fixing the issue. > > In most cases I would expect continuing releases (which may provide > fixes for other issues) is the better option. > > Not having long embargoes would also address this but there are some > manufacturers for whom that would be difficult. > > Real world example: > CVE-2025-48989 HTTP/2 Made You Rest and Apache Tomcat > > > 2. Reports during release process > > The release process is not instantaneous. In some OSS projects it can > extend over a period of days as community members are given an > opportunity to validate and/or review the release. > > If a vulnerability report is received during the release process then > the project team may make the decision to continue with the release even > if the reported issue is determined to be valid. > > Factors that may be taken into consideration include: > - is it possible to cancel the release without signalling that the > release is being cancelled for a security issue (since that would focus > attention on subsequent commits and significantly increase the risk of > the vulnerability leaking before the fixed release was available) > - what fixes (bugs and vulnerabilities) would be delayed if the release > was cancelled > - how severe is the reported vulnerability > - are workarounds available for the reported vulnerability > > Essentially, this is a risk assessment with the project making the > decision which is the lowest risk option for the community as a whole. > > > 3. Waiting on fix in dependency > > Similar to 1 but rather than an embargo, the project is aware of an > issue in a dependency but the fixed version of the dependency will not > be available for several months. > > > 4. Complicated fix. > > Similar to 2 but in this case, due to the complexity of the issue and/or > the fix, the project expects that the time taken to produce the fix will > be longer than the typical release period (e.g. monthly) for the project. > > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > >
