08-29-2025 02:00 PM - edited 10-13-2025 01:39 PM
The security community is increasingly concerned about the use of programming languages that are not memory safe. Researchers claim that as many as 70% of the security vulnerabilities reported are the result of memory issues, and they fault languages like C/C++ that force users to carefully manage memory. A group of authors at CACM (Communications of the ACM, or Association for Computing Machinery) posted an article calling for an end to the use of non-safe languages (It Is Time to Standardize Principles and Practices for Software Memory Safety – Communications of th...). CISA and the FBI have also issued a statement to encourage the use of memory safe languages (CISA and FBI Warn of Malicious Cyber Actors Using Buffer Overflow Vulnerabilities to Compromise Soft...).
This did make us stop to consider- is LabVIEW a memory safe language? After working with NI software engineers, and some of our leading users in the community, we wrote the attached article. We assert that yes, LabVIEW is a memory safe language and should be considered as an alternative to C/C++ and other non-safe languages.
For details, please see the attached white paper. And let us know here if you have any questions or comments. Are you seeing this at your workplace? Are you being pressured to use memory safe languages to improve security?
09-05-2025 09:39 AM
Thank you for detailing out!
Many of LabVIEW’s built-in base functions (including signal processing, linear algebra, analysis, etc.) are ultimately implemented in compiled native code, most often in C/C++ DLLs. - Just trying to understand, how this is in overall makes LabVIEW a memory safe language?
Thank you.
09-05-2025 09:57 AM
That is a really important point and question. Yes, LabVIEW components are built using a variety of languages—including C, C++, and assembly. Other MSL environments like Python and Java are also implemented in C, while Rust stands out for being written primarily in Rust.
So, can you trust these environments?
This article is aimed at typical test system developers or teams who may not have the resources to fully test their code for memory-related issues. NI’s LabVIEW developers, however, have access to extensive testing tools that help minimize bugs in released versions. These releases are then used by many thousands of LabVIEW users, who provide real-world feedback that NI actively responds to. So ultimately, this question comes down to this- Can you trust NI? Do you trust our development and test process? Do you trust our large install base to test out our code? Do you trust that NI responds to reported issues? Or, do you trust yourself to develop error-free code without the test resources, the large install base, and the response resources?
NI is also transitioning toward using memory-safe languages in its development processes—part of a broader industry shift to improve software reliability and security. LabVIEW's long development history means that we use a variety of tools, but we believe that our long history and large user base also means that LabVIEW's code base can be trusted.
09-06-2025 04:08 AM
Great to see someone call this out Steve - memory safety is a important feature of LabVIEW that I always remember talking to customers about but before this term was common parlance.
I do think the whitepaper goes off the rails when it suggests Python is less trustworthy because it calls to C/C++ and it has muddied the waters of the message. In several forums the above question has been asked about whether LabVIEW is memory safe because it is written in C++
I also think that attempting to differentiate that memory safety isn't required because LabVIEW developers have superior tools also misses the points. Memory safety vulnerabilities are introduced by the best and most capable development teams in the world when using memory unsafe languages. In fact, the majority of CVE's reported in LabVIEW this year are due to memory safety issues.
This is not meant to say that LabVIEW should not be considered a memory safe language or NI are any less trust worthy than any of these other platforms. I just think it muddies the important point of the message.