diff mbox series

security-manual: Add information about how security is handled in builds

Message ID 20260807164325.4083331-1-richard.purdie@linuxfoundation.org
State New
Headers show
Series security-manual: Add information about how security is handled in builds | expand

Commit Message

Richard Purdie Aug. 7, 2026, 4:43 p.m. UTC 
We have no information about how security is handled within the builds
themselves. Start to document this.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../security-manual/build-security.rst        | 41 +++++++++++++++++++
 documentation/security-manual/index.rst       |  1 +
 2 files changed, 42 insertions(+)
 create mode 100644 documentation/security-manual/build-security.rst
diff mbox series

Patch

diff --git a/documentation/security-manual/build-security.rst b/documentation/security-manual/build-security.rst
new file mode 100644
index 000000000..5f15d5f64
--- /dev/null
+++ b/documentation/security-manual/build-security.rst
@@ -0,0 +1,41 @@ 
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+**************
+Build Security
+**************
+
+OpenEmbedded is used to run the builds and careful consideration has gone into
+how it does this with the aim of being both secure and reproducible. Like any
+system, it does need to be used carefully and in keeping with the design for
+that to be true. Users of the system should consider that:
+
+-  The builds generally aim for any input into the build process being verified in
+   some form. For source code tarballs, these would have a checksum. Git source
+   trees would have a specific git revision. Metadata would also usually be
+   under source control and also have revisions.
+
+-  Some elements that can influence the build are not verified. It is assumed
+   that the operating system running the system is secure and of a known setup and
+   version. The system goes to signififant lengths to isolate against host
+   contamination of the output but it is certainly possible, especially malicously.
+
+-  The builds assume DL_DIR is a safe location. Once things enter that location
+   there are not repeatedly re-verified. A user could edit the git trees or
+   tarballs there in ways the build might not detect.
+
+-  The builds assume things from SSTATE_DIR or from a configured sstate mirror
+   are safe (with signature checks if configured).
+
+-  The core build tool, BitBake is a execution engine and will execute code both
+   during builds and when parsing recipes. This is not a security issue, it is an
+   essential part of it's function and purpose.
+
+-  OE-Core is well tested for reproducibility issues but other layers and their
+   recipes and code may not be as well tested. Those reproducilbity tests are
+   available for others to run against their own layers and code.
+
+-  The builds combine many different software components and we take it on trust
+   that there aren't issues in those code bases. We'd recommend build environments
+   being setup in such a way that if such an issue were ever discovered, which at
+   some point could happen, the build environments themselves could be simply
+   destroyed and rebuilt cleanly, i.e. they're disposable.
diff --git a/documentation/security-manual/index.rst b/documentation/security-manual/index.rst
index a767cd9c6..328265be2 100644
--- a/documentation/security-manual/index.rst
+++ b/documentation/security-manual/index.rst
@@ -11,6 +11,7 @@  Yocto Project Security Manual
    :numbered:
 
    intro
+   build-security
    securing-images
    vulnerabilities
    read-only-rootfs