RAT — Built for ComplianceRelease Automation Tools for LabVIEW
v1.0.0RAT — Release Automation Tools
Cybersecurity · Compliance · LabVIEW

RAT does not just help build LabVIEW software;it makes compliance attestation provable.

Release Automation Tools for LabVIEW. A LabVIEW-native CI/CD pipeline that produces SSDF, CRA, IEC 62443, IEC 62304, MDR, and FDA evidence as a by-product of every build — tied to the exact Git commit, stored automatically.

Runs on GitLab CI, GitHub Actions, Azure DevOps No cloud dependency — on your build server Immutable, version-controlled pipeline
Talk to us about your compliance roadmap Explore the page first
United States

Federal Mandate

Executive Order 14028 (May 2021) and OMB M-22-18 require every federal software supplier to attest that they follow NIST’s Secure Software Development Framework (SSDF). LabVIEW shops supplying federal agencies — or their contractors — are directly in scope.

European Union

Cyber Resilience Act

Regulation (EU) 2024/2847 applies to any product with digital elements sold in Europe — including LabVIEW applications. Full compliance required by 11 December 2027. US, UK, and global companies selling into the EU are not exempt.

Industrial & Medical

IEC 62443, IEC 62304, FDA & MDR

Industrial control systems and medical devices add their own process requirements: IEC 62443-4-1 for OT, IEC 62304 for medical software, FDA Cybersecurity 2023, and the EU’s MDR 2017/745. Filter below by your industry to see what applies.

Cybersecurity for LabVIEW

Pick a view, then narrow by your industry and region. Your industry and region selections persist across views.

Industry
Region
Showing all 7 regulationsUnited Statesall industries

What your regulations require

Federal mandates, NIST frameworks, FDA guidance, and international standards
Executive Order 14028General
Improving the Nation’s CybersecurityWhite House · May 12, 2021
Key requirements for software suppliers:
  • Secure software development practices required for all software sold to the federal government.
  • Software supply chain security — knowing what is in your software and how it was built.
  • Mandated NIST to define what “secure development” means → produced the SSDF.
  • LabVIEW impact: any LabVIEW software supplied to a federal agency or federal contractor must comply.
OMB Memorandum M-22-18General
Enhancing the Security of the Software Supply ChainOMB · September 14, 2022
Operationalises EO 14028 for agencies:
  • Federal agencies must only use software from producers who can attest SSDF compliance.
  • Attestation form (CISA, March 2024) — an officer must sign that secure development practices were followed.
  • Requires artefact evidence: automated tool outputs, build provenance records, test results.
  • Third-party suppliers to federal contractors are also in scope — the obligation flows down.
NIST SP 800-218 — SSDFAll
Secure Software Development FrameworkNIST · February 2022 (v1.1) · v1.2 in draft 2025
The SSDF defines four practice groups:
  • PO — Prepare the Organisation: governance, tooling, environments.
  • PS — Protect the Software: source code protection, access control, signing.
  • PW — Produce Well-Secured Software: design, code, test, build securely.
  • RV — Respond to Vulnerabilities: identify, analyse, remediate.
  • PW.4 / PW.8 / PW.9 are the most directly actionable for a LabVIEW dev team.
CMMC 2.0General
Cybersecurity Maturity Model CertificationDoD / NIST SP 800-171 rev 3 · Phase 1 launched November 2025
Mandatory for DoD contractors (prime and sub):
  • SA.11 — require developer security testing (analysis, threat modelling, assessment).
  • SA.15 — require documented processes, standards, and tools.
  • CM.2 / CM.6 — baseline configurations maintained and managed in version control.
  • CMMC certifies the organisation’s process maturity, not just the product.
FDA — Cybersecurity in Medical DevicesMedicalIndustrial
Quality System Considerations and Content of Premarket SubmissionsFDA CDRH · September 27, 2023 · supersedes 2022 draft guidance

LabVIEW is widely used in medical device software, instrument control, and FDA-regulated process control (pharmaceutical manufacturing under 21 CFR Part 11, GxP environments).

