LabVIEW, VIPM packages and tracking of their vulnerabilities.

[MzazM]

Hello,

cybersecurity requirements are asking to monitor vulnerabilities found in the libraries we use.

While I found a CVE list for LabVIEW, I haven't found any CVE associated to the packages we install via VIPM?

Do you think this should be something handled by JKI or by those that make their packages available via VIPM?

Edited March 30, 2023 by MzazM

[ShaunR]

It depends what you mean by "vulnerabilities". Buffer overflows, for example, cannot be managed by addon providers (only NI) while a memory leak of a queue reference can.

But lets expand the discussion into what, at all, security is available for addons? Many of the network resources aren't even HTTPS. 

I did start to write an installer which had in-built code signing and verification but haven't worked on it for a while. For code signing and verification it would need to be the installer (JKI) rather than the package provider. LabVIEW packages don't even have basic authenticity verification which has been a standard feature in package managers for over 20 years.

[MzazM]

Hi @ShaunR, thanks for your answer.

Indeed, knowing that, as of now, JKI does not provide authenticity verification of the packages we install is something worrying. It would not be easy to defend (read: get approval for) the cybersecurity and integrity of software built and deployed using such libraries. This is indeed a problem and I think it should be a feature request to VIPM forums. Link here if you or others are interested.

Going back to my original question. What I meant is that normally cybersecurity vulnerabilities are published in such CVE lists (for example the one for LabVIEW) , so that users can get notified and decide to patch the application or not. In my understanding there is no way to understand if the packages we install are affected by a security vulnerability leading to a vulnerability in the application that is using them. For example, this happened with the famous Log4j vulnerability few months back, where millions applications and devices where suddenly exposed. Is such a list something that in the world of Package management in LabVIEW is available? 

Edited April 3, 2023 by MzazM

[ShaunR]

16 hours ago, MzazM said:

Hi @ShaunR, thanks for your answer.

Indeed, knowing that, as of now, JKI does not provide authenticity verification of the packages we install is something worrying. It would not be easy to defend (read: get approval for) the cybersecurity and integrity of software built and deployed using such libraries. This is indeed a problem and I think it should be a feature request to VIPM forums. I will follow up there and post a link here if you (and others are interested).

Going back to my original question. What I meant is that normally cybersecurity vulnerabilities are published in such CVE lists (for example the one for LabVIEW) , so that users can get notified and decide to patch the application or not. In my understanding there is no way to understand if the packages we install are affected by a security vulnerability leading to a vulnerability in the application that is using them. For example, this happened with the famous Log4j vulnerability few months back, where millions applications and devices where suddenly exposed. Is such a list something that in the world of Package management in LabVIEW is available? 

CVE vulnerabilities will be logged against LabVIEW. All software written in LabVIEW will potentially be vulnerable until NI roll out a fix. There is little an addon developer can do. If the addon leverages other suppliers' binaries, then that is also a route to vulnerability but that would be outside NI's remit. The addon developer would need to keep a track of the issues associated with the binary distributions that they use. So. The answer is "it's complicated"

One of the issues I have had to deal with (and is probably something you may have to investigate depending on your environment) is that NI distribute OpenSSL binaries. However. Their security updates lag years behind the current fixes (currently OpenSSL 1.0.2u  20 Dec 2019, I believe). That was untenable for me and my clients so I had to come up with a solution that could react much more quickly. I moved away from the NI OpenSSL binaries to my own compiled ones from source (currently OpenSSL 3.1.0 14 Mar 2023). That meant I could update the OpenSSL binaries within weeks or days for serious issues, if necessary.