You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by Mark Thomas <ma...@apache.org> on 2025/10/23 12:03:35 UTC
Releasing without disclosing a known security vulnerability
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: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 10/23/25 8:03 AM, Mark Thomas 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.
5. Multiple vulnerabilities where some are much higher priority than others.
For example, an HTTP vuln that affects all users and is trivial to
exploit and also a separate vuln that only affects WebDAV users with
write-capabilities. It's much more important to focus on a fix for the
former while the latter can wait.
(Perhaps this is simply another incarnation of #4 above, since an "easy
WebDAV fix" would also be included in that same release.)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ma...@apache.org> 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: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: Releasing without disclosing a known security vulnerability
Posted by "Olle E. Johansson" <oe...@edvina.net>.
> On 24 Oct 2025, at 11:27, Mark Thomas <ma...@apache.org> wrote:
>
> On 24/10/2025 08:27, Olle E. Johansson wrote:
>>> On 23 Oct 2025, at 19:09, Piotr P. Karwasz <pi...@mailing.copernik.eu> 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.
>
> This thread started as direct result from a discussion at Code & Compliance. I'll let Dirk-Willem fill in the details but there is - currently - an expectation that OSS will not be releasing software with known vulnerabilities. The purpose of this thread is to collect examples as to why that might not always be the case so that at be fed back and the expectation corrected.
Ok. Wish I had been able to be there.
>
>> 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.
>
> No. Annex 1, Part 1, Para 2, point (b): "... without known *exploitable* vulnerabilities”
>
Ok
> It also doesn't define known by whom.
Exactly. I was hoping the NIS2 technical guidance would say something here, but it doesn’t seem that way.
>
>> 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?
>
> Directly, no, because Open Source Stewards don't place products on the market.
>
> However, if you look at the text around attestation programmes you see phrases like:
>
> "...voluntary security attestation programmes for assessing the
> conformity of products with digital elements qualifying as free and open-source software with all or certain essential
> cybersecurity requirements or other obligations laid down in this Regulation..."
>
> Given that one of the essential cyber security requirements is releasing without known vulnerabilities, that could apply to OSS if OSS wanted to use attestations. From a market efficiency point of view, manufacturers are going to want at least popular OSS dependencies to have attestations (even if the manufacturers have to fund that themselves).
Won’t there be a difference between projects that deliver “assembled” products like OCI containers or operating systems consisting of many third party products and projects that deliver a piece of their own code, maybe linux packages, that depend on third parties but do not deliver them?
There’s a lot of stuff here to think about. Good discussion! :-)
/O
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by "G.W. Haywood" <ge...@jubileegroup.co.uk>.
Hi there,
On Fri, 24 Oct 2025, Mark Thomas wrote:
>>> ...
>>> ...
>
> This thread started as direct result from a discussion at Code & Compliance.
> I'll let Dirk-Willem fill in the details but there is - currently - an
> expectation that OSS will not be releasing software with known
> vulnerabilities. The purpose of this thread is to collect examples as to why
> that might not always be the case so that at be fed back and the expectation
> corrected.
> ...
> ...
The message below arrived this morning. It may be a data point for you.
--
73,
Ged.
8<----------------------------------------------------------------------
>From security@slackware.com Fri Oct 24 00:12:29 2025
Date: Thu, 23 Oct 2025 15:27:40 -0700 (PDT)
From: Slackware Security Team <se...@slackware.com>
To: slackware-security@slackware.com
Subject: [slackware-security] openssl (SSA:2025-296-01)
Received-SPF: pass (mail6.jubileegroup.co.uk: slackware.com:
64.57.102.36 is authorized to use
'owner-slackware-security@slackware.com' in
'mfrom' identity (mechanism 'ip4:64.57.102.36/29' matched)
client-ip=64.57.102.36;
helo=connie.slackware.com)
X-AS-Number: AS11620
([SUCCEED-NET] [US] [64.57.102.36])
X-SPF-hello: none
([connie.slackware.com]=none)
X-SPF-mfrom: pass
([slackware.com]=[v=spf1 ip4:64.57.102.36/29 -all])
(DNS lookups=[0] void lookups=[0])
X-DKIM-auth: none
([2025-10-23 23:12:28Z mail6.jubileegroup.co.uk]
[result=No DKIM signature found in message])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[slackware-security] openssl (SSA:2025-296-01)
New openssl packages are available for Slackware 15.0 to fix a security issue.
Here are the details from the Slackware 15.0 ChangeLog:
+--------------------------+
patches/packages/openssl-1.1.1zd-i586-1_slack15.0.txz: Upgraded.
Apply patch to fix a moderate severity security issue:
Fix incorrect check of unwrapped key size in kek_unwrap_key()
The check is off by 8 bytes so it is possible to overread by up to 8 bytes
and overwrite up to 4 bytes.
Although the consequences of a successful exploit of this vulnerability
could be severe, the probability that the attacker would be able to perform
it is low. Besides, password based (PWRI) encryption support in CMS
messages is very rarely used.
This CVE was fixed by the 1.1.1zd release that is only available to
subscribers to OpenSSL's premium extended support. The patch was prepared
by backporting from the OpenSSL-3.0 repo.
Thanks to Ken Zalewski for the patch!
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2025-9230
(* Security fix *)
patches/packages/openssl-solibs-1.1.1zd-i586-1_slack15.0.txz: Upgraded.
+--------------------------+
Where to find the new packages:
+-----------------------------+
Thanks to the friendly folks at the OSU Open Source Lab
(http://osuosl.org) for donating FTP and rsync hosting
to the Slackware project! :-)
Also see the "Get Slack" section on http://slackware.com for
additional mirror sites near you.
Updated packages for Slackware 15.0:
ftp://ftp.slackware.com/pub/slackware/slackware-15.0/patches/packages/openssl-1.1.1zd-i586-1_slack15.0.txz
ftp://ftp.slackware.com/pub/slackware/slackware-15.0/patches/packages/openssl-solibs-1.1.1zd-i586-1_slack15.0.txz
Updated packages for Slackware x86_64 15.0:
ftp://ftp.slackware.com/pub/slackware/slackware64-15.0/patches/packages/openssl-1.1.1zd-x86_64-1_slack15.0.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-15.0/patches/packages/openssl-solibs-1.1.1zd-x86_64-1_slack15.0.txz
MD5 signatures:
+-------------+
Slackware 15.0 packages:
5917ba00eca52d7e3377c051c02772a6 openssl-1.1.1zd-i586-1_slack15.0.txz
1d8b3745c638b4788d22abf581ab3c2d openssl-solibs-1.1.1zd-i586-1_slack15.0.txz
Slackware x86_64 15.0 packages:
231482c02ec0e0ca42dffafaf8ef9e01 openssl-1.1.1zd-x86_64-1_slack15.0.txz
43b1705338bcd157b2e78f98d61ffd34 openssl-solibs-1.1.1zd-x86_64-1_slack15.0.txz
Installation instructions:
+------------------------+
Upgrade the packages as root:
# upgradepkg openssl-1.1.1zd-i586-1_slack15.0.txz openssl-solibs-1.1.1zd-i586-1_slack15.0.txz
+-----+
Slackware Linux Security Team
http://slackware.com/gpg-key
security@slackware.com
+------------------------------------------------------------------------+
| To leave the slackware-security mailing list: |
+------------------------------------------------------------------------+
| Send an email to majordomo@slackware.com with this text in the body of |
| the email message: |
| |
| unsubscribe slackware-security |
| |
| You will get a confirmation message back containing instructions to |
| complete the process. Please do not reply to this email address. |
+------------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQTsVknaQB4iq/pnNu9qRGPAQBAiMwUCaPqo7gAKCRBqRGPAQBAi
M3h5AJ9XHYnF3TVFgPrrGyQWAuW4qRZo8gCfcjF1lYU67kqQITkGC8nbdT/Pn6E=
=3GkA
-----END PGP SIGNATURE-----
8<----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by Mark Thomas <ma...@apache.org>.
On 24/10/2025 08:27, Olle E. Johansson wrote:
>
>
>> On 23 Oct 2025, at 19:09, Piotr P. Karwasz <pi...@mailing.copernik.eu> 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.
This thread started as direct result from a discussion at Code &
Compliance. I'll let Dirk-Willem fill in the details but there is -
currently - an expectation that OSS will not be releasing software with
known vulnerabilities. The purpose of this thread is to collect examples
as to why that might not always be the case so that at be fed back and
the expectation corrected.
> 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.
No. Annex 1, Part 1, Para 2, point (b): "... without known *exploitable*
vulnerabilities"
It also doesn't define known by whom.
> 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?
Directly, no, because Open Source Stewards don't place products on the
market.
However, if you look at the text around attestation programmes you see
phrases like:
"...voluntary security attestation programmes for assessing the
conformity of products with digital elements qualifying as free and
open-source software with all or certain essential
cybersecurity requirements or other obligations laid down in this
Regulation..."
Given that one of the essential cyber security requirements is releasing
without known vulnerabilities, that could apply to OSS if OSS wanted to
use attestations. From a market efficiency point of view, manufacturers
are going to want at least popular OSS dependencies to have attestations
(even if the manufacturers have to fund that themselves).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by "Olle E. Johansson" <oe...@edvina.net>.
> On 23 Oct 2025, at 19:09, Piotr P. Karwasz <pi...@mailing.copernik.eu> 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: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
Re: Releasing without disclosing a known security vulnerability
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
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: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Releasing without disclosing a known security vulnerability
Posted by Mark J Cox <mj...@apache.org>.
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 <ma...@apache.org> 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: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>