(WIP) Security team and private reporting

Note: this page is undergoing migration to the official Yocto Project documentation.

How to Report a Potential Vulnerability?

If you would like to report a public issue (for example, one with a released CVE number), please report it using the Security Bugzilla.

If you are dealing with a not-yet-released or urgent issue, please send a message to security AT yoctoproject DOT org, including as many details as possible: the layer or software module affected, the recipe and its version, and any example code, if available.

Branches maintained with security fixes

See Stable release and LTSfor detailed info regarding the policies and maintenance of Stable branch.

The Release page contains a list of all releases of the Yocto Project. Versions in grey are no longer actively maintained with security patches, but well-tested patches may still be accepted for them for significant issues.

How to Contact the Yocto Project regarding Security

We have set up two security-related mailing lists:

Public List

yocto [dash] security [at] yoctoproject[dot] org

This is a public mailing list for anyone to subscribe to. This list is an open list to discuss public security issues/patches and security-related initiatives. For more information, including subscription information, please see the yocto-security mailing list info page.

Private List

security [at] yoctoproject [dot] org

This is a private mailing list for reporting non-published potential vulnerabilities. The list is monitored by the Yocto Project Security team.

What you should do if you find a security vulnerability

If you find a security flaw; a crash, an information leakage, or anything that can have a security impact if exploited in any Open Source software built or used by the Yocto Project, please report this to the Yocto Project Security Team. If you prefer to contact the upstream project directly, please send a copy to the security team at the Yocto Project as well. If you believe this is highly sensitive information, please report the vulnerability in a secure way, i.e. encrypt the email and send it to the private list. This ensures that the exploit is not leaked and exploited before a response/fix has been generated.

What Yocto Security Team does when it receives a security vulnerability

The YP Security Team team performs a quick analysis and would usually report the flaw to the upstream project. Normally the upstream project analyzes the problem. If they deem it a real security problem in their software, they develop and release a fix following their own security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it.

The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are normally non-public.

When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published.

If an upstream project does not respond quickly

If an upstream project does not fix the problem in a reasonable time, the Yocto's Security Team will contact other interested parties (usually other distributions) in the community and together try to solve the vulnerability as quickly as possible.

The Yocto Project Security team adheres to the 90 days disclosure policy by default. An increase of the embargo time is possible when necessary.

Security Team Appointment

The Yocto Project Security Team consists of at least three members. When new members are needed, the YP TSC asks for nominations by public channels including a nomination deadline. Self-nominations are possible. When the limit time is reached, the YP TSC posts the list of candidates for the comments of project participants and developers. Comments may be sent publicly or privately to the YP and OE TSCs. The candidates are approved by both YP TSC and OE TSC and the final list of the team members is announced publicly. The aim is to have people representing technical leadership, security knowledge and infrastructure present with enough people to provide backup/coverage but keep the notification list small enough to minimise information risk and maintain trust.

YP Security Team members may resign at any time.

Security Team Operations

The work of the Security Team might require high confidentiality. Team members are individuals selected by merit and do not represent the companies they work for. They do not share information about confidential issues outside of the team and do not hint about ongoing embargoes.

Team members can bring in domain experts as needed. Those people should be added to individual issues only and adhere to the same standards as the YP Security Team.

The YP security team organizes its meetings and communication as needed.

When the YP Security team receives a report about a potential security vulnerability, they quickly analyze and notify the reporter of the result. They might also request more information.

If the issue is confirmed and affects the code maintained by the YP, they confidentially notify maintainers of that code and work with them to prepare a fix.

If the issue is confirmed and affects an upstream project, the YP security team notifies the project. Usually, the upstream project analyzes the problem again. If they deem it a real security problem in their software, they develop and release a fix following their security policy. They may want to include the original reporter in the loop. There is also sometimes some coordination for handling patches, backporting patches etc, or just understanding the problem or what caused it.

The security policy of the upstream project might include a notification to Linux distributions or other important downstream projects in advance to discuss coordinated disclosure. These mailing lists are generally non-public. The YP Security Team participates in the discussion as needed. They might also include the YP maintainer of the affected package.

When the upstream project releases a version with the fix, they are responsible for contacting Mitre (cve.mitre.org) to get a CVE number assigned and the CVE record published.

When the fix is publicly available, the YP security team member or the package maintainer sends patches against the YP code base, following usual procedures, including public code review.

Handling multi-project embargoes

In rare cases, a severe security issue affects multiple projects. This might be numerous projects having a similar issue because of design, coding pattern, or reuse of the same code (an example of this situation is CVE-2023-44487 where multiple web servers share a design weakness). It might also be a high-profile issue in a commonly used library (like OpenSSL). In such cases, the project, learning first about the issue, might decide to notify other affected projects confidentially so that they come up with a synchronized fix. It might also be the affected project informing major distributions to roll out the update simultaneously.

Such notifications happen over confidential, non-public means. Typically, the project initiating this "embargo" directly notifies a selected number of people from each project, including a subset of the security team. When Yocto Project is a part of such a notified group, developers prepare fixes on separate infrastructure and test it. They might also include additional developers and domain experts who can help with the fix and eventual regressions. When the embargo is lifted, they send a patch to the relevant public list, and the usual review process starts.

Current Security Team Members

For secure communications, please send your messages encrypted using the GPG keys. Remember message headers are not encrypted so do not include sensitive information in the subject line.