From 3be25ab4863393754919e0b25cbd68eea1626092 Mon Sep 17 00:00:00 2001 From: Edwin Joassart Date: Fri, 11 Jul 2025 15:21:41 +0200 Subject: [PATCH 1/5] minor: add sbom and vex on security page https://balena.fibery.io/Work/Project/balenaos-SBOM-as-release-asset-1515 --- pages/learn/welcome/security.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/pages/learn/welcome/security.md b/pages/learn/welcome/security.md index ce7b531898..2d57749fd7 100644 --- a/pages/learn/welcome/security.md +++ b/pages/learn/welcome/security.md @@ -96,6 +96,18 @@ Devices contain metadata that identifies the device, fleet, and state of deploye Currently, metadata such as device identifiers or WiFi credentials are not encrypted on disk by default. This is because most commercially available devices do not support any form of hardware-level encryption, meaning that the decryption keys for this data would have to be stored in an accessible area of the device. Storing the keys with the encrypted data means that it is trivial for anyone with physical access to the device to decrypt the data at any point, rendering the encryption itself moot. If you do have a device that is capable of hardware-level encryption, please contact us to discuss your options. +## BalenaOS Software Bill of Materials (SBOM) and Vulnerability EXchange (VEX) files + +BalenaOS provides Software Bill of Materials (SBOM) in the - machine readable, but human friendly - CycloneDX 1.4 json format. Those files can be used to determine the versions of the all the components that composes the OS, and the known fixed vulnerabilities. + +As we apply patches to fix vulnerabilities, comparing the version of a component to popular vulnerability databases such as the NVD is not enough. That's why we also release `vex` files along the sbom. Each vex file is related to a specific sbom and **will list known vulnerabilities (CVE) that don't impact the release**, with an explanation when possible (i.e. the vulnerable code path is not accessible, the vulnerability has been patched, ...). Beware that this is **not an exhaustive list of known vulnerabilities** for the component. The vex file should only be used to filter down the list of vulnerabilities reported by sbom vulnerability scanner. + +A device release might contain multiple assets (the OS itself, a flasher image, the initramfs, ...), each will have their own `bom.json` and `vex.json`. + +`bom.json` and `vex.json` files can be found in the asset list of an OS release page (under the `cyclonedx` folder); click the `HOST OS VERSION` of a device to go to that page). + +SBOM and VEX are compatible with the cyclonedx ecosystem of software composition analysis, a list of tools (open-source and proprietary) can be found on [cyclonedx.org tool center](https://cyclonedx.org/tool-center/). + ## Building images The first step in deploying to a fleet of devices is to build a Docker image that contains everything necessary to run your application. While these images can be built locally, {{ $names.company.lower }} provides a powerful image builder that is more appropriate for most use cases. The builder for x86 images is hosted on AWS, while the builder for ARM images is hosted by a combination of AWS and Hetzner. From 3039c2ce0a1397c6ff4876c2cdaa20901c7e4fe2 Mon Sep 17 00:00:00 2001 From: Edwin Joassart Date: Fri, 11 Jul 2025 17:00:51 +0200 Subject: [PATCH 2/5] Update security.md Co-authored-by: Matthew Yarmolinsky --- pages/learn/welcome/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/learn/welcome/security.md b/pages/learn/welcome/security.md index 2d57749fd7..375f18897a 100644 --- a/pages/learn/welcome/security.md +++ b/pages/learn/welcome/security.md @@ -106,7 +106,7 @@ A device release might contain multiple assets (the OS itself, a flasher image, `bom.json` and `vex.json` files can be found in the asset list of an OS release page (under the `cyclonedx` folder); click the `HOST OS VERSION` of a device to go to that page). -SBOM and VEX are compatible with the cyclonedx ecosystem of software composition analysis, a list of tools (open-source and proprietary) can be found on [cyclonedx.org tool center](https://cyclonedx.org/tool-center/). +SBOM and VEX are compatible with the cyclonedx ecosystem of software composition analysis. A list of tools (open-source and proprietary) can be found on [cyclonedx.org tool center](https://cyclonedx.org/tool-center/). ## Building images From 8254f0e962d90239882c446f49a6b8f54577e8f2 Mon Sep 17 00:00:00 2001 From: Edwin Joassart Date: Fri, 11 Jul 2025 17:01:00 +0200 Subject: [PATCH 3/5] Update security.md Co-authored-by: Matthew Yarmolinsky --- pages/learn/welcome/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/learn/welcome/security.md b/pages/learn/welcome/security.md index 375f18897a..89595690a7 100644 --- a/pages/learn/welcome/security.md +++ b/pages/learn/welcome/security.md @@ -100,7 +100,7 @@ Currently, metadata such as device identifiers or WiFi credentials are not encry BalenaOS provides Software Bill of Materials (SBOM) in the - machine readable, but human friendly - CycloneDX 1.4 json format. Those files can be used to determine the versions of the all the components that composes the OS, and the known fixed vulnerabilities. -As we apply patches to fix vulnerabilities, comparing the version of a component to popular vulnerability databases such as the NVD is not enough. That's why we also release `vex` files along the sbom. Each vex file is related to a specific sbom and **will list known vulnerabilities (CVE) that don't impact the release**, with an explanation when possible (i.e. the vulnerable code path is not accessible, the vulnerability has been patched, ...). Beware that this is **not an exhaustive list of known vulnerabilities** for the component. The vex file should only be used to filter down the list of vulnerabilities reported by sbom vulnerability scanner. +As we apply patches to fix vulnerabilities, comparing the version of a component to popular vulnerability databases such as the NVD is not enough. That's why we also release `vex` files along with the SBOM. Each vex file is related to a specific SBOM and **will list known vulnerabilities (CVE) that don't impact the release**, with an explanation when possible (i.e. the vulnerable code path is not accessible, the vulnerability has been patched, ...). Beware that this is **not an exhaustive list of known vulnerabilities** for the component. The vex file should only be used to filter down the list of vulnerabilities reported by SBOM vulnerability scanner. A device release might contain multiple assets (the OS itself, a flasher image, the initramfs, ...), each will have their own `bom.json` and `vex.json`. From 64141337306c1270dbf54ed6ae8b245c0bf806ef Mon Sep 17 00:00:00 2001 From: Edwin Joassart Date: Fri, 11 Jul 2025 17:01:05 +0200 Subject: [PATCH 4/5] Update security.md Co-authored-by: Matthew Yarmolinsky --- pages/learn/welcome/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/learn/welcome/security.md b/pages/learn/welcome/security.md index 89595690a7..7a2dc829ce 100644 --- a/pages/learn/welcome/security.md +++ b/pages/learn/welcome/security.md @@ -98,7 +98,7 @@ Currently, metadata such as device identifiers or WiFi credentials are not encry ## BalenaOS Software Bill of Materials (SBOM) and Vulnerability EXchange (VEX) files -BalenaOS provides Software Bill of Materials (SBOM) in the - machine readable, but human friendly - CycloneDX 1.4 json format. Those files can be used to determine the versions of the all the components that composes the OS, and the known fixed vulnerabilities. +BalenaOS provides Software Bill of Materials (SBOM) in the - machine readable, but human friendly - CycloneDX 1.4 json format. Those files can be used to determine the versions of all the components that compose the OS, and the known fixed vulnerabilities. As we apply patches to fix vulnerabilities, comparing the version of a component to popular vulnerability databases such as the NVD is not enough. That's why we also release `vex` files along with the SBOM. Each vex file is related to a specific SBOM and **will list known vulnerabilities (CVE) that don't impact the release**, with an explanation when possible (i.e. the vulnerable code path is not accessible, the vulnerability has been patched, ...). Beware that this is **not an exhaustive list of known vulnerabilities** for the component. The vex file should only be used to filter down the list of vulnerabilities reported by SBOM vulnerability scanner. From d752d60658bc2c3e0bfa6ffa3227cd854345fe65 Mon Sep 17 00:00:00 2001 From: Edwin Joassart Date: Mon, 14 Jul 2025 15:57:38 +0200 Subject: [PATCH 5/5] Update security.md --- pages/learn/welcome/security.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/pages/learn/welcome/security.md b/pages/learn/welcome/security.md index 7a2dc829ce..d848938bb7 100644 --- a/pages/learn/welcome/security.md +++ b/pages/learn/welcome/security.md @@ -108,6 +108,8 @@ A device release might contain multiple assets (the OS itself, a flasher image, SBOM and VEX are compatible with the cyclonedx ecosystem of software composition analysis. A list of tools (open-source and proprietary) can be found on [cyclonedx.org tool center](https://cyclonedx.org/tool-center/). +Note that availbility of sbom and vex depends on device type and version, if you can't find them for a release you care about, please contact our support. + ## Building images The first step in deploying to a fleet of devices is to build a Docker image that contains everything necessary to run your application. While these images can be built locally, {{ $names.company.lower }} provides a powerful image builder that is more appropriate for most use cases. The builder for x86 images is hosted on AWS, while the builder for ARM images is hosted by a combination of AWS and Hetzner.