Security in a software application requires a formal methodology for adding a secure mindset throughout the development lifecycle. This software development lifecycle (SDLC) starts before development begins with preparing the team, setting up protections for the development of the software, following best security practices in the design of the software, and supporting the software after release. This paper provides recommendations for NI LabVIEW teams to adopt a formal SDLC that includes a secure software development framework into their projects.
A software development life cycle (SDLC) is a formal or informal methodology for designing, creating, and maintaining software (including code built into hardware).
Every software team already has a development process, whether or not it is formally documented. Intentional secure development adds activities throughout that process to reduce vulnerabilities, improve maintainability, and reduce the cost of fixing security issues. Vulnerabilities include not just bugs caused by coding flaws, but also weaknesses caused by security configuration settings, incorrect trust assumptions, and outdated risk analysis.
The earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security. This principle, known as shifting left, is critically important regardless of the SDLC model. The shift left principle is true for any programming environment, including LabVIEW—a secure programming environment that can be used to develop secure applications. Much of the security of the completed application depends on the SDLC adopted by the development team.
An important note about SDLC and compliance: Most regulatory programs like the European Cyber Resilience Act (CRA), US Cybersecurity Maturity Model Certification (CMMC), UK Defence Cyber Certification (DCC), and others require evidence that a system was designed following secure practices like those in this SDLC, but these programs require much more than just an SDLC. For more specifics, refer to documentation for those programs.
This guidance is based primarily on the principles and practices defined in NIST Special Publication 800-218, Secure Software Development Framework (SSDF), which provides a technology-neutral framework for developing secure software and is widely recognized as supporting US government software security requirements. Each SSDF practice has been interpreted and applied specifically to the needs of LabVIEW development teams, with emphasis on practical implementation within test, measurement, automation, and engineering environments.
The recommendations presented in this document were also compared against other established secure development frameworks and industry best practices, including the JKI Security Suite and Microsoft Security Development Lifecycle (SDL), to ensure consistency with proven approaches to software security, risk management, and software supply chain protection. The objective is to provide LabVIEW organizations with a practical roadmap for integrating cybersecurity into their development processes while generating the evidence and traceability increasingly required by customers, regulators, and government acquisition programs.
The process described in NIST 800-218 covers these four areas of software development:
In this paper, we use these topics to guide the development of a LabVIEW SSDF.
Before starting development, it is important to take steps to help your team adopt secure development principles, complete the necessary training, and establish the processes and tools that will support secure development. This phase includes taking time to achieve the following goals:
These requirements are generic to any software development team, but there are some steps to take to adapt these to test teams, and to LabVIEW teams.
Many test teams are isolated from their company’s security team. Coordinate with them to build a relationship of trust, so they know that you take security seriously. Meet with your security team to understand their requirements for developed code. Show them your projects and your test areas, and walk them through your processes. It is helpful for them to understand how a test lab operates and to know what limitations you face. Your challenges will be unique from other IT systems, and it helps if the security team understands those differences.
It is also important for you to understand the security team’s concerns. As you understand what programs they are required to meet, you can trace security mandates back to requirements, and you can better meet the intention of the original program.
Requirements tracking is an important part of preparing your team to deliver secure code. More than just storing requirements, a good tracking process provides traceability of those requirements. Your team should be able to trace a requirement throughout the lifecycle:
Requirement Definition → Design → Implementation → Test → Defect Remediation → Release
This traceability becomes evidence during customer audits, security declarations (like CRA), assessments (like CMMC), or supplier security reviews.
GitHub Issues + Projects + Milestones is the most common requirements tracking approach for most smaller teams. Other options for tracking include GitLab (with both free and paid tiers), Azure DevOps, JIRA, and other professional software development tools. These tools let you create issues and track them through to resolution.
Inside your chosen tool, systematically track security requirements. Each requirement should meet the following criteria:
After you identify a requirements-tracking tool, document your process to include the use of these tools in your development. Use the process for requirements tracking and issue tracking throughout the lifecycle of the system. Your process may include the following steps:
Plan to make your code modular. This step is especially helpful in LabVIEW, since you can test individual modules. As you plan your modular architecture, plan to develop unit tests as well. These improve your code quality and provide a faster way to validate code after making updates, even after the system has been deployed.
Learn more about using the NI Unit Test Framework
Third-party testing tools provide additional value; for example, JKI’s Caraya and LUnit products expand software testing for LabVIEW teams.
Define a process to check and approve subcontracted work, third-party software, and open-source components. Your process should include checking public databases like Common Vulnerabilities and Exposures (CVE) to identify known vulnerabilities in the components you use.
If you use open-source components, you are responsible for scanning vulnerabilities prior to using the code in your application.
Define specific roles on your team, including security-specific roles. Identify the responsibilities and access of each of these roles. At a minimum, define roles with privileged access (admins) separate from user roles (developers and operators).
Create security training applicable to those roles. Assign the training to team members and track completion of the training. Those records will be used as evidence in a certification review.
Consider using the NI security training available online: Security Considerations for Test System Integrations Course.
Industry certification programs such as ISC2 provide low-cost introduction-level certifications. The value of these programs to a test team is to provide a common language for communicating with security teams.
After you have defined your SDLC, present this to company leadership and get their formal support for it. It should be approved by at least the level that approves the security budget, to show their commitment to the program.
As an organization, identify the types of data you may encounter and create a labeling system. You should consider the following data types:
Having a clear data management and labeling system will enable you to protect the data appropriately, applying the right restrictions to each classification of data. Defining this as an organization before starting your system development will save time by applying the right controls to the right risk areas. Mapping into existing corporate and IT labeling systems will simplify how systems share data with each other.
Identify the software and driver versions and configurations that you will standardize on for security. For LabVIEW, identify the version you will use for development. Establish a secure configuration for your installations. You can follow the LabVIEW Secure Configuration Guide. You can find other secure configuration guides at ni.com/security.
For auditability and to quickly set up new systems, automate how development and build machines are set up. Establish a baseline installation and create an image from that installation.
Establish tools to be used for security checks throughout your development. You will need a static application security testing (SAST) tool to analyze your source code without executing the program to find potential security vulnerabilities. For LabVIEW graphical code, we recommend the JKI Security Suite, designed specifically to provide static analysis of LabVIEW code. Alternatively, you can perform manual static code analysis looking for security issues.
SAST tools are one important security tool to analyze code for vulnerabilities. Dynamic application security testing (DAST) tools are also important and are used to scan the running code during testing. Software composition analysis (SCA) identifies the use of open-source libraries, third-party packages, and software components and scans for known vulnerabilities and licensing issues with those components.
There are many other types of tools used for scanning code for security issues. The right tool for your project depends on your toolset, the nature of your project, and the kinds of code you use. During this phase of the secure development lifecycle, it is important to research and identify the tools your team will use.
Secure development requires that source code is stored—with multiple versions so that teams can revert to previous versions in case something breaks in the code. As part of preparing the organization to do secure development, establish a code repository that stores code, checks out code for development, and maintains version control of the source code.
Branching in the code repository facilitates parallel development and stable releases. Define the branch types you will use in your organization. These branch types are standard, but may be adapted to your needs:
Use a repository that provides proper security controls. Ensure that the repository maintains a complete history of commit files and changes for traceability.
Ensure that the computers used for developing code follow basic cybersecurity policies. These basic controls include password protection, malicious code protection, and other basic cyber hygiene. As an example of these basic controls, refer to https://www.acquisition.gov/far/52.204-21.
For traceability, capture the configuration settings of the computer used to develop the system. Configuration settings to capture include the following examples:
Most security programs will require evidence that your team followed the practices established as part of the SSDF. Establish a repository to track evidence and keep it updated throughout the development and deployment of the system. The system should track the following items:
Many teams perform these security activities but cannot prove they did them. Compliance teams will want to see both: that your team has processes in place, and that you follow them. Having these documents in one place will greatly simplify audits and compliance reviews.
When the organization has been prepared to develop code securely, the next task is to protect the software. This step ensures that the team keeps the code safe during development and release.
Protecting software during the development process is critical for any software, regardless of the programming language used. As LabVIEW teams adopt professional workflow tools for software development, those teams must adopt secure development processes and tools as well.
Use the secure code repositories identified in the previous phase to store and manage your code. A good repository does more than manage the source code. It also contains the requirements, documentation, build scripts, test artifacts, and release histories. Because the repository contains so much of the code and support, it is important to use a secure repository—if the repository is compromised, your software is compromised.
Within the repository, your main branch is a critical asset that must be protected. Your team should define and follow policies to protect the code. These policies may include the following examples:
The repository should also provide traceability from the generation of a requirement, through development and out through the product release. Some repositories allow signing of commits (for example, in Git).
The repository should provide an audit trail by keeping a record of software changes. What changed, who changed it, why was it changed, who approved it, and when was it released? Additionally, release images should be backed up to a secure archive, so that code can be retrieved even if the repository is compromised.
An SBOM provides a list of software and components used in the development of the code. Generating an SBOM as part of the build process ensures that you have a log of which components are used in the code, streamlining the process to identify and fix vulnerabilities.
Starting with LabVIEW 2026 Q3, you can generate SBOMs as part of the application build process. For more information, refer to Generating a Software Bill of Materials for a Stand-Alone Application.
Code signing provides a mechanism for users to verify that software was produced by a known organization, has not been modified since release, and was approved for distribution. In a LabVIEW application, code signing should be applied to executables, installers, deployment packages, DLLs, drivers, and update packages.
You can sign your application during the build process by following these instructions. You can also sign software using SignTool.exe from Microsoft, which is the same as signing any application or file.
Applications frequently require secrets such as passwords, API keys, certificates, tokens, encryption keys, database credentials, and service account credentials. These secrets provide access to systems and data and must be protected throughout the software lifecycle.
Never hard-code passwords, API keys, certificates, or encryption keys directly into source code, configuration files, build scripts, or test utilities. Hard-coded secrets are difficult to rotate, may be copied into repositories, and can be exposed through source code reviews, backups, or reverse engineering of deployed applications.
Store secrets using secure operating system or hardware-protected storage whenever possible. Examples of secure or protected storage include the following options:
Apply the principle of least privilege when granting access to secrets. Only users, systems, and services that require access to a secret should be able to retrieve it. Administrative credentials should be separated from user credentials, and shared accounts should be avoided whenever possible.
Passwords, certificates, API keys, and encryption keys should be periodically replaced according to organizational policy. Establish a process that defines how secrets are generated, where they are stored, who can access secrets, and how compromised secrets are revoked.
Test systems frequently use real network connections, databases, cloud services, and instruments. Test teams need access to these systems during testing. Use dedicated testing credentials rather than production credentials whenever possible. Separate testing environments reduce the risk of exposing operational systems during development and validation activities.
This phase focuses on designing, implementing, testing, and validating software securely. To do this task effectively, a team must evaluate the risks and requirements of the intended software use and design for those risks. Best practices include reuse of known secure components where possible, testing during development, and scanning development code for vulnerabilities. Teams plan for secure use, including using secure-by-default settings.
Test and measurement applications face security challenges different from general software applications. LabVIEW teams are positioned to understand those challenges and develop software that will protect against attacks focused on their applications. LabVIEW provides a number of inherent safety protections, but teams must consider the possible attacks and prepare a defense against them.
OWASP (Open Worldwide Application Security Project) is a nonprofit foundation that provides free tools, guides, and standards to help people build secure software. OWASP provides a community-driven guide to threat modeling; their model provides a structured series of steps to scope your work, determine threats, determine countermeasures and mitigation, and assess your work.
For test teams, this starts with a conversation to understand the intended use and threats for the system being developed. The conversation should include the lead developer, test architect, system engineer, product owner, cybersecurity representative, and operations personnel.
The OWASP approach includes a threat list including spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege (STRIDE). STRIDE threat categories help guide a team to consider all types of threats.
Test teams should draw upon their experience in brainstorming sessions to look specifically at how threats will impact their systems in a test environment:
Adding these test-specific risks to more traditional cyberthreats will help identify appropriate defense strategies for the test system. The output of threat modeling should be a set of prioritized risks and the security requirements necessary to mitigate those risks. These requirements become inputs to the system design and development activities described in the next section. Periodic threat reviews can help teams identify new and emerging threats over time and can include a review of issues that previous threats didn’t capture.
Threat modeling identifies risks to the system. The next step is to convert those risks into measurable security requirements that can be implemented, tested, and traced throughout the lifecycle. Security requirements should be treated with the same level of rigor as functional requirements.
A security requirement defines a security control or behavior that the system must provide. Good security requirements are specific, measurable, testable, and traceable. The following table shows some examples.
Security requirements should be assigned unique identifiers and tracked through the same requirements management tools used for functional requirements.
A well-defined security requirement should be traceable through the complete development lifecycle. Traceability demonstrates that identified risks were addressed and provides valuable evidence during customer audits, supplier security assessments, and regulatory reviews.
Test and measurement systems have security requirements that are often overlooked in enterprise software projects. As you develop security requirements use standard security categories, but also consider the following data:
Because inaccurate measurements and corrupted test results can have significant business consequences, security requirements for integrity are often as important as requirements for confidentiality.
Modular code limits the impact of defects and vulnerabilities by isolating functionality into well-defined components with controlled interfaces. In a good modular design, each module exposes only the functions that other modules need. This task provides fewer entry points and reduces the opportunities for misuse. Modular code also has the advantage that it is easier to test, so it is easier to apply and validate updates to the code.
As you build modular code, consider the principle of least privilege. A module should only have the permissions required to perform its function. For example, an instrument communication function does not need access to a database, as this is handled by a different module. Avoid passing the database handle to the instrument communication module.
As data is passed among modules, assess the trust of the communication. Where applicable, validate the source before accepting data from another component.
Modular code should make security reviews easier. Each module can be reviewed, rather than reviewing the entire set of code with each review. The code reviewer does not need to understand the entire set of code to contribute to the security of a single component.
Code modules also simplify code reuse. A module that has been developed securely and tested can be reused into other applications with confidence that it works as intended.
Establish a set of best practices and follow those practices. Your code reviews should verify compliance with these practices. While a complete review of best practices is outside the scope of this document, these should include at a minimum these areas:
Use a recognized LabVIEW unit testing framework (NI Unit Test Framework, JKI Caraya, or LUnit). These tools allow developers to define inputs and outputs and validate that the code operates correctly. This can be done without running the entire application, simplifying code validation.
Unit testing protects sensitive functions, like controlling expensive equipment, because modules can be tested in isolation. Unit tests should be designed for repeatable execution and are ideally integrated into a continuous integration (CI) system to ensure that they run automatically on code changes.
Frequent security reviews are an important part of establishing a security-minded development culture. Reviews provide a way for teams to establish secure practices, learn from each other, and reinforce secure processes. Security reviews start before development—reviewing the planned architecture and methods. Reviews should then continue throughout the development process to ensure that code is developed securely. Frequency should be based on the size of the development; reviews should occur frequently enough that issues can be corrected before significant downstream development has occurred. Reviews should occur at every merge request, pull request, or other significant code integration event. Additional scheduled reviews may be appropriate for large projects.
Security reviews are greatly enhanced when a team works through the review from a checklist. These checklists should be established by the organization and customized at the beginning of each project based on the threat and risk analysis.
In addition to manual code reviews, perform automated code reviews. If you use a continuous integration and continuous delivery/deployment (CI/CD) process, add security scanning to your intake process so that code is scanned with each code check-in. Set up additional scanning tools to run daily or weekly to catch any newly introduced security flaws before they become a permanent part of the code. Use static analysis, unit tests, and other security scanning tools to include a variety of review types.
Where possible, use the latest version of the development software drivers. New security threats are identified almost daily, and developers build security fixes into patches and new software versions. If you can’t use the latest version, use software that is still receiving security updates from the vendor, and will receive them for the lifetime of the system.
Configure your tools for security using the configuration guides provided by the vendor.
See the list of supported software versions for NI products
Prior to releasing the product, apply testing based on the threats and risks identified at the beginning of the project. This list may include the following tests:
Because LabVIEW is a graphical programming language, some traditional security tools cannot test LabVIEW code. Tools such as the JKI Security Suite provide security-focused static analysis capabilities designed for LabVIEW developers—able to scan LabVIEW code and tuned to the specific security concerns of a graphical programming language.
Learn more about the JKI Security Suite
A release should not be approved unless the development team can demonstrate that the threat model was reviewed, critical vulnerabilities were resolved, unit tests were applied and passed, static analysis was performed, an SBOM was generated, code reviews were conducted, and the release package was signed. Enforcing a formal release gate process gives management a decision to point to review that processes were followed and the software is secure.
Developing secure software is only part of the process. A secure application can become vulnerable if it is deployed incorrectly or if security controls are removed during installation and configuration. The deployment process should therefore be treated as part of the secure software development lifecycle, with defined procedures, reviews, and validation activities before software is released to users.
Secure Default Configuration
Applications should be deployed using secure-by-default settings. Users frequently assume that default settings represent the recommended configuration. Any security-sensitive option that is disabled by default may remain disabled throughout the life of the system.
Secure defaults can include the following examples:
Users should be required to consciously weaken security settings rather than manually enabling security protections.
Production Hardening
Before release, remove development artifacts and features that are useful during development but create unnecessary risk in production environments. Review the application for the following criteria:
Production systems should expose only the functionality required to operate the system.
Account and Permission Management
Review the permissions required by the system and assign them to appropriate roles. Systems should not grant administrator privileges unless there is a documented operational need. Service accounts should be configured with only the permissions required to perform their intended function. When considering role-based permissions, consider:
If the system stores sensitive information, verify that access controls protect that information appropriately.
Network Security Configuration
Document all required network communications before deployment. For each connection made by the system, consider:
When data crosses network boundaries the data must be protected. For each data transmission, take the following precautions:
Test systems are often connected to enterprise networks, manufacturing networks, cloud services, and instruments simultaneously. Understanding and documenting these trust boundaries is an important deployment activity.
Secret and Credential Management
Applications often require passwords, API keys, certificates, tokens, or encryption keys. When handling these secret tokens, take care not to:
Instead, use one of the following tools or technology:
Document how secrets are created, stored, rotated, backed up, and revoked. Follow this process.
Logging and Auditing
Applications should record important operational and security-relevant events. Events to log include the following examples:
Verify that logging does not include logging any secrets, such as passwords and personal or confidential information, as logs may be visible to audiences not intended for that information.
Logs help troubleshoot failures, investigate incidents, and demonstrate compliance with customer and regulatory requirements.
Where possible, integrate application logs with platform logging mechanisms such as Windows Event Viewer or Linux Syslog to simplify monitoring, incident investigation, and compliance reporting. Evaluate if sending logs to a secure server will help with protection and accessibility.
Protect audit logs from unauthorized access and modification and define how long logs will be retained.
Release Approval
Before releasing software, perform a final security review to verify the application meets the team’s release requirements. As part of this final review, include:
The release process should produce evidence showing that these activities were completed. These evidence records should be protected from tampering after the release to maintain integrity.
Code Signing and Package Integrity
Users should be able to verify that released software originated from the expected organization and has not been modified since release.
Code signing should be applied to all the following software types:
Code signing does not prevent software modification but provides strong detection of unauthorized modifications and assurance that software originates from the expected publisher.
Deployment Validation
After installation, verify that the deployed system operates securely in its intended environment. Validation activities should confirm the following functionality:
Security validation should be performed whenever significant configuration changes are made.
Deployment Evidence
Maintain records demonstrating that deployment was performed according to the defined process. These records include the following examples:
These records provide valuable traceability during customer audits, supplier assessments, regulatory reviews, and internal security investigations.
A software vulnerability is a weakness, flaw, or defect in software design, implementation, configuration, or operational processes that could be exploited to compromise the confidentiality, integrity, or availability of a system or its data. A vulnerability may be identified in the code developed by the team, or in one of the components used in the software. Because vulnerabilities provide malicious actors a way to damage a system, it is important that these vulnerabilities are remediated and deployed to affected systems.
The test industry faces a historical challenge with responding to vulnerabilities. Many test projects are funded through a single upfront funding model—with no funding for ongoing maintenance of the systems. This means that test teams don’t have the resources to update systems, even to provide security updates. This presents a direct conflict to the security requirements to keep systems updated.
A significant challenge is the amount of validation required to make updates. Even if the software and hardware tools are no cost, an update can be very expensive to validate the system works as intended after the update.
As the security industry changes, the test industry must also start to change to better plan for and fund test systems throughout their lifecycle. There are some steps that test teams can take to shift to a full lifecycle management approach, which include:
We announce vulnerabilities in NI products, including LabVIEW, drivers, and other software, at ni.com/security. Patches are also reported through the Common Vulnerabilities and Exposures (CVE) system. These patches may fix vulnerabilities in the software code developed by NI engineers or in the components we use. You can sign up for notifications of new patches at ni.com/security.
An SBOM can also be used to automate scans of the software. If you generate an SBOM from your LabVIEW application, you can set up scanning software to check the CVE database for reported issues and notify you. There are a variety of software composition analysis (SCA) tools that scan SBOMs and match these to the CVE database.
If your end user identifies a vulnerability, they can report this directly to you. If the problem is inside the NI software, you can report that at ni.com/security.
It is important to take vulnerability reports seriously. If your user reports an issue, or if a vulnerability is reported in your software stack, analyze the vulnerability to determine the impact and likelihood of it being exploited. These issues are impacted by the nature of the vulnerability and by the way you’ve used the affected software component. If you determine that the threat of exploitation is significant, you need to update your software and issue a patch to your end user.
Some regulations, such as the European Cybersecurity Resilience Act (CRA), require that you provide security patches for five years or more. Some contracts may specify longer or shorter support commitments. Plan for this level of support in your initial project proposal to avoid surprises after you deliver the project.
As part of your vulnerability remediation process, perform root cause analysis of the vulnerability to improve your development process to eliminate similar issues in future projects.
Secure software development is not a separate activity performed at the end of a project. It is a set of practices integrated throughout the lifecycle of a system. By adopting the principles described in this guide, LabVIEW teams can reduce vulnerabilities, improve maintainability, simplify compliance efforts, and better protect the systems and data entrusted to them. Security is a process and your team will mature over time. Start now to establish a repeatable and sustainable process that continuously improves security throughout the life of the product.
| Threat | Security Requirement |
|---|---|
| Unauthorized modification of test results | Only authenticated users with the appropriate role shall be allowed to modify stored test results. |
| Interception of network traffic | All communications between the application and external systems shall use encrypted protocols. |
| Corruption of calibration data | Calibration data shall be protected from unauthorized modification, and all changes shall be logged. |
| Unauthorized equipment control | Administrative or hazardous equipment operations shall require authenticated and authorized users. |