Zephyr Project

Previous software releases are available from https://www.zephyrproject.org/downloads. A plan for Long-Term-Support (LTS) support is in progress.

https://github.com/zephyrproject-rtos/zephyr/issues

All changes to software are submitted through the GitHub pull request process and logged and reviewed there: https://github.com/zephyrproject-rtos/zephyr/pulls. Git log tools can be used to generate detailed reports, as well as summaries on https://github.com/zephyrproject-rtos/zephyr/pulse for insights.

Security-related issue reporting is mentioned on https://www.zephyrproject.org/doc/introduction/introducing_zephyr.html and documented in https://www.zephyrproject.org/doc/security/security-overview.html

The project contribution guidelines include coding standards and tools for verifying: https://www.zephyrproject.org/doc/contribute/contribute_guidelines.html#coding-style

gitlint and checkpatch tools automatically verify and enforce coding standards, as documented in https://www.zephyrproject.org/doc/contribute/contribute_guidelines.html#coding-style

We're using CMake to generate binaries which does support the above and does honor environment variables.

The generated ELF has debugging information, however the binary installed to the final platform may not preserve this information.

Any cross dependencies will cause a rebuild of the dependent component.

Rebuilding binaries that have no variable data such as timestamps results in the same bit-for-bit output, this is verified by building a binary for a certain configuration multiple times and comparing check-sums of generated binaries and all other output.

The build system provides a common method for installing on all target platforms.

We install the compiled image in a platform-specific way (e.g., to flash)

We have getting started guides for Linux, Windows, and MacOS

Note: this is about installation of items that are needed to use and build zephyr, see requirement above.

External components are identified in the /ext area in GitHub: https://github.com/zephyrproject-rtos/zephyr/tree/master/ext but those are not "installed", they are part of the source. For external dependencies need to build and test the project we have scripts/requirements.txt (https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requirements.txt).

see https://github.com/zephyrproject-rtos/zephyr/issues/6533, one step of the release process is to verify for known vulnerabilities

External components are self-contained without any modifications or local changes, we maintain information about the source and origin of such components and track the used versions and SHAs in case of git repositories. Updating to a new component is in most cases a drop-in replacement of existing code. We will support external components in external repos. Additional, wherever we have local modifications, we maintain a fork of the original trees and keep the trees up-to-date with upstream. Local modification are submitted upstream where applicable, this is a policy of the project.

The project is self-contained and does use minimal external APIS, mostly from libc. We verify usage of those APIs on constant basis and remove any obsolete usage when found or reported.

Each commit/Pull Request requires passing a series of sanity checks, including building documentation, driven by the "shippable" tool: https://app.shippable.com/github/zephyrproject-rtos/zephyr/dashboard

Issues that are marked with regression label (https://github.com/zephyrproject-rtos/zephyr/labels/Regression) will be added to automated test-suite and integration tests that run through CI where applicable.

We use gcov/lcov to measure coverage of core features of the project. Due to the fact that Zephyr is an RTOS that can't be run with all features enabled on a host system, the coverage of some areas is not measured yet, the kernel however is being measured and has coverage of 80% in the supported configuration and where measurement is possible. Coverage reports can be found here: https://codecov.io/gh/zephyrproject-rtos/zephyr

Policy for adding new functionality and the requirements on tests can be seen here: https://github.com/zephyrproject-rtos/zephyr/blob/master/CONTRIBUTING.rst

https://github.com/zephyrproject-rtos/zephyr/blob/main/CONTRIBUTING.rst

Build system statically compiles and fails when met with warnings. CI also catch potential issues before being accepted into the code.

http://docs.zephyrproject.org/security/secure-coding.html

There are no default usages for weak crypto, SSH is not being used and is not supported.

Through the support of mbedTLS and tinyCrypt, users and developers have a variety of algorithms to choose from.

This is application specific and is out of scope for the project. Mechanism to support this requirement are provided in general terms. Application developer will have to follow best practices for their use-case.

We support TLS and DTLS for all communication protocols. HTTPS, COAPS and any other protocols can be abled with additional security enabled.

All configurations of the project use TLS 12 by default:

lib/crypto/mbedtls/configs/config-ccm-psk-tls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-coap.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-mini-dtls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-mini-tls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-threadnet.h:#define MBEDTLS_SSL_PROTO_TLS1_2

https://github.com/zephyrproject-rtos/zephyr/tree/master/ext/lib/crypto/mbedtls/configs

The project contains a sample application that is located at the primary repository located at: https://github.com/zephyrproject-rtos/zephyr The sample application implements a proper TLS secure connection and publishes data to the Google Cloud.

The project contains a sample application that is located at the primary repository located at: https://github.com/zephyrproject-rtos/zephyr The sample application implements a proper TLS secure connection and publishes data to the Google Cloud.

We don't do binary distributions and Git provides a secure release history.

Starting with release 1.12, the releases are now being signed by keys of recognized developers & maintainers.

The project does not have user interfaces that would allow user input by default, so this is out of scope. If those interfaces are added by the developer/user they need to follow our secure coding practices document in the project here: http://docs.zephyrproject.org/security/security.html

We do build by default with -Wformat -Wformat-security -Wno-format-zero-length and stack-protector is enabled as an option where supported. It is disabled by default for performance reasons but can be enabled by the user. The master CMake file contents show this to be the case:

https://github.com/zephyrproject-rtos/zephyr/blob/master/CMakeLists.txt

The project maintains documentation of current threat models, identification of assets, and trust boundaries. The documentation also provides coding and development guidelines intended to mitigate threats.

See: https://docs.zephyrproject.org/latest/security/secure-coding.html

Coverity (https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html) is used for static code analysis.

Software is not application-level.