Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Update on reporting obligations for open source software stewards

On Sun, Sep 6, 2026, at 12:15, August Bournique via open-regulatory-compliance wrote:
So the distinction between an actively exploited vulnerability and a severe incident is somewhat vague to me - both require an attacker to be doing or have done somethign to the product ...

It's easy to find severe incidents that don't involve exploited vulnerabilities: insider threats, brute-forced weak passwords, misconfigured machines, etc etc.

I agree they also go together: if my product is a software package, and you run my software as part of your product, then a vulnerability in my software/product could lead to an incident in your service/product. You'd need to report an incident, I'd need to report a vulnerability.


Arnout


they are both incidents of a sort.  A manufacturer doesn't need to report an "exploitable vulnerability", only one where a breach etc occured. The distinction matters somewhat because the reporting timeline (at least the last part of it) is different, but the line between the two seems to be something about both impact (severity) and duration.  It might be possible to imagine an exploited vulnerability that one discovered occurred six months ago, but that had only a minimal impact ... and argue that it was neither a severe incident (though it was an incident) or a an actively exploited vulnerability (it happened long ago - so it's no longer actively exploited).  Though I suspect one should report even this, because it's easier then arguing with a cranky MSA if the incident proves to be worse later ... However, one could likely report it then and claim lack of knowledge regarding severity, and hence no undue delay in reporting.  

That's my reading at least.

Sincerely,

August

On Sun, Sep 6, 2026 at 12:46 AM Tobie Langel via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:


On Sun, Sep 6, 2026 at 12:33 AM Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Does it then apply to the oss projects that the steward is using/depending upon to provide that build server (eg. compilers, encryption, dependency mgmt systems, etc)?

No, this focuses strictly on severe incidents affecting infrastructure provided to stewarded projects. Not CVEs in the infrastructure's components. 

Huh?  The log4j vulnerability (e.g.) was a severe incident that affected much sw infrastructure...provided to projects of many kinds, build systems, etc...as well as many other kinds of components (open source and commercial).  I don't see how you can you separate 'infrastructure provided to stewarded projects' from 'infrastructure' in general.

No. log4j was a vulnerability, not an incident. An incident is when a vulnerability is actually exploited, or some other event occurs, resulting in a compromise or material disruption of the infrastructure. So in the log4j case, a steward would have notification requirements for a vulnerability if they were the steward of log4j AND were actively involved in its development. They would have a notification requirement of a severe incident if running an unpatched version of log4j caused a build server they provided to a project to be compromised.
_______________________________________________
open-regulatory-compliance mailing list
To unsubscribe from this list, visit https://accounts.eclipse.org


--

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org



Back to the top