[
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
|
So it looks like we've got two discussions here now. My take on both is this:
First, as has been mentioned, stewards have no reporting duties under the CRA until 2027. When they do have article 14 reporting duties this will only apply to stewards with fairly deep involvement in an open source product. Exactly what that involvement entails may be a bit of an open question.
I would add to this though that personally I think stewards who can should actively step into the reporting role early. Reporting to the SRP is not especially arduous, but it might be time consuming, and internal structures/coordination/communication for when to do so can be tricky to set up. The next year is also likely a time when manufacturers with open source components will be deciding if they want to fork or perhaps support these components and a stewardship organization offering actual help with CRA compliance/component due diligence may make the support option more appealing. Plus, as Daniel pointed out - some union members are up to shenanigans regarding extra reporting requirements. Best to be prepared, and hope they aren't entirely different from or contradictory to the CRA ones.
Second, manufacturers absolutely need to report severe incidents and actively exploited vulnerabilities in components if they effect thier product. If there is a severe incident/actively exploited vulnerability for a product that involves a component ... it's still a severe incident/actively exploited vulnerability for the product. The only exception I can see would be an actively exploited vulnerability/severe incident one notices in the component that doesn't effect one's product - it's happening elsewhere. Since this isn't effecting the manufacturer's preoduct (either because it's mitigated in the product somehow or because it just hasn't happened yet), there's no duty to report it. 13(6) upstreaming requirements are broader as they cover all vulnerabilities, but don't kick in until next year.
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 ... 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@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--
