Three Pillars of Software Security Every LabVIEW Team Should Be Thinking About

Not long ago, most conversations I had with engineering teams centered only on performance, reliability, or reducing development time. Security was usually considered someone else's responsibility or as something owned by IT departments and cybersecurity specialists.

However, over the past year that conversation has changed dramatically.

Whether I'm talking with aerospace organizations preparing for CMMC assessments, manufacturers evaluating the European Union's Cyber Resilience Act (CRA), or engineering teams modernizing decades of LabVIEW code, the questions have become increasingly similar:

1. "How do we know what's actually in our software?"
2. "How do we know it's secure?"
3. "How do we demonstrate that we've followed good engineering practices?"

What has surprised me most is that these questions aren't being asked only by cybersecurity professionals but also by LabVIEW developers, test engineers, software architects, and engineering managers. This suggests that the role of the test engineer has changed over these past years.

Today's automated test systems are connected to enterprise networks, cloud databases, manufacturing execution systems, and AI analytics platforms. These systems collect enormous amounts of operational data and often make decisions that directly affect product quality and manufacturing throughput. As these systems become more integrated, they naturally become more attractive targets for cyberattacks looking to do harm. This vulnerability makes software security a key part of the whole engineering process and not just a concern for IT departments.

Fortunately, while the regulatory landscape may seem overwhelming, many of the requirements being introduced by standards (CMMC, the Cyber Resilience Act, and NASA software assurance practices) ultimately ask organizations to answer three fundamental questions about their systems:

• Do you know what's in your software?

Every software project depends on other software, and while some dependencies are obvious at a glance, others exist several layers beneath the application developers interact with every day.

LabVIEW applications may depend on NI packages, VIPM packages, third-party DLLs, .NET assemblies, drivers, operating system components, and libraries that themselves rely on additional software to function.

Most developers don't think about this entire ecosystem as they work, because they haven't needed to until now.

Now, when a new vulnerability is disclosed and organizations need to know if they are affected, they can't answer that question if they don't know what software their application contains or depends on to function.

This is where Software Bills of Materials (SBOMs) have become so important. An SBOM is an inventory of the software components that make up an application and how they are interconnected. Instead of manually reconstructing dependency trees when vulnerabilities are announced, engineering teams can immediately and easily determine whether they're impacted by looking at their SBOM, saving engineering time and energy.

• Have you actually tested your software for security?

Traditional software testing focuses on verifying that an application behaves correctly.

Security testing asks a slightly different version of this question.

What happens when someone maliciously tries to make it behave incorrectly?

Many software weaknesses have nothing to do with functionality but involve issues like hard-coded credentials, unsafe file operations, command injection opportunities, race conditions, insecure network communication, or resource exhaustion.

These problems often remain invisible because they don't surface when the applications are working as intended.

The earlier these weaknesses are identified, the easier they are to correct, as finding a security issue during development might only require a few hours of work, but finding the same issue after deployment could require emergency patches, production downtime, customer notifications, and much more.

That's why static application security testing (SAST) has become such an important part of modern software development. Rather than waiting until an application is deployed, static analysis evaluates the source code itself and identifies potential weaknesses before they become operational risks and become much more difficult to address.

Dynamic testing, penetration testing, and vulnerability scanning continue to play important roles after deployment, but with SAST, prevention is better than cure.

• Is security part of your development process?

This third question is one that most development teams have difficulty answering.

Organizations often address this only by asking which security tools they should purchase, but a better question is: What process do we want every engineer to follow?

Software security isn't created by simply running the right tool before a release. It requires consistently making good engineering decisions throughout the entire software lifecycle.

This process begins during system design and must continue through all stages, including coding standards, peer reviews, source control, unit testing, automated security scans, build management, deployment procedures, and long-term maintenance.

No individual practice eliminates every risk, but each additional secure layer significantly reduces the likelihood that vulnerabilities will ever reach production.

Organizations looking to deploy consistently secure and reliable software should then focus on building repeatable engineering processes that keep good security practices at the forefront of normal development.

Bringing the Three Pillars Together

We see these as the Three Pillars of Software Security.

1. Software Bill of Materials that helps you understand and keep track of what your software contains.
2. Static Application Security Testing that helps surface weaknesses before deployment.
3. Secure Development Processes that can prevent most of these weaknesses from being introduced in the first place.

These Three Pillars reinforce each other, and together they provide both the technical evidence and engineering discipline that modern software assurance requires.

Security Is Becoming an Engineering Discipline

It's easy to view today's cybersecurity requirements as another set of regulatory hurdles or "checkboxes to fill," but I prefer to look at them differently.

Many of these expectations represent engineering practices that improve software quality beyond simply fulfilling compliance requirements.

Understanding your software dependencies makes maintenance easier. Finding vulnerabilities earlier reduces cost. Following consistent development practices improves software reliability and maintainability.

The end result isn't just more secure software but overall better software that is cheaper to maintain and causes fewer issues in the long run.

As LabVIEW applications continue to become more connected and increasingly important to manufacturing, aerospace, defense, and research organizations, I believe security will become as fundamental to engineering as unit testing, version control, and code reviews are today.

While this transition won't happen overnight, every organization that starts answering these three questions today will be better prepared for whatever tomorrow's cybersecurity landscape brings.

Featured on Embedded Computing Design Magazine