The Security Conversation We're Not Having
You've built a test system that's running 24/7 in production. The code is clean, the architecture is solid, and it's been humming along perfectly for months. Then someone from IT asks, "What security testing did you do on this?"
It's not that you don't care about security, you use a parity bit for your network data and you're careful with file permissions. But when it comes to systematic security design and testing? That's where most of us draw a blank.
In the cybersecurity world, there's a framework that's gained traction: Common Weakness Enumeration (CWE): think of it as the periodic table of computer science vulnerabilities. Whether your customer requires NIST compliance, ISO 9001, or the new EU Cyber Resilience Act, they're all speaking the same language underneath: CWEs.
The good news? LabVIEW's architecture already protects us from many common security nightmares. The better news? We can be just as systematic about the security challenges that do affect us.
Why CWEs Matter (Even for LabVIEW)
MITRE, the organization that manages our air traffic control systems and other critical infrastructure, created the CWE system back in 2006. They saw the same vulnerabilities appearing across many systems in a wide variety of industries and realized we needed a common framework to discuss them. Today, there are over 900 catalogued weaknesses, each with a number, description, and real-world examples.
Why should LabVIEW developers care? Because when your customer asks about your security posture, or when you're trying to meet compliance requirements like CMMC Level 2, they're thinking in CWEs. That SQL injection vulnerability? It's [CWE-89]. That hardcoded password in your connection string? [CWE-798]. Having these numbers isn't just bureaucracy, it's about speaking the same language as your security auditors, customers, and teammates in a clear traceable way.
The MITRE Top 25 list is the annual ranking of the most dangerous software weaknesses, is heavily skewed toward web applications and traditional text-based programming languages. Cross-site scripting tops their list, but when was the last time you built a web app in LabVIEW?
That's why we need our own lens for looking at CWEs. One that respects what makes LabVIEW different, and focuses on the security challenges we actually face.
The LabVIEW Security Advantage
Let's talk about what LabVIEW does best. While developers in other languages are wrestling with buffer overflows and memory corruption, we're protected by LabVIEW's automatic memory management. When you wire an array in LabVIEW, you can't accidentally write past its bound, the IDE simply does not provide that capability.
Consider MITRE's current top vulnerabilities that barely touch us:
- #1 Cross-site Scripting [CWE-79]: We're not building web pages with dynamic content
- #2 Out-of-bounds Write [CWE-787]: LabVIEW manages our memory boundaries
- #8 Use After Free [CWE-416]: Can't use memory after it's freed when you never manually allocated it
- # 21 Null pointer dereferences [CWE-476]: LabVIEW's type system prevents these by design.
Writing in code in C++ can mean lots of pointer math and bounds checks, in LabVIEW, memory allocations are handled securely by the compiler.
This isn't luck, it's by design. LabVIEW's dataflow paradigm and type safety eliminate entire categories of vulnerabilities by default. The wires carry both data and type information, making many classic exploits impossible.
Memory Safety by Design
LabVIEW qualifies as a memory-safe language, joining the ranks of Rust, Python, and other languages that automatically prevent memory-related vulnerabilities. While C and C++ require developers to manually manage memory allocation and deallocation, LabVIEW's dataflow paradigm handles this automatically. This means entire categories of the most dangerous security vulnerabilities (e.g. memory allocation) simply can't occur in normal LabVIEW code.
With recent government initiatives (CISA, White House) pushing for memory-safe languages in critical infrastructure, LabVIEW developers have a significant advantage when meeting new security requirements.
However, LabVIEW's strengths also create its own unique security challenges. The parallel execution model, while powerful, opens doors to race conditions. Our ease of creating user interfaces means input validation often gets overlooked. In visual programming it can be easy to inadvertently store and expose sensitive information on block diagrams and in default values on front panel controls.
The Real LabVIEW Security Challenges
LabVIEW is a unique language so deserves its own CWE Top 25 specialized the strengths and challenges of developing secure applications in LabVIEW. Starting from our JKI Secure Software Development plan, we ranked each CWE by relevance to LabVIEW, Severity, and how actionable each issue was to create a list of CWEs that are the most valuable to CWEs to consider when making a LabVIEW Application
[CWE-20] Input Validation: Our #1 Concern
In LabVIEW it's almost too easy to create a user interface. Drop a numeric control, wire it to your calculation, and you're done. But what happens when someone types 999999 into that motor position setpoint? Or enters "../../../" into your file path control?
A collection of LabVIEW input terminals with invalid, suspicious, and dangerous values. How do you validate your UI inputs?
Input validation [CWE-20] tops our list because it affects nearly every LabVIEW application. Though UI input validation is just a subset of CWE-20. Those friendly front panels we create are often the front door for problems. The good news is that LabVIEW gives us powerful tools:
- Numeric controls: Use the Data Entry properties, set minimums, maximums, and coercion, as well as "In Range and Coerce"
- String controls: Limit to 1 Line, cap lengths, use match pattern or regular expression validation for specific formats like IP addresses
- Path controls: Strip path traversal patterns and validate against expected directories
- Enum/Ring controls: The safest input is one where users can only select valid options
The Parallel Processing Pitfalls
What makes LabVIEW powerful, easy parallelism, also introduces unique hazardous pitfalls. Drop two while loops on a diagram and you've got parallel execution. Share data between them without thinking, and you've got a race condition.
Two parallel loops accessing the same global variable with racing loops. It is hard to predict the exact timing, and exact behavior of this code.
These concurrency issues manifest in sneaky ways:
- Race conditions [CWE-362]: Two loops writing to the same global variable
- Deadlocks [CWE-833]: Using -1 timeouts on queue operations (we'll fix this in a moment!)
- Improper locking [CWE-667]: DVR operations that aren't properly protected
The fix isn't to avoid parallelism, it's to be intentional about it. Use queues for communication, protect shared resources with DVRs & mutexes properly, and always ask: "What happens if these two things run at the same time?"
The Hidden Credential Problem
Quick confession time: How many of us have a string constant with a password sitting on a block diagram somewhere? Or an INI file with database credentials in plain text?
Hard-coded credentials [CWE-798] and cleartext storage [CWE-312] are all too common in LabVIEW applications. It's just so convenient to drop that connection string right where you need it. But convenience today becomes a vulnerability tomorrow when that code ships to a customer site.
The solution starts with awareness. Credentials belong in secure storage, Windows Credential Manager, encrypted configuration files, or environment variables. Never in string constants, never in plain text INI files, and definitely never in the default value of a control (yes, that gets saved with the VI!).
Three Security Wins You Can Implement Today
1. Fix Those -1 Timeouts [CWE-833]
Open your code right now and search for -1 wired to any timeout terminal. Found some? You're looking at potential deadlocks [CWE-833] waiting to happen.
Two primitives with default -1 timeouts, and two with valid default timeouts, than can be set to wait forever.
Replace -1 (wait forever) with reasonable timeout values. Even 5000ms is better than forever. Your application might hiccup, but it won't hang indefinitely.
2. Validate Every User Input [CWE-20]
For every control on your front panels:
- Numerics: Right-click → Data Entry → Set your min/max
- Strings: Right-click → Limit to Single Line (unless you need multiline)
- Paths: Add a VI that checks for ".." patterns after any path input
This takes minutes but prevents hours of debugging weird customer issues.
3. Hunt Down String Constant Credentials [CWE-798]
Search your project for string constants containing:
- "password"
- "pwd"
- Connection strings with embedded credentials
- API keys
Move these to encrypted config files or use the Windows Credential Manager. There are tradeoffs; more secure methods are often less convenient, but for critical data it's worth the trade.
4. Checkout: ni.com/security
Over the last few years NI (Emerson) has put a renewed focus on product security. They’ve created guides, tools, BOMs and resources to secure your products and hardware.
NI’s focus on tools for the security of LabVIEW are complementary to the security process and tools JKI provides for security of the source code you write. Together these tools provide a complete security solution for your mission critical LabVIEW Applications.
These small improvements add up to something bigger, code you can be proud of, that stands up to scrutiny. It's about crafting software that's not just functional, but trustworthy. Every timeout you fix and every input you validate is a statement: "I build reliable, secure systems that last."
Making Security Systematic with JKI Security Suite
You've made those three improvements. Your code is already more secure. But what happens when your team grows? When that aerospace customer asks for your security documentation, When you need to prove compliance with NIST 800-171?
The real challenge isn't fixing today's code, it's building a culture where secure coding is just how things are done. Where every developer knows which CWEs matter for LabVIEW. Where security testing happens automatically, not as an afterthought.
At JKI, we've spent years translating the world of CWEs into practical tools for LabVIEW developers, tools we use when we write code for NASA, and other mission critical applications. The JKI Security Suite brings enterprise security practices to the LabVIEW community:
JKI Cybersecurity Software Development Plan (SDP): A comprehensive framework that maps 71 CWEs to LabVIEW-specific practices. This isn't generic security advice, it's a detailed roadmap covering everything from race condition prevention to secure credential storage, complete with audit-ready documentation templates that speak your customer's compliance language.
J-Crawler Static Analysis: Automated security scanning built specifically for LabVIEW. It finds those -1 timeouts, flags hardcoded credentials, identifies race condition patterns, and checks for proper error handling, all mapped to specific CWE numbers. Run it locally or integrate it into your CI/CD pipeline.
J-Crawler Explorer: A modern web dashboard that transforms J-Crawler results into actionable insights. Sort, organize, and triage your results, and generate reports that prove your security posture to customers and auditors.
The truth is, security has become table stakes for serious LabVIEW applications. Whether you're building test systems for defense contractors, automation for pharmaceutical companies, or control systems for critical infrastructure, your customers expect, and increasingly require, demonstrable security practices.
The three quick fixes we shared earlier? They're a great start. But when you're ready to move from ad-hoc improvements to systematic security, when you need to satisfy audit requirements, or when you want to sleep better knowing your code is truly secure, we're here to help.
Ready to make security part of your LabVIEW DNA?
Learn more at jki.net/security
Enjoyed the article? Leave us a comment