Update: Our vulnerability process has been approved. You can access a FAQ.
This document contains the requirements for a CVE process to be defined for AllScenariosOS. Please add your comments, additional ideas and difficulties you can think about.
What is the CVE process for
The CVE process describes the way of handling security vulnerabilities. It should define clearly who is doing what.
Our process should be aligned with industry best practices. Examples of those practices include OSS vulnerability guide, OpenChain standard when available, OpenSSF recommendations.
The process should include all elements from CII Best Practices
Reporting a security issue to us
The project should have a way to report a security issue in the code owned by the project or in the upstream code.
There should exist a security mailing list with limited audience, that should be used for anyone (developer, user, security researcher) to report security issues or to discuss security issues in the project. This would be used by upstream projects for notifications, and security researchers used to this way of reporting issues.
We can also have a way to report a security issue using a bug tracker, with a way to mark such issue as security related and confidential. Issues reported this way should be visible to a limited audience (same as the issues on the mailing list) until eventually reclassified.
There should be a way to report an issue in a confidential way (not using a public ticket).
Where the issues come from?
Security issues may come from different sources:
- Reported to the security list by anyone
- Found by the project developers
- Entered initially in the project bug reporting system and re-classified as a security issue
- Received from upstream projects as updates
- Received as a new CVE list
- Notified from upstream projects (possibly under an embargo)
Security issue lifecycle
Typically the process for security bugs / CVEs is divided into fours phases:
- Monitoring (meaning, us looking at upstream and CVE databases and mailing list - we should look into joining those mailing lists by appointing a security owner - since some CVEs fall into embargo so only companies participating get to know of a CVE and fix it before it is disclosed to the public)
- Assessment, i.e. whether or not all scenarios is is impacted by a CVE
- Remedy, meaning fixing such CVE during dev and in particular LTS
- Notification, meaning a dashboard that lists all CVEs being monitored, assessed, fixed (or not required to be fixed) and delivered (i.e. a commit ID or a given release tag).
Embargo is a period of time until the security issue is made public. The time should be used to provide a patch and deploy it if possible. The patch during the embargo should contain no information or suggestion about the security issue, it should be just describing what the fix is.
We can do a fix at the source level on an item under embargo. In this case the developer should mention only what is fixed, not include any reference to the CVE. A fix might have a title like ‘fix a NULL pointer dereference in module X’. When the embargo is over, we publish the advisory and can (but do not have to) point to the actual commits. We can distribute patches if necessary.
Issues from upstream projects may come to ASO during the embargo period. In this case they should be handled according to the rules of the upstream project (eg. duration, type of people who can be notified etc).
ASO project may decide on embargoes in the issues we’re upstream for if the security impact is judged important enough. The embargo period should be long enough to allow fixing, but also motivating to do it in time.
Security vulnerabilities are special classes of bugs
Security vulnerabilities are special bugs. The bug handling process applies to them (with some changes). For example, the SLA that applies to bugs should apply to security issues in general, too. SLAs will then map to priority classes (which we’ll need to define).
CVEs when released get a CVVS score representing the issue severity, with 10 being the maximum. We will define a way to map CVSS scores to big priorities. For example, mapping CVEs scored 9 and 10 in the CVSS score scale to a P1 (critical) bug for All Scenarios OS - CVEs scored 7 and 8 could be mapped to high, etc.
Reviewing bugs for security issues
General bugs should be reviewed for security issues and may be reclassified as security issues. If they are one, they should follow the security process from that point.
All notifications of security issues should be reviewed and responded in limited time. We should define the time and the organization that allows that review (composition of the team).
Handling upstream and downstream
The project must handle issues from both upstream and downstream. It should be tracking released CVEs to include the fixes if necessary (a process similar to the one of Debian) could be put in place.
Security issues might have different severity levels. The project should define its levels and actions related to each level. For example, every issue classified as ‘high’ could get an announcement, is fixed in 7 days. On the other hand, ‘low’ severity issues may be fixed by periodic updates.
Releasing security announces
The project should release security announcements for issues that need to be fixed immediately (as defined above in the issue priorities). It should also provide a list of issues fixed with each release.
Releasing product status
We can think of publishing via a RSS feed or a periodical bulletin the stats in a report showing which products are affected by which issue. It might be done in the security announcements.
Getting CVE numbers
We need a way to get CVE numbers. This will be either direct by becoming a CVE Numbering Authority (CNA) on our own, or indirectly by requesting numbers in another CNA.
The role of users
Users, the vendors of devices using AllScenariosOS are an essential part of the process. They should have representatives in the security committee.
They should also have a (secure) way to receive the information about urgent updates in advance, for example when the issue is under embargo.
We might consider creating a bug bounty program.