[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [open-regulatory-compliance] 24(3) not referencing 14(2), 14(4)
|
No, I am sorry if I was unclear. The reporting mechanism is EXCLUSIVELY self-reporting about your own product. The difference is:
Premarket -> no known vulnerabilities
This is about a product that should not be shipping vulnerable code in the first place when being placed on the market (your log4j concern) and is an essential cybersecurity requirement that manufacturers will be obliged to respect starting dec 2027 for all new and substantially modified products.
Aftermarket -> no exploited vulnerabilities
If log4j is the vector that enabled successful scans to escalate into compromise, then the vulnerability has effectively been exploited. This must be reported when the manufacturer has become aware of it. It is not Apache’s duty to report this.
I see how this can be confusing. The 11th Sept deadline is only talking about the aftermarket situation here.
On 7 Sep 2026, at 17:06, Daniel Thompson-Yvetot via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> But Dirk, why do you say nothing will be reported? If it’s indeed a KEV with actual IoC in the manufacturer’s product, then the incident must be reported under threat of penalties. A manufacturer suffering under an exploit or severe incident cannot just walk away from their problem because the “fault” lies in some OSS component.
Right - if they are aware of this exploit.
In 99 of the 100 historic cases - they never ware -- only the open source foundations were. Even today - a lot of manufactures still ship with vulnerable log4j code.
So my thesis is that 9 out of 10 of the qualifying things won't be reported - as the open source foundations will not inform their downstream normally until they have a patch. The manufacturer never hear of it in time.
Dw
