| Re: [open-regulatory-compliance] Open Source Software Stewards and CRA Whitepaper: review in progress until November 20th |
<stuff deleted>
We’re working on the attestations to figure them out, but they
*MAY* be a way to simplify the manufacturer’s due diligence. A steward may also have a process
to be more clear about lifecycle events for an open source project.
Well, they should. Otherwise they wouldn't be much of a steward?
All one has to do to find existing problems with 'non-profit/profit/Foundation as open source steward' approach is to look at an existing org-hosted project's dependencies. There are *many* large popular open source projects where plenty of resources, time, money, managers, lawyers, insurance, other 'middle-men' exist (and are often well-payed) to keep that project secure...e.g. all of the Foundation's 'flagship' projects/applications.
But look 1-level or more down in the project dependency tree (e.g. modules/libs that are used, or libs that those libs use, etc.) and the situation changes completely. Historically, many (if not most) of the major security issues in open source end up being underneath the top level projects...in the middle and lower layers of the technology 'stack'. Examples: log4 (a widely-used logging library, heartbleed (openssl), middleware, operating-system or even hardware issues. The current situation is that these lib/infra projects do not get support necessary to even continue in many cases...and asking them to add maintenance work through frequently unsupported 'contributions' is just impossible.
Further, it's not reasonable to expect that just anyone (even in the dev community specifically) will be able to actually provide reasonable 'stewardship' for n-level dependencies...no matter what is said in the marketplace. IMO, there needs to be some requirements put on 'stewards' that recognizes and addresses this problem wrt dependencies...as such dependencies are a part of what defines open source 'community', 'transparency', as well as 'collaboration'.
_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org