[
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
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
--
_______________________________________________
open-regulatory-compliance mailing list