Functional safety and cybersecurity compliance
STIG is intended to support the development of mission-critical products, including systems with functional safety, cybersecurity, safety of the intended functionality (SOTIF), and artificial intelligence safety requirements. It connects specifications, engineering analyses, verification links, implementation evidence, and reports so that teams can maintain and review the engineering work supporting their compliance arguments.
STIG's current functionality is strongest in functional safety. Using the tool supports a project's compliance work; demonstrating compliance still requires the project's applicable lifecycle activities, engineering judgments, and validated evidence.
Relevant standards
The following standards frame STIG's intended application domains and development direction. Their inclusion here identifies the relevant engineering context; current feature coverage and qualification plans are described below. The links lead to the standards bodies' own descriptions.
Domain | Standard | Engineering context |
|---|---|---|
Automotive functional safety | Safety lifecycle for automotive electrical and electronic systems, including requirements, design, verification, and safety analyses. | |
Industrial functional safety | Functional safety of electrical, electronic, and programmable electronic systems and the foundation for sector-specific safety standards. | |
Military system safety | U.S. Department of Defense system-safety practice for eliminating hazards and minimizing remaining risks throughout the system lifecycle. | |
Airborne software assurance | RTCA DO-178C — Software Considerations in Airborne Systems and Equipment Certification | Development assurance for airborne software. |
Software tool qualification | Qualification of software tools for defined uses, including tools used in airborne software development and verification. | |
Automotive cybersecurity | Cybersecurity risk management throughout the lifecycle of automotive electrical and electronic systems. | |
Industrial cybersecurity | IEC 62443 — Security for industrial automation and control systems | Organizational and technical cybersecurity requirements throughout the lifecycle of industrial automation and control systems. |
Safety of the intended functionality | ISO 21448 — Road vehicles: Safety of the intended functionality | SOTIF addresses hazards caused by functional insufficiencies, including specification and performance limitations and reasonably foreseeable misuse. |
Safety and artificial intelligence | ISO/PAS 8800 — Road vehicles: Safety and artificial intelligence | Safety assurance for vehicle systems using AI, including risks from AI output insufficiencies and errors. |
Current functional safety coverage
The CREATE viewpoints organize Context, Requirements, Design, Analysis, and Tests using the typed Highway metamodel. The metamodel and its checks currently focus mainly on safety engineering at the element level:
Connected requirements, interfaces, design allocations, and verification links support traceability across the element hierarchy.
ASIL classifications and consistency checks help engineers review the allocation of safety integrity requirements.
The Analysis viewpoint records failure modes, failure propagation, safety measures, and engineering rationale.
Executable model rules identify missing information, inconsistent relationships, and other modeled engineering problems. The model-rule catalog defines the available checks and their exact scope.
Source-code analysis and generated reports connect implementation observations with the model for engineering review.
Dedicated item-level hazard analysis and risk assessment (HARA), safety-goal development, and fault tree analysis (FTA) are on the roadmap. Until those workflows are delivered, projects perform that work in their safety process and supply the resulting requirements and classifications to the element specifications. A successful model check establishes only the properties covered by its rules.
Cybersecurity, SOTIF, and AI safety roadmap
As of October 2026, the near-term roadmap calls for additional cybersecurity, SOTIF, and AI safety functionality over the coming weeks. A dedicated threat analysis and risk assessment (TARA) workflow is on the way. This includes extensions to the metamodel and checks for work associated with ISO/SAE 21434, IEC 62443, ISO 21448, and ISO/PAS 8800. These capabilities are planned additions; the current safety functionality does not establish complete coverage of those domains.
Use the release notes and the model and rule references for the installed STIG version to establish which capabilities have been delivered.
Engineering quality and assurance
STIG's architecture separates the metamodel and executable rules, the shared execution engine, and its Gradle and IDE integrations. Typed interfaces, explicit input validation, and structured results make those responsibilities easier to verify. The architecture guide describes the execution layers and their contracts.
The core toolchain and specification DSL use statically typed Kotlin compiled to JVM bytecode. Compilation checks types and references before a model is processed. The native source-code analyzer is compiled C++; report viewers also contain browser JavaScript. This design provides early feedback and supports maintainable, testable components.
Automated verification includes compiler checks, formatting and linting, static analysis, and tests at several levels:
Component and unit tests check individual rules and tool components.
Integration tests exercise interactions between components, including native analysis.
Functional and validation tests exercise consumer workflows and inspect generated reports and evidence.
The testing overview describes the suites, their coverage, and known limitations; the source-checking policy describes the automated code checks. These engineering measures provide a foundation for tool qualification. Compilation, architecture, and testing alone do not constitute qualification.
Tool qualification and certification
STIG has scheduled a safety assessment for 2027. The intended assessment scope includes support for development under ISO 26262 up to ASIL D, with defined tool use cases assessed at Tool Confidence Level 3 (TCL3), and military system-safety work under MIL-STD-882 — System Safety. Additional applicable standards and intended certificates will be specified in the assessment plan.
ASIL describes the automotive safety integrity requirements of the product being developed. TCL concerns confidence in a tool for a particular use, considering its potential impact and the measures that prevent or detect tool errors. The applicable supporting-process standard is ISO 26262-8 — Road vehicles: Functional safety, Part 8: Supporting processes. Qualification must therefore identify the STIG version, configuration, intended uses, and supporting evidence within its scope.
The scheduled assessment will evaluate the evidence supporting the intended qualification and certification claims. STIG does not currently claim completed tool qualification or certification. Each standard requires its own defined scope and evidence; MIL-STD-882 is a system-safety standard, not an ASIL or TCL level.
For use in ASIL D development with tool use cases assessed at TCL3, the following are considered STIG's top-level requirements and safety claims. They define correctness objectives to be demonstrated by qualification evidence.
For any architectural element modeled in STIG:
STIG correctly imports authoritative information from other sources, such as message catalogs and API definitions.
STIG correctly detects syntax errors in authored user specifications.
STIG correctly detects all defined rule violations in user specifications.
For software components, activities, and ROS nodes, the following additional claims apply:
STIG correctly generates metrics related to data flow within the modeled software element.
STIG correctly detects unintended cascading fault propagation from the modeled software element's inputs to its outputs.