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]
