CRA compliance: lifecycle management

[mrybczyn]

The CRA requires a complete security lifecycle of a project. The specification concentrates on the period when the product is already present. Possible additions:

• state that this process applies on the whole lifecycle (monitoring for vulnerabilities at the development time, accepting reports for alpha/beta/rc)
• describe how we handle EOLs

[dirkx]

And 3) how we announce/advertise EOLs (as currently the CVE system is not used for marking a package as `dead').

[rjb4standards]

Our SCRM risk assessment process tracks two risk factors, Commercial Status and Support Status when determining a trust score.
Commercial Status is used to indicate Retired, EOL, status.
Support Status is used to indicate level of support provided, i.e. community in the case of some open source projects.

This XML schema contains the enumerated vales for both Commercial and Support Status:

[oej]

The CVE program may allow end-of-life in the future: https://nodejs.org/en/blog/vulnerability/updates-cve-for-end-of-life

OWASP Common Lifecycle Enumeration (ECMA 428) can be used for lifecycle events:
https://tc54.org/cle/

[oej]

The chicken-and-egg problem is how to mark dead projects as dead - well, if there's a steward it's the responsibility of the steward (if they're alive). If it's a project without a steward where the maintainers are not reachable, there needs to be a third party trusted source for this kind of information.