Requires premarket submission to include:
  • Cybersecurity risk assessment and design controls.
  • SBOM — a complete list of all software components and libraries.
  • Secure build and release process documentation.
  • Evidence of testing for vulnerabilities and security properties.
  • Post-market vulnerability monitoring and patch plan.
IEC 62443-4-1:2018Industrial
Secure Product Development LifecycleIEC/ISA · 2018 (under revision 2024) · international, applies in the US too

The international SDL standard for industrial / OT software — widely required by US industrial and energy customers, especially under NERC CIP and TSA pipeline rules.

  • SM — Security Management: defined, documented, version-controlled SDL.
  • SR — Security Requirements specified before coding.
  • SI — Secure Implementation: code review, static analysis.
  • SVV — Security Verification & Validation: testing, pen testing, independence.
  • DM / OM — Defect Management; release and deployment procedures.
IEC 62304:2006/AMD1:2015Medical
Medical Device Software — Software Lifecycle ProcessesIEC/ISO · 2006 + Amendment 1 (2015) · international, FDA-recognised consensus standard

The international standard for medical device software lifecycle. The FDA recognises it as a consensus standard for premarket submissions; the EU references it in MDR harmonised standards.

  • Software safety classification (Class A / B / C) drives process rigour.
  • Required documentation: software development plan, requirements, architecture, unit and integration tests.
  • Mandatory configuration management with version control.
  • Defines verification, validation, and software problem resolution processes.
  • Required for any LabVIEW software inside a medical device or used in its production.
No items in this view — try adjusting filters above.

How RAT helps you comply

Pipeline mapping · SSDF, OMB M-22-18, IEC 62443, IEC 62304
PO — Prepare the Organisation · PO.2, PO.5 (SSDF) · SA.15 (CMMC) · IEC 62304 §5.1 / IEC 62443-4-1 SMDocumented, enforced development process

RAT’s rat.yml and gitlab-ci.yml are the documented, version-controlled development process. Immutable init and teardown stages ensure the process cannot be bypassed by any team member — the kind of evidence SSDF PO, IEC 62304’s software development plan, and IEC 62443-4-1 SM all require.

Covered
PS — Protect the Software · PS.1, PS.2 (SSDF) · CM.2, CM.6 (CMMC) · IEC 62304 §8 (configuration management)Source code and pipeline in version control

RAT runs natively on GitLab CI. All pipeline configuration (rat.yml, gitlab-ci.yml, rat-custom-*.yml) is committed to Git alongside the source code. Every build is tied to a specific, immutable commit — a per-release, per-buildspec audit trail that satisfies PS.2 / CM baseline-configuration requirements and IEC 62304’s configuration management.

Covered
PW.4 / PW.5 — Secure, reproducible build processClean-environment, dependency-pinned builds

rat-initializr clears the Compiled Object Cache and applies the project’s VIPC file on every run — guaranteeing a clean, dependency-pinned build environment. The same inputs always produce the same outputs, which is the practical definition of a reproducible build under SSDF PW.4.1 and PW.5.

Covered
PW.7 / PW.8 — Code review and tests in CI · IEC 62304 §5.5–5.7Mandatory, non-bypassable quality gates

rat-analyzr runs the NI VI Analyzer on every changed VI; results stored as a GitLab Code Quality report per commit. rat-testr executes NI Unit Test Framework tests with JUnit XML output. rat-validatr performs architectural checks. Together these satisfy PW.7.1, PW.8.1, and the unit / integration testing required by IEC 62304. Note: VI Analyzer covers code quality; security-specific SAST rules for LabVIEW are not currently available from NI.

Partial
PW.9 · OMB M-22-18 SSDF Attestation SupportAuto-generated audit evidence package

rat-teardown collects test reports, analysis results, documentation, and builds into a single bundle stored in GitLab per commit tag. The CISA attestation form (March 2024) asks for evidence of secure build environment, automated tool use, build provenance, and test results — RAT’s artefact set is that evidence. The attestation officer can point to stored GitLab artefacts for every question on the form.

Covered
PS.3.1 · OMB M-22-18 build provenanceVersioned, company-stamped, organised artefacts

