Written by Kate Stewart, Senior Director of Strategic Programs at the Linux Foundation
“Device makers, especially consumer-focused ones, have been the Achilles’ heel of IoT security. These vendors have often viewed proper security implementations as extra cost, complexity, and time-to-market burdens with an unclear payoff.” – Maciej Kranz *
“New security loopholes are constantly popping up because of wireless networking. The cat-and-mouse game between hackers and system administrators is still in full swing.” — Kevin Mitnick **
When the Zephyr project launched in February of 2016, the security committee was one of the first working groups formed. We wanted Zephyr to be used in IoT products, and knew that we were not always going to be able to anticipate all the vulnerabilities that would be discovered over time in such a dynamic environment for each release, let alone after a release was out. To help Zephyr become a trusted RTOS to use in products, the security committee has been actively looking for best practices so we can be a responsible upstream for product makers to depend on.
One of the early inspirations for the projects came for the Linux Foundation’s (LF) Core Infrastructure Initiative (CII) Best Practices badging program. This program focused on identification of best practices for open source software (OSS) projects to follow for production of Open Source Software; was based on practices observed in a well-run OSS projects; would increase the likelihood of better quality & security, and the criteria was designed so that any OSS project could qualify. Challenge accepted! Zephyr’s security committee worked towards the identified goals, and achieved passing status and then silver status, and then the very rare gold status over the last few years.
One of the widespread accepted ways of communicating vulnerability information about products is through use of Common Vulnerability and Exposure (CVE) numbers, in the U.S. National Vulnerability Database (NVD). Since the Zephyr Project is under a neutral governance, it didn’t make sense to rely on any specific company to triage potential vulnerabilities. The security team decided that it would be best for the Zephyr Project to become a CVE Numbering Authority (CNA), and directly manage vulnerabilities that were detected and reported to the project directly rather than relying on member company security incident response teams (PSIRTs). To further this goal, the project applied to become a CNA in 2017, and has been one ever since.
Last year, we released the first Zephyr Long Term Support 14.0. With this release, the project committed to do backports of significant bug and security fixes for the next two years in this code base, together with the main development branch, and latest release. Since then, community members have reached out with issues they’ve found. We are very appreciative of their efforts to help us improve Zephyr! When appropriate, the Zephyr project has issued CVEs to track these vulnerabilities, and ensured that they are documented in the release notes. With the recent LTS release of Zephyr 1.14.2 last week, there were some CVE numbers referenced that were still under embargo at that point. Once the embargo period ends, the release information will be updated to provide further details, as will the associated records with those CVE numbers in the NVD.
In 2018, we started seeing evidence of products based on Zephyr appearing in the marketplace including:
As we move into 2020, we are hearing (through word of mouth) and the community about new products every day. While we are able to share embargo information with our project members who are part of the security team, we have lacked the ability to reach out to the product makers and let them know when a vulnerability had been fixed. As a sign of the commitment of the Zephyr project to product makers, we created a form where product makers, who are not currently members of the Zephyr project, can also request to get notifications of vulnerabilities that may impact their products during the embargo window. To be eligible to receive vulnerability notification during the embargo window, a product maker must have a publicly available product based on Zephyr that is posted on their web site and provide valid contact information. Zephyr project member who participate in the security committee receive this information already.
To learn more about the Zephyr security program for product makers see:
To understand more about how the Zephyr security team handles vulnerabilities see:
https://docs.zephyrproject.org/latest/security/security-overview.html
If you’re a product maker who meets the criteria and would like to apply to be notified of vulnerabilities during the embargo period, please fill out the form at: