CVE Processes of Open Source Projects

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

Checking for CVEs
Yocto provides cve-check.bbclass that allows checking for the CVEs in the NVD

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):

Eclipse Foundation projects

Bug reporting
Bug fixes are handled by each project, recommended to use Bugzilla.

Projects do have different policies:
Mosquitto is asking for direct reporting to Eclipse Bugzilla/Eclipse security team.
Jetty has a proper address for security issues.

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

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.

Commiters from the project need to apply for CVE numbers handled by the Eclipse foundation. There is a strong preferences for asking for a CVE just before making the issue public.

Security issues are resolved by the project team, the Eclipse Security team provides assistance.

Vulnerability policy
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.

Bug reporting
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 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

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.

Debian security team manual
secuity bug tracker for issues from upstream

Note: the NVD database might be updates much later (days, weeks…) after the CVE is released.

1 Like

Our vulnerability process and bug policy have been approved. You can access a FAQ.