rat-buildr stamps version and company metadata into every built artefact. rat-deployr organises outputs under a versioned namespace (destination\namespace\project\vX.Y.Z). Combined, these provide the build provenance record required by PS.3.1 and OMB M-22-18.

Covered
No items in this view — try adjusting filters above.

What RAT does not yet cover — for your region

Region-specific gap notes · cross-link with the roadmap above

RAT is the most complete automated compliance toolchain available for LabVIEW — but these gaps are real and should be disclosed. The roadmap section above ranks them by HSE priority; the cards below explain the regulatory implication.

SBOM Generation

SSDF PW.4.1 · OMB M-22-18 · FDA Cybersecurity 2023 · IEC 62304 §8.1.2

A Software Bill of Materials — a machine-readable inventory of all software components — is required by OMB M-22-18 attestation, FDA premarket submissions, and IEC 62304 software item identification. rat-documentr already parses the full LabVIEW project tree. SBOM output (CycloneDX or SPDX format) is planned as an extension of the Document stage.

On Roadmap

Build Artefact Code Signing

SSDF PS.3.2

Build outputs should be cryptographically signed so downstream consumers can verify authenticity and detect tampering. rat-buildr stamps version metadata but does not yet apply a cryptographic signature. An optional Authenticode-compatible signing step is on the roadmap.

Gap — Planned

Vulnerability / Dependency Scanning

SSDF RV.1 · CMMC SA.11

No CVE database exists for LabVIEW components. No commercial SAST tool supports G-code. RAT cannot scan for known CVEs in LabVIEW packages — this requires NI / Emerson to publish a component vulnerability feed. RAT’s clean-environment builds prevent dependency drift, which is the practical mitigation available today.

Ecosystem Gap

Attestation Document Generation

OMB M-22-18

The SSDF attestation form is currently completed manually using RAT’s artefact evidence. A machine-readable attestation report — mapping artefacts to SSDF practices — is on the roadmap as a rat-documentr extension.

Gap — Planned
No items in this view — try adjusting filters above.

What your regulations require

CRA, NIS2, IEC 62443-4-1, MDR, and IEC 62304
Selling to Europe? CRA applies to you — even if you are headquartered outside the EU. Any product with digital elements offered for sale, distribution, or download to EU users — from any manufacturer globally — is in scope. The CE mark under CRA will be required on the product by 11 December 2027.
Regulation (EU) 2024/2847 — EU Cyber Resilience ActAll
Key dates & scope
  • In force: 11 December 2024.
  • Vulnerability reporting obligations: 11 September 2026.
  • Full compliance required: 11 December 2027.
  • Applies to any product with digital elements placed on the EU market — hardware or software with any network or device connection.
  • LabVIEW executables, networked instruments, and measurement systems with LAN/USB/GPIB interfaces are almost certainly in scope.
What CRA requires of your dev team
  • Secure by design — no known exploitable vulnerabilities at time of release.
  • Minimal attack surface, secure default configuration.
  • SBOM — identify and document all software components (Annex I Part II(1)).
  • Technical documentation maintained for at least 10 years (Art. 13(6)).
  • Security-relevant event logging; secure update mechanism.
  • Coordinated vulnerability disclosure policy; 5-year post-release support obligation.
NIS2 Directive — Directive (EU) 2022/2555All
Network and Information Security Directive 2In force January 2023

Primary scope: essential and important entities operating critical infrastructure — energy, transport, banking, finance, health, water, ICT services.

  • Supply chain security — entities must manage cybersecurity risks in their supply chain, including software suppliers.
  • Art. 21(2)(d): supply chain measures must consider product security practices of software developers.
  • LabVIEW impact: if you supply software to NIS2-regulated operators (energy, water, transport, health, finance), they will ask for your development process documentation.
  • NIS2 pushes requirements upstream — your customers’ obligations become your obligations.
IEC 62443-4-1:2018Industrial
Secure Product Development LifecycleIEC/ISA · 2018 (under revision 2024) · EN 62443 series, harmonised under CRA

