Common Vulnerabilities and Exposures (CVE) is a way of identification of known (cyber)security vulnerabilities in products. The vulnerabilities are identified by unique numbers, called CVE numbers. In this document we describe the processes related to vulnerability reporting, preparing patches and deploying them (called CVE processes) used in various Open Source projects, especially including those upstream to the AllScenariosOS.
The CVE database is available with a search option.
Yocto is leaving the security to the user - product developer.
Stable branches are updated for security fixes. Yocto LTS updates Bitbake, OE-Core, meta-yocto, and yocto-docs. Other layers are not included in the LTS.
Public mailing list
The class allows to define a product name or version for the CVE check if it is different from the ones in the Yocto recipes. There is a regular run on the OE layers and results sent to the public public list.
Reporting CVEs to Yocto
A private mailing list should be used security [at] yoctoproject [dot] org If it is an upstream issue, they forward it to the corresponding upstream project. They may also report it to the linux-disto list to synchronize a release.
Yocto security policy: Security - Yocto Project
A slide set about CVE monitoring (including Yocto): https://elinux.org/images/0/0a/Open-Source-CVE-Monitoring-and-Management-V3.pdf
Eclipse Foundation projects
Bug fixes are handled by each project, recommended to use Bugzilla.
Checking for CVEs
Found no process for automatic check of CVEs. It is up to the project to file for one.
Reporting CVEs to an Eclipse project
The private list to report undisclosed issues is email@example.com.
Issues may be also reported to Eclipse Foundation’s Bugzilla instance, where it must be tagged as commiter_only. In this case they are visible to all commiters.
Security issues are resolved by the project team, the Eclipse Security team provides assistance.
A discussion about the Eclipse CVE assignement process (February 2021)
Debian handles issues for its upstream projects, releasing Debian Security Advisories (DSA) if an important issue affects a Debian package.
Everyone can report a bug in Debian to the Debian bug tracker (BTS). If it is a security issue, the person should contact the security team instead at firstname.lastname@example.org. BTS should be used only if the issue if already public.
Checking for CVEs
Debian has a security tracker downloading automatically all new CVEs and reporting the current status on the security tracker website. The source code of the tracker is available from
git clone https://salsa.debian.org/security-tracker-team/security-tracker.git
The tracker includes data files. New CVE entries should be checked manually, to verify the CVE description, if the package is in Debian, if it has a vulnerable version, and check any errors there might be in the CVE description. They tag non-Debian packages as Not-For-Us (NFU). A set of scripts in the tracker parses the status and generates the website content.
If the issue exists in Debian, there should be a bug filled in BTS and the right package maintainers informed. They should prepare the big fix changing as little ABI as possible.
Security updates in Debian are handed by the security team directly.
Note: the NVD database might be updates much later (days, weeks…) after the CVE is released.