Announced: LabVIEW 2026 Q3 will have SBOM Generation

[kdevelle]

ok thanks for the feedback. That will be important for us as basically we sell product with the application embedded meaning we should provide both SBOM.
In the meantime, how to get the initial sbom?

[Oli_Wachno]

---

@kdevelle wrote:

ok thanks for the feedback. That will be important for us as basically we sell product with the application embedded meaning we should provide both SBOM.
In the meantime, how to the initial sbom?

---

You don't have to provide a SBOM (CRA Annex I Part II), you have to have it available.

Oli_Wachno_0-1787724067334.png

After all, an SBOM is a list of dependencies. If push comes to shove, I can be created manually from the information in your LVPRJ (though this is nothing you really want to do).

[joerg.hampel]

---

@Oli_Wachno wrote:

---

---

You don't have to provide a SBOM (CRA Annex I Part II), you have to have it available.

Oli_Wachno_0-1787724067334.png

After all, an SBOM is a list of dependencies. If push comes to shove, I can be created manually from the information in your LVPRJ (though this is nothing you really want to do).

---

It's also worth highlighting that for CRA compliance, the SBOM must cover "at the very least the top-level dependencies" - good for us, as that leaves room for interpretation. We can surely argue that the top-level dependencies of our product are sufficiently defined via VIPs and NIPMs.

[alexderjuengere]

---

@Oli_Wachno wrote:

After all, an SBOM is a list of dependencies. If push comes to shove, I can be created manually from the information in your LVPRJ (though this is nothing you really want to do).

---

A comprehensive SBOM goes beyond a simple dependency list; it maps full software and hardware relationships and includes critical data such as cryptographic hashes and component licenses.

I recommend to perform this process manually for the first iteration before establishing automation.

[joerg.hampel]

---

@alexderjuengere wrote:
A comprehensive SBOM goes beyond a simple dependency list; it maps full software and hardware relationships and includes critical data such as cryptographic hashes and component licenses. I recommend to perform this process manually for the first iteration before establishing automation.

---

Reading between your lines, perhaps it makes sense to differentiate between an SBOM and the CycloneDX format?

• An SBOM is a Software Bill of Materials, it does not usually cover hardware as far as I know
• CycloneDX supports information on completeness (via the aggregate field), meaning an SBOM can technically be "incomplete" (and the CRA does not require completeness). Also, CycloneDX is broader than a traditional SBOM format and can contain hardware information, eg via the component -> type fields

[SumRunner]

The way to get any SBOM for any NI product is to send an email to security@ni.com. Tell us which software, which version you want. We'll walk you through the process from there. 

[SumRunner]

You can see from this thread that there are some very real questions around SBOMs. The CRA language (Cyber Resilience Act — Full Text of Regulation (EU) 2024/2847 · cyberresilienceact.eu) answers only some of the questions:

Annex I, Part II, (1)  identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.

Article 3 (39) ‘software bill of materials’ means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements;

Article 13 (24) The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials.

Article 13 (25) market surveillance authorities may request manufacturers of such categories of products with digital elements to provide the relevant software bills of materials

(77) Manufacturers should not be obliged to make the SBOM public.

All of that means, you must have an SBOM of the direct components (those you can control). You don't have to make it public, but you must be prepared to share with authorities if they request it. The commission is supposed to clarify what is in the SBOM. I have not been able to find any clarification so far. 

Cyclone DX allows for a lot of things beyond what is in the CRA requirements. NI is standardizing on Cyclone DX for our products. It's not clear that the CRA will require this format. 

We are trying to comply with these requirements, and help you comply, but it's difficult without more information from the commission. We maintain SBOMs for NI products, but we do not make them public. We understand that some companies (and some of your customers) demand that you have SBOMs of the dependencies of your components, so you can request these SBOMs by emailing security@ni.com. You can now generate LabVIEW SBOMs but only with direct dependencies. We are working to improve this right now. 

In many cases, you will need to add components manually to the SBOM. We are working to make this easier, with a tool that lets you enter information into a form that adds the information to the SBOM. We'll announce here when that is available.

The whole SBOM situation is frustrating and we are trying to navigate through it. Keep posting your thoughts, comments, and questions here - they are helpful for other readers. 

[MaximeR]

Hi,

I'm facing exactly the same issue than @ADAMMetcalf . The generated sbom file with LabVIEW 2026 create pURL with the  "purl": "pkg:vipm/ or "purl": "pkg:nipkg/. Scanner like trivy or Grype returns no Vulnerabilities because they don't know this type of URL.

Can you explain how to Scan easily generated sbom file within LabVIEW ?

Regards

[A-T-R]

It would be great if someone from NI and/or JKI would read through this thread:

https://forums.ni.com/t5/LabVIEW/SBOM-generation-in-2026-Q3-fails-due-to-VI-in-conditional/m-p/44846...