LabVIEW CycloneDX SBOM Toolkit

[wiebe@CARYA]

---

@SumRunner wrote:

CRA requires that there are zero known vulnerabilities

---

That's not my understanding, but I'm quite new to the show. So while I'm building my CRA knowledge, I do (reluctantly) use AI to summarize... 

What would be non-compliant:

• Ship with known critical vulnerabilities that are unaddressed
• Ignore vulnerability reports
• Fail to provide fixes or updates
• Lack a vulnerability management process
• Don’t report actively exploited vulnerabilities

So (as I see it) you can ship with known vulnerabilities, as long as those vulnerabilities are mitigated in some way.

There should be 

• Responsiveness
• Transparency
• Lifecycle security management

Of course we'd all prefer 0 known vulnerabilities.

But will this ever happen?

LabVIEW must have a long, long list of dependencies. Are you really saying LabVIEW won't be compliant until each and every one of those dependencies fixed every known vulnerability?

That is a great goal, but I think in practice addressing known vulnerability is enough?

[joerg.hampel]

---

wiebe@CARYA wrote:

---

@SumRunner wrote:

CRA requires that there are zero known vulnerabilities

---

That's not my understanding, but I'm quite new to the show. 

---

My understanding is that these are the relevant sections of the CRA:

What is the literal requirement?

(2)	On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall: (a) be made available on the market without known exploitable vulnerabilities;

Source: Annex I Essential Cybersecurity Requirements

What does 'exploitable vulnerability' mean?

‘exploitable vulnerability’ means a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions;

Source: Chapter 1 Article 3 Definitions

...so as always with laws and regulations, there is room for interpretation 🤷‍♂️

[wiebe@CARYA]

---

@joerg.hampel wrote:

...so as always with laws and regulations, there is room for interpretation 🤷‍♂️

---

When it comes to our own CRA compliancy, I literally flip between "this is totally irrelevant", "this would be trivial" and "this is near impossible" several times during a single read or conversation.

In this case, I'd think there's a huge difference between "known exploitable vulnerabilities" and "known vulnerabilities".

For instance, in our LabVIEW executables, VI Server is a "known vulnerabilities", but it won't be a "known exploitable vulnerabilities" if you turn it off or address the issue in another way (secure by default?).

[SumRunner]

There is some room for interpretation, but the language about delivering with zero known exploitable vulnerabilities is pretty clear. The fines for non-compliance are very high and based on total global revenue. As a large global company, Emerson has to be very conservative in the way we interpret these regulations, because non-compliance would be such a large number.

LabVIEW does have thousands of dependencies. AI complicates this because it finds many more vulnerabilities than before. This, combined with the rule for zero vulnerabilities, will make 2027 a very busy year for the LabVIEW team (and other NI software teams). The hope in the security community is that even though AI will make 2027 much harder for all of us, it may lead to a future state with far fewer vulnerabilities. If AI helps us find and fix vulnerabilities now, and if we use AI to review code before release (and components do this as well), we may see far fewer - even zero - vulnerabilities in the future. So we view this as paying down historical technical debt for a better software future. 

[Jacobson]

---

@SumRunner wrote:

If AI helps us find and fix vulnerabilities now, and if we use AI to review code before release (and components do this as well), we may see far fewer - even zero - vulnerabilities in the future.

---

Zero?

[SumRunner]

That's what some in the security community are saying. The case study they use is Firefox - after years of manual review, they thought there were no more vulnerabilities. AI found 271 last month. But now that Firefox has fixed those issues, and they are running regular scans of their code, they don't think they will see any in the future. 

IBM and others are committing more than $5B in support for small and open source software to do the same with the components that get used in large software packages. 

I don't think we'll get to zero, but I do think we'll see a dramatic reduction from what we've seen in the past - after we see a dramatic rise over the next couple of years. 

Here's the Mozilla story: The zero-days are numbered  and the claim that zero-day exploits will go away. 

[wiebe@CARYA]

---

@Jacobson wrote:

---

@SumRunner wrote:

If AI helps us find and fix vulnerabilities now, and if we use AI to review code before release (and components do this as well), we may see far fewer - even zero - vulnerabilities in the future.

---

Zero?

---

FTR, Zero known vulnerabilities.

I know from experience that the number of bugs in software won't be zero until you stop looking for them.

I wander if that's different for vulnerabilities? Even AI can be trumped by better AI.

But I agree that security will become better. This (an enforced standard for software security) is 30 years overdue. The backlog seems to be the biggest problem.

[wiebe@CARYA]

I also wander if there's a quality or qualification to the vulnerabilities?

The last few that (I saw) where reported, and fixed, in LabVIEW where rather silly in my opinion.

Yes, an exe could crash if you drop a modified (hacked) VI on it and that could give a debugger system level access... I'd like to know (literally, not sarcastically) how that could be used to actually attack a system. I'd think a secure system should not allow a hacker to drop a VI on an exe, but I suppose this would be an improvement... 

In general I think we should all know much more about how to exploit these vulnerabilities if we want any change finding them.

[SumRunner]

I agree on some of these fixes. The problem is that these were found by white hat hackers - people who are not NI customers, but who download the eval versions of our software, and they work hard to create these hacks. They then report to us and to the CVE, with a date that they will go public. Once they do that, we have to respond; otherwise, it looks like there are open CVEs and scanning software will fail our software.

So you are doing the right thing - when you see these, look into the details and decide if it is worth the disruption of an update. 

[wiebe@CARYA]

I found a few situations where a modified VI crashed LabVIEW.

I used to obfuscate the diagrams of an entire toolkit (protecting IP despite "passwords"). That worked really well.

While figuring out what I could and couldn't modify in de BD Heap (in the VI's file, not with scripting) I found several things that would crash LabVIEW. So I tweaked until LabVIEW didn't crash.

Then I thought it "worked", the diagram didn't show anything!

It worked for hundreds of users, but not for 1, where loading the VI's crashed LabVIEW. The only difference I could find is that his LabVIEW was a configured with German as language...

I wander if\when AI will disclose this 😁.

It might actually spot these risks perfectly, as from LabVIEW's code it's probably a buffer overflow that can very well be detected by code review.