CVE database for L5 (and other Purism devices)?

@skyvine mentioned something in Driver updates on librem 5 - #5 by skyvine that stirred a thought, which kinda nags me as I briefly noted this a few years back when looking at alternative modems:

CVE (Common Vulnerabilities and Exposures) notifications specific to L5 (or any devices - in this case - Purism’s) are not listed, at least easily (as is with most devices, especially by small operators which are often on linux). This is not good in general but certainly something that should be part of a secure platform (hardware, OS and other software).

It’s not a straight forward thing to do, but not impossible either. A device has many components, which sometime hide inside them other components and sub-components and so on. So, CVEs are not always directly linked to a specific device. The hardware and software bill of materials (BOM) - which is becoming a reguirement for most things. A decent rundown on EU CRA with comparisons to US: Organizations will need to have vulnerability and incident reporting in place by Sept. 11, 2026, while other requirements (such as those related to SBOMs) will take effect on December 11, 2027. This is going to cause some work and it should be done already regardless of the CRA. I hope it’s implemented for all devices, since it would boost confidence in security and help everyone, even beyond EU (although there are caveats, like the amount of work it requires).

Something to know about CVEs and vulnerabilities is, that the CVE metrics that sometimes get posted are one thing - they are a way to help create a prioritizing, as there are vulnerabilities ranging from insignificant to catastrophic, but they are not perfect - sometimes even misleading (although newer version of metric have gotten maybe a bit better).

The CVE databases (for instance: cve.org, cvedetails.com, vulndb.com etc.) list a lot of CVEs but the devil is in the details. For instance Debian has about 7600 CVEs directly and not all are even assigned in their tracker, Ubuntu has about 42000 across all releases, of which 0 (atm) are critical and still considered a vulnerability. Of course these only list the known ones (“zero days” are not known). The linux kernel CVE list may seem scarily long too. Most (non critical) vulnerabilities need special circumstances or scenario to be an immediate thereat - often you need a few of these to line up for an attack anyway, so the chances decrease a bit. Unfortunately, it is shown and known that old vulnerabilities do not seem to disappear completely, even though patches may be created - they are not always applied. Projects are not always well maintained and patching not automatic (patches may even brake stuff).

Anyways, the inconvenient though is that there should be at least a CVE tracker page for L5+PureOS components, which users could then use to determine if they can consider the device safe enough and if they (in their usecase and with their specific risk profile) can mitigate, remove or prevent the threats. Purism did have a couple of random blog posts about a few CVEs back in the day, which were informative in the sense that we knew some of the loudly talked about vulnerabilities were not a threat, but mostly they were for marketing purposes - not from s strict security and patching process. For that, a good hardware and software BOM is needed to create database searches that would list the relevant CVEs. As far as I know, that does not exist at the moment.

[Edit to add and emphasize: SBOM and CVE databases may help users but their main benefit is for the provider to keep devices secure by having an automated and systematic process that helps prioritize most dangerous vulnerabilities to fix with limited development resources - the platforms/tools seem to mostly connect to development pipelines]

There are a fewhow-toarticles and projects and such related things on this, but has anyone any examples, experience of doing something like this?

8 Likes

Perhaps this list could just be links to the relevant CVEs for recommended/supported operating systems (including PureOS), CPUs, WiFi modules, modems.

For example, since I’m running Qubes OS on my laptops, I don’t care about PureOS CVEs on it. Qubes has its own page for that with much fewer vulnerabilites.

1 Like

A proper database page would have filters to sort through the various CVEs from many angles, not just a list. Not all CVEs are equal and their status changes.

3 Likes

Taking this as a comment on virtualisation generally, it shows how complex this topic can get. For any given CVE that does actually apply to operating system X, it may apply differently or not at all depending on whether X is the outer os or the inner os.

However since the primary focus at least started out as “Librem 5” maybe we can consider virtualisation complexities as less important.


As a small starting point, apt changelog zzz works on my desktop (not running PureOS) but I think does not work on the Librem 5. If that’s correct then why?

By way of example, from yesterday

apt changelog openssh-server
openssh (1:9.6p1-3ubuntu13.8) noble-security; urgency=medium

  * SECURITY UPDATE: MitM with VerifyHostKeyDNS option
    - debian/patches/CVE-2025-26465.patch: fix error code handling in
      krl.c, ssh-agent.c, ssh-sk-client.c, sshconnect2.c, sshsig.c.
    - CVE-2025-26465
  * SECURITY UPDATE: pre-authentication denial of service
    - debian/patches/CVE-2025-26466.patch: don't reply to PING in preauth
      or in KEX in packet.c.
    - CVE-2025-26466
:
:

So there’s two CVEs right there. Has this come through for the Librem 5? Yes, I think it has but it would be more difficult to verify.

Where is that changelog coming from? If it’s upstream then why doesn’t it appear on the Librem 5?

If we could make it appear on the Librem 5 then maybe a bit of pattern matching (on Purism’s side) could make the CVE appear in a database automatically.

NB: That only works in a positive way (this has been patched), not in a negative way (this has not yet been patched) but even that allows the Librem 5 owner to go off and consider mitigation in the absence of a patch if the owner is already aware of the CVE.

With such a database, I guess Purism could add another mailing list for those who actually want to subscribe to a CVE feed.

4 Likes

It seems there are separate standards for doing CVEs and SBOMs, so using changelog and creating some search for that may not be needed. For instance:

And this seems a good view of the SBOM ecosystems: SBOM Landscape

It seems they cover much more than just security issues, and it should be noted an SBOM is just a step towards identifying which CVEs might be related to L5, as I assume not all patches have a mention that they may be related to one. A specific platform made for this probably has these covered - but has anyone ever used one, or even better, set one up?

3 Likes

A post was split to a new topic: CVE database tangent

Let’s have the discussions about various CVEs and threats in their own thread(s).

2 Likes

Well, CVEs are provided in JSON format, so ideally we could just pull data from their to identify relevant vulnerabilities.

Unfortunately I’m not sure if there’s an efficient way to do this due to non-standardized language to refer to impacted components. For example, the Librem 5’s CPU is the NXP® i.MX 8M Quad core Cortex A53 which is presumably impacted by CVE-2022-45163. But the only way to tell that it is impacted is the “description” field which IIUC is freeform text provided by the researcher. I don’t see any standardized product identification fields. So we can’t just grep for a specific string every time the repository is updated, we would have to manually review each incoming CVE to check if it’s impacted.

We also need to make sure that all of the hardware vendors participate in the CVE process. The WiFi module used by the Librem 5 is produced by SparkLan and I don’t see any mention of this company in the CVE repository, which does not inspire confidence.

2 Likes

CVEs are notifications, not the whole report. For the one you linked, see: https://www.nccgroup.com/us/research-blog/technical-advisory-nxp-imx-sdp_read_disable-fuse-bypass-cve-2022-45163/

I agree, CVEs don’t seem to be fully standard, but even as they are, they are something. The receiving end, relevent representatives, devices devs, communty and customers need to decipher the details regarding relevancy. Apparently on the BOM side there is more standardization (even ISO something if I saw correctly) and the platforms surely have them automated - up to a a point, alt least.

1 Like