The international SDL standard for industrial / OT software — directly applicable to LabVIEW. Likely to be a presumption-of-conformity route under CRA Article 27.

  • SM — Security Management: defined, documented, version-controlled SDL.
  • SR — Security Requirements specified before coding.
  • SI — Secure Implementation: code review, static analysis.
  • SVV — Security Verification & Validation: testing, pen testing, independence.
  • DM / OM — Defect Management; release and deployment procedures.
MDR — Medical Device Regulation 2017/745Medical
EU framework for medical devices, including Software as a Medical Device (SaMD)Regulation (EU) 2017/745 · fully applicable since May 2021

Replaces the Medical Devices Directive (MDD 93/42/EEC). Software in or as a medical device — including LabVIEW-built diagnostic, monitoring, or therapy software — must comply.

  • Conformity assessment via Notified Body for most device classes (Class IIa and above).
  • References harmonised standards: IEC 62304 (lifecycle), ISO 14971 (risk management), ISO 13485 (QMS).
  • UDI (Unique Device Identifier) tracking and EUDAMED registration.
  • Post-market surveillance, vigilance reporting, and periodic safety update reports.
  • Cybersecurity requirements via Annex I (general safety + performance) and MDCG 2019-16 guidance.
IEC 62304:2006/AMD1:2015Medical
Medical Device Software — Software Lifecycle ProcessesIEC/ISO · 2006 + Amendment 1 (2015) · harmonised standard under MDR

The international standard for medical device software lifecycle. Harmonised under MDR — conformance to IEC 62304 grants presumption of conformity for the corresponding MDR essential requirements.

  • Software safety classification (Class A / B / C) drives process rigour.
  • Required documentation: software development plan, requirements, architecture, unit and integration tests.
  • Mandatory configuration management with version control.
  • Defines verification, validation, and software problem resolution processes.
  • Required for any LabVIEW software inside a medical device or used in its production.
No items in this view — try adjusting filters above.

How RAT helps you comply

Pipeline mapping · CRA Annex I & Art. 13, IEC 62443-4-1, IEC 62304
CRA Art. 13(1) — Designed, developed, produced per Annex I · IEC 62304 §5.1 / IEC 62443-4-1 SMDocumented, mandatory, reproducible development process

RAT’s immutable pipeline enforces a documented, reproducible, mandatory development process on every run. Pipeline configuration is committed to Git; init and teardown stages cannot be bypassed. This is the lifecycle evidence Art. 13(1), IEC 62443-4-1 SM, and IEC 62304’s software development plan all require.

Covered
CRA Annex I Part I(2) · IEC 62443-4-1 SI · IEC 62304 §5.5Secure default configuration & reproducible builds

rat-initializr applies a pinned VIPC on every build — a reproducible, dependency-controlled environment from day one. Combined with rat-analyzr’s mandatory VI Analyzer pass on every changed VI, this satisfies CRA Annex I Part I(2), IEC 62443-4-1 SI, and IEC 62304’s software-unit verification.

Covered
CRA Annex I Part I(7) · IEC 62443-4-1 OMAudit trail of security-relevant events

Every pipeline run produces a dated, commit-tagged artefact set — test results, analysis, documentation, build logs — stored in GitLab per release. This is the audit trail Annex I Part I(7) requires, and the OM (Operational Management) evidence under IEC 62443-4-1.

Covered
CRA Art. 13(6) · MDR Art. 10(8) technical documentationVersioned API documentation per release

rat-documentr generates HTML and PDF API documentation on every release run — a parsed view of every library, VI, DQMH module, and class in the project. Combined with GitLab artefact retention, this provides the foundation for the 10-year retention obligation under CRA Art. 13(6) and MDR’s technical-documentation requirement.

Covered
CRA Annex I Part I(1) · IEC 62443-4-1 SVV · IEC 62304 §5.6–5.7Verification before release

rat-analyzr checks all changed VIs and rat-testr runs the NI Unit Test Framework in CI; rat-validatr covers architectural checks. Penetration testing cannot be automated for LabVIEW — a manual gate step is the practical mitigation. Security-specific SAST for LabVIEW is not currently available from NI.

Partial
IEC 62443-4-1 OM — Release processAutomated build, package, deploy — every release

rat-buildr + rat-packagr + rat-deployr automate the complete build and deployment sequence. Every release follows the same documented, reproducible process. Versioned namespace deployment prevents release collisions.

Covered
No items in this view — try adjusting filters above.

What RAT does not yet cover — for your region

EU-specific gap notes · cross-link with the roadmap above

CRA and MDR apply broadly — some obligations are out of scope for any build pipeline. The roadmap section above ranks fixable items by HSE priority; the cards below list region-specific implications.

SBOM (CycloneDX / SPDX)

CRA Annex I Part II(1) · mandatory under CRA · required by MDR technical documentation

rat-documentr already parses the full LabVIEW project tree. SBOM output in CycloneDX or SPDX format is on the roadmap as an extension of the Document stage.

Roadmap

Post-release vulnerability monitoring

CRA Annex I Part II(2,3,6) · MDR post-market surveillance

RAT covers build-time only. Monitoring for newly disclosed vulnerabilities and pushing free security updates for at least 5 years post-release is an operational obligation outside RAT’s scope.

Out of scope

Coordinated Vulnerability Disclosure policy

CRA Annex I Part II(4) · organisational requirement

A published CVD policy is a process the organisation must run — not a control RAT can enforce. RAT supports it indirectly by providing the evidence trail needed to investigate disclosures.

Org policy

Secure update mechanism in built software

CRA Annex I Part I(8) · product design obligation

CRA requires the product itself to support secure updates. RAT builds the software; the update mechanism a product implements is a design choice the developer makes, not something a build pipeline can enforce.

Out of scope

EU Declaration of Conformity + CE marking

CRA Art. 28 · MDR Art. 19/20 · manufacturer obligation

Preparing the EU Declaration of Conformity and applying the CE mark under CRA or MDR is a manufacturer process. HSE consulting can guide this end-to-end alongside the RAT pipeline.

HSE consulting
No items in this view — try adjusting filters above.
Who this is for

Three teams. Three deadlines. One pipeline.

RAT is built for the LabVIEW teams whose customers are starting to ask hard compliance questions. If any of these sound like you, talk to us.

US · General

LabVIEW engineering managers preparing an SSDF attestation

You sell to a federal agency or a federal contractor. Procurement is asking for the OMB M-22-18 attestation form. Your build process is mostly manual.

  • The attestation form asks for evidence of automated tool use, build provenance, and test results — you have none of these recorded today.
  • Your VI Analyzer runs are ad-hoc; there’s no audit trail for code review.
  • Your release artefacts live on a network share with no commit traceability.
Talk to us about SSDF attestation
US · DoD / CMMC

Federal/DoD contractors on the CMMC path

CMMC Phase 1 launched in November 2025. Your DoD prime is going to require CMMC certification. SA.11, SA.15, CM.2, and CM.6 all touch your dev process.

  • SA.15 wants documented, version-controlled processes — yours live in someone’s head and a hand-written release note.
  • CM.2 / CM.6 want baseline configurations under change management — your CI YAML is hand-edited per release.
  • SA.11 wants developer security testing — you have unit tests, but no CI gate enforcing them.
Talk to us about CMMC
EU · General + Industrial + Medical

EU manufacturers approaching CRA deadlines

CRA full compliance is required by 11 December 2027. Vulnerability reporting kicks in 11 September 2026. Your LabVIEW software ships into European industrial or medical contexts.

  • SBOM is mandatory under Annex I Part II(1) — you have no inventory of what your software contains.
  • 10-year technical-documentation retention (Art. 13(6)) needs to start now — current docs are ad-hoc per release.
  • If you’re also under MDR, Notified Body reviews want IEC 62304 evidence, IEC 62443 lifecycle evidence, and harmonised-standards conformance.
Talk to us about CRA + MDR

Ready to map your compliance requirements to RAT?

Pick whichever of these is closest to where you are. We’ll work with your team and your LabVIEW project, not a generic demo.

Request a live pipeline walkthrough with your LabVIEW project Map your specific compliance frameworks against RAT’s coverage Discuss the SBOM and code-signing roadmap timeline for your delivery date
Talk to us → RAT product page