EU Cyber Resilience Act

As of today: (Sep 11th 2026) Cyber Resilience Act | Shaping Europe’s digital future

11 September 2026: Reporting Obligations Begin

  • Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs.
  • Timelines: 24-hour early warning, 72-hour detailed notice, and 14-day final report.
  • This applies to all products currently on the market, not just new models.

As an Open Source developer spending my free time and free will and is not compensated by BeagleBoard.org. (I also live in North Dakota, a non EU territory). Consider me under the “Software Exceptions” listed as:

Non-Commercial Open Source: Free-of-charge software developed outside of commercial activities.

As a free time developer I will not be physically able to meet any of those timelines, my free time is more important to me then ever, so don’t push me.

Raspberry Pi has a pretty good page and whitepaper up explaining how to deal with the pure “Debian” side of the packages here: https://www.raspberrypi.com/for-industry/cyber-resilience-act/

Going forward, i will continue to focus on what i love. Kernel/u-boot development, so feel free to use my kernel and u-boot as you see fit. However, I’ll be changing one of my main packaging helping, anything not in packaged in Debian, well “you” have to get it in Debian.

Debian has a really good tracker here: Security Bug Tracker

My images on https://rcn-ee.net will still exist, but I’ll start nuking some of the older “pre-debian-13” images as those have “known” Security bugs. The same with GitHub - RobertCNelson/omap-image-builder: omap image builder · GitHub anything pre-debian-13 will start getting purged and the “non-EU-CRA” code paths will be removed.

To the best of my knowledge (not a lawyer), over the last year I’ve tuned my image builder to meet EU CRA requirements for our downstream manufactures.

Regards,

Robert, you’re an absolute legend, and definitely one of the good guys.
Don’t lose any sleep over the EU CRA. Their intention is not to go after people like you.

I’m super impressed you’ve made efforts already to comply with this, especially while not even living in the EU. Hugely appreciated!

I don’t know if it was with regards to this specific piece of legislation, or something else I’ve forgotten about, but I believe Linus’s approach was “Lets just wait and see, and focus on developing tooling that can automatically help all open source projects achieve compliance”

Hello Robert,

On the other hand, do you know if BeagleBoard.org will release similar documents regarding CRA as Raspberry Pi did?

Remember i’m not a lawyer, so you have to be more specific, to what “Exactly” you need.

Regards,

sorry it took me some time to get familiar with the whitepaper itself. It contains information how Raspberry Pi is compliant with CRA in form of points and tables and what are the remediation methods for the customer

debsbom GitHub - siemens/debsbom: SBOM tooling for Debian-based distributions · GitHub

Install thru apt

I’ve added the backport of debsbom into our apt armhf/arm64/riscv64 repos for Debian 13 (trixie)..

sudo apt update
sudo apt-get install debsbom python3-spdx-tools

on a base install, it’s not exactly light:

voodoo@21-am335x-bbb:~$ sudo apt-get install debsbom
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

<snip>

0 upgraded, 179 newly installed, 0 to remove and 0 not upgraded.
Need to get 139 MB of archives.
After this operation, 531 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Install via pipx

sudo apt update
sudo apt-get install pipx

Add to path if never done…

pipx ensurepath
source ~/.bashrc

Install

pipx install debsbom[spdx]

Much smaller

voodoo@21-am335x-bbb:~$ du -sh ~/.local/share/pipx/venvs/debsbom/
26M	/home/voodoo/.local/share/pipx/venvs/debsbom/

Usage

debsbom generate

Okay finally got something exported, that i could import into one of those random online scanners…

So take this very basic: Index of /rootfs/debian-armhf-13-base-v6.18/2026-09-17

use this sbom.cdx.json and load up: https://rcn-ee.net/rootfs/debian-armhf-13-base-v6.18/2026-09-17/am335x-debian-13.7-base-v6.18-armhf-2026-09-17-4gb.sbom.cdx.json

Hey Robert, do you have any recommendations for the analyzer tool to search for the vulnerabilities? I tried to use self-hosted Dependency Track but didn’t have any luck. It consumed the SBOM but it didn’t find any vulnerabilities in any of the components

Good point… all the sbom checkers suck…

debsbom generate -t cdx -o /opt/source/sbom/debsbom.cdx.json
debsbom generate -t spdx -o /opt/source/sbom/debsbom.spdx.json
tar -czvf /opt/source/sbom.tar.gz -C /opt/source/sbom .

Lets dump both formats debsbom supports today..

So here’s another format.. using the same tool as RPI… syft… 52MB json file..

https://rcn-ee.net/rootfs/debian-armhf-13-base-v7.3/2026-09-18/am335x-debian-13.7-base-v7.3-armhf-2026-09-18-4gb.syft.spdx.json

I guess i better compress it..

config:

  metadata:
    selection: all
    digests:
      - sha256

output:
  - spdx-json

format:
  pretty: true

source:
  file:
    digests:
      - sha256

package:
  cataloger:
    scope:
      - squashed
syft scan -c "$SYFT_CONF" dir:"${tempdir}" > "${DIR}/deploy/${export_filename}/syft.spdx.json"

Regards,

Okay, compressed form:

and we need grype : Releases · anchore/grype · GitHub

Download

wget https://rcn-ee.net/rootfs/debian-armhf-13-base-v6.12/2026-09-18/am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json.xz
unzx am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json.xz

Run grype on file

grype am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json --file results.txt

Results:

$ grype am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json --file results.txt
 ✔ Scanned for vulnerabilities     [4866 vulnerability matches]  
   ├── by severity: 403 critical, 1636 high, 906 medium, 67 low, 983 negligible (2494 unknown)
   └── by status:   49 fixed, 6440 not-fixed, 1623 ignored 

(full results)
results.txt (862.3 KB)

This works better but it’s a massive file now:

grype am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json --output json | jq . > vuln_report.json

Just a ton of noise with linux-cpupower/libcpupower1… only reason we have it installed is for cpufreq tools..

cat .grype.yaml

ignore:
  - package:
      name: linux-cpupower

  - package:
      name: libcpupower1
grype am335x-debian-13.7-base-v6.12-armhf-2026-09-18-4gb.syft.spdx.json --output table > table.txt

table.txt (261.2 KB)

So good news, every package has a CVE. :wink:

Regards,

4866 matches and only 49 actually fixable is such noise, these sbom scanners flag the whole rootfs and call it a report lol

I need to dig more into it, as it seems to be scanning every linux module and creating a match, but it can’t figure out what kernel version to tie the cve to…

But yeah, right now most of the scanners are pretty useless, i’m just glad we can run grype locally to test sbom files..

Found this…

Regards,

Hey Robert, did you come with an idea how to match the kernel?

Right now the best option i’ve found:

grype 'cpe:2.3:o:linux:linux_kernel:6.18.52:*:*:*:*:*:*:*' --output table > 6.18.52.txt

6.18.52.txt (22.9 KB)

it’s looking at:

   "metadata": {
    "name": "3w_9xxx",
    "version": "2.26.02.014",
    "sourceVersion": "D0DE63C5B9EA5612D9A079B",
    "path": "/usr/lib/modules/6.18.52-arm64-k3-r56/kernel/drivers/scsi/3w-9xxx.ko.xz",
    "description": "3ware 9000 Storage Controller Linux Driver",
    "author": "LSI",
    "license": "GPL",
    "kernelVersion": "6.18.52-arm64-k3-r56",
    "versionMagic": "6.18.52-arm64-k3-r56 SMP preempt_rt mod_unload aarch64",
    "parameters": {
     "use_msi": {
      "description": "Use Message Signaled Interrupts.  Default: 0"
     }

we need to map 6.18.52-arm64-k3-r56 → 6.18.52

Side note… there are some templates:

Download one: grype/templates at main · anchore/grype · GitHub

grype beagleplay-debian-13.7-xfce-v6.18-k3-arm64-2026-09-20-12gb.syft.spdx.json -o template --template html.tmpl --file grype_report.html

rc’s can be done with:

grype 'cpe:2.3:o:linux:linux_kernel:7.3:rc6:*:*:*:*:*:*'