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.
Right - but that is what I mean. You are a Manufacture with some very critical product M that is, say, based on some Apache-Foo parser where the ASF is the open source steward
That parser has a bug found by a reporter R. R reports it to the ASF. It also lets the ASF know that they found it as it was being exploited on their systems.
The ASF does the usual triage, the Apache-Foo PMC picks this up and starts the normal, in private, conversation & fixing process, assigns a CVE, etc During which only R and a limited, need to know group of volunteers at the ASF are aware of this.
Once there is a fix; in coordination with R - the ASF releases the patch; publishes the CVE, does re-releases and the usually comms for the down stream. At that point M hears of it - and it should update their product and tell their users in a perfect world.
Post 11 December 2027 we would have reported this to the SRP - and hopefully the powers that be would have made sure that M heard this. Now it has to wait for the ASF to do the fix.
If the same thing happened through R reporting to M reporting to the ASF (which is actually not that common - most reports tell us first/at the same time - because they get desensitized by companies not doing anything / understand that the impact is probably way larger than just M) - the 11 September would have lead to a repot.
Hence by 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.
And the reports will more often than not go not the open source foundations -- because the reporters already understand what code the issue is in.
Or am I making a reasoning error here ??
Dw.
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
