LabVIEW CycloneDX SBOM Toolkit

[Cannon_Controls]

What I have there isn’t too much of a spin off. It’s mostly a GUI for Sam’s toolkit (he did all of the heavy lifting there). I did change some of the openG functions as I was having issues as well but that was pretty minuscule. All kudos still go to Sam there.

[Mads]

FYI:

Working on generalizing the SBOM metadata bit (Generate CPE based on inputs from the projecty or user etc) I noticed that the original code gets its metadata section highlighted as erroneous by the some tools. I have fixed this in the generalized version I am working on, but is this something others have seen as well?:

Here is a comment from a parser:

The header (specifically the metadata section) of this CycloneDX 1.5 SBOM is malformed.

The issue is here:

"metadata": {
  "timestamp": "2026-04-23T08:58:37.184Z",
  "manufacture": { "name": "RAM AS&D" },
  "supplier": { "name": "RAM AS&D" },
  "component": {
    "type": "application",
    "name": "softwarename",
    "metadata": {                  // ← This is invalid
      "component": {
        "supplier": { "name": "RAM AS&D" },
        "author": { "name": "RAM AS&D" },
        "version": "4.0.9",
        "description": "Softwarename",
        "cpe": "cpe:2.3:a:ramasd:softwarename:1.2.219:*:*:*:*:*:*:*"
      }
    }
  }
}

In CycloneDX (including version 1.5), the top-level metadata.component is meant to directly describe the main/root component that the entire BOM is about. It should be a standard Component object.You cannot nest another "metadata": { "component": { ... } } inside it. That structure does not exist in the schema.

[Bas.v.E]

Great initiative! I was also thinking about creating a small .net aplication to quickly scan a vipc and just check the installed dependencies via nipm and I want to make sure that the purl you've added is also used by the SBOM generation tool that NI is releasing in 2026 Q3 otherwise we could have mismatches when checking for vulnerabilities

[SumRunner]

I just posted an announcement that SBOM generation is coming to LabVIEW 2026 Q3 - Announced: LabVIEW 2026 Q3 will have SBOM Generation - NI Community. Just wanted you to consider this as you spend time on this initiative in this post. 

[Bas.v.E]

I knew that already, but this doesnt provide a solution for our projects that run in lv 2020 until this version

[SumRunner]

Great point. You would have to open the project in 2026 Q3 to generate the SBOM for earlier versions. Having a separate tool could be really handy for that use case. 

I love the initiative to create this - I just didn't want to surprise anyone when we announce this being in LabVIEW later this year. 

[Bas.v.E]

The biggest issue with this is, when using like IMAQ or something or the RIO drivers, you want the have the drivers that match your labview version, if you try to create your SBOM with the latest and greatest version, you'll be missing the CVE that occur in those older versions

[Oli_Wachno]

Talking old LabVIEW versions (CRA related)....

I don't think it is possible to have a valid CE mark for a software which has been built using an obsolete version.

While having an SBOM makes sense definitely!

[Bas.v.E]

The lifecycle policies of LabVIEW is 5 years support with security updates, this means that we can use 5 year old LabVIEW and still be CRA compliant. 
https://www.ni.com/en/support/software-product-life-cycle-policies.html

[SumRunner]

There are a number of CRA requirements. The first NI software versions that will be fully compliant with zero defects, secure by default installation, documentation, etc. will be in 2027, including for LabVIEW. Our teams are working to get these done early in 2027, but we aren't ready to commit to a specific date at this time. 

This belongs in a different thread, but with AI coming online as a threat detection tool, all software vendors are finding hundreds or thousands of vulnerabilities even in software that was previously considered to be free of defects. That means that between now and next year, there will be a huge wave of software updates, including to the software components that we use in NI software. CRA requires that there are zero known vulnerabilities, this is different from our commitment to provide 5-year support lifecycle to address high impact security issues. 

I would plan to update in 2027 to be fully CRA compliant. I would plan on seeing many patches from all vendors in 2027.