Those are all valid scenarios and very well described. I can give an example from Airflow for 3. and 4. combined:
CVE-2024-49767 Werkzeug vulnerability, we could not upgrade to a newer version of Connexion 3 (so point 4. from your list) because of a complicated fix (we tried and failed), So we had to wait for Connexion 2.15.0 release (which happened finally after a year of discussions, PRs and back-forth) so now we finally can release (working on it) Airflow 2.11.1 with the updated dependency. Also - that is partially another case 5. in fact and we might add this one: 5. Unknown impact of 3rd-party dependency Similar to 4, where fix (usually upgrade) is complex (but possible), but also where the PMC is not aware of any exploit and their investigation shows that the CVE in a dependency does not impact what we are releasing. Due to the nature of security issues, it's often impossible to have certainty about the impact of 3rd-party dependency, generally speaking you might prove that you are vulnerable, but often you can't prove that you are not. In this case PMC might decide to NOT invest in the upgrade without having exploitation POC. Actually the CVE-2024-49767 is also an example of 5. - we **think** we are not impacted (due to the functionality of Werkzeug - multipart forms - that is affected by it) - but we cannot be sure. We are not aware of a scenario where it can be exploited - that's why we opted to wait until release of Connexion is made available - that was continuing across multiple releases and was a deliberate decision of the PMC not to invest our time in it. J. On Thu, Oct 23, 2025 at 2: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] > >
