Test System Security
SBOM Analyzer doesn't know "purl": "pkg:nipkg/..." or "purl": "pkg:vipm/..."
Hello,
I did some tests with LabVIEW 2026 Q3 to generate SBOM automaticaly. Generated SBOM give a list of NI Package and VIPM packages. Everything seems good. But after generating a SBOM file, the interest is to be able to check if there are some vulnerabilities.
I tried with with Trivy, and when using Debug, we discover that it didin't check the packages in reality.
With Grype, it's the same. The tool don't know how to check these purl.
I'm newby on that subject like certainly many developpers. I love labVIEW, because, i don't think about a lot of things compare to other langages like this kind of things, and I was hopping that the SBOM generator will help me more easily for CRA. It's seems that we are missing something.
Like other LV developpers on the forum, my understanding is that SBOM is only the first step. This file allow to use tool to analyze it and check if the components used are concerned by vulnerabilities. If at the end, the analyzer tools, more for NI Packages than VIPM packages, return 0 vulnerabilities because it's not checked, it's not good.
We often have to conviced internally to keep some customer tools based on LabVIEW. If we don't have the rights tools to show that we are OK against vulnerabilities, it will be very difficult for us to maintain customer application based on LabVIEW.
Please, explain me how to analyze easily my sbom file.
Best regards
Maxime,
similar discussion last week at the GDevCon.
No offence to JKI, but the pricing option, they are offering today is not attractive (euphemism) to small businesses.
Most of us would be happy to pay a reasonable fee for a flexible subscription.
Since most of us need it, there will be a community / open source solution hopefully soon!
To state it clearly: I see no obligation to NI to provide an SBOM Analyzer though. All the analyzers (I know) are third party tools.
The Cyber Resilience Act (CRA) is making SBOMs a necessity rather than an optional feature. As a global company, NI faces the same challenge as many vendors: enabling customers to generate and analyze SBOMs efficiently.
It is therefore surprising that a key SBOM solution for LabVIEW comes not from NI, but from a partner, JKI. While JKI is fully justified in monetizing the significant investment behind its work, the resulting cost is difficult to ignore, especially when equivalent capabilities for competing ecosystems are often available at little or no cost.
Given the price of NI software, customers could reasonably expect such a fundamental compliance and security capability to be included as part of the LabVIEW ecosystem. In that regard, this feels like a missed opportunity for NI. One would hope that an arrangement could have been found whereby JKI was fairly compensated while NI delivered the functionality under its own banner.
The issue is amplified by the nature of LabVIEW itself. Unlike many programming languages, LabVIEW remains a largely closed ecosystem where meaningful code analysis requires platform-specific knowledge and tooling. That reality places a particular responsibility on NI to provide the tools necessary to make LabVIEW applications robust, secure, and CRA-compliant.
In an era where software vendors are expected to remove barriers to compliance, asking customers to pay extra for a fundamental security capability feels less like innovation and more like monetizing necessity.
When cybersecurity compliance becomes a premium add-on instead of a core platform capability, customers may reasonably begin to question where the value of the platform itself truly lies.
At a minimum, NI should offer a basic SBOM analysis capability. Better yet, it could open-source parts of the implementation and allow the community to contribute improvements. Instead, customers are being asked to pay a premium for access to a capability that is increasingly becoming a baseline expectation.
