Writing effective test cases is essential for validating embedded system functionality, catching defects early, and ensuring compliance with safety standards.

This guide provides practical guidance on writing unit tests, integration tests, and system-level test cases for embedded systems, helping you improve software quality and accelerate development cycles.

How to Write Unit Test Cases in Embedded C/C++

Unit testing in embedded C/C++ focuses on validating individual functions and modules in isolation. Effective unit test cases follow a consistent structure:

• Setup. Initializing variables and mocking dependencies.
• Execution. Calling the function under test.
• Assertion. Verifying expected outputs and side effects.
• Teardown. Cleaning up resources.

Writing comprehensive unit testing for embedded code requires addressing hardware dependencies through mocking and stubbing techniques. When testing GPIO control functions, sensor reading routines, or data processing algorithms, isolate hardware interactions to enable testing without physical devices.

Embedded software testing solutions provide specialized capabilities for handling these hardware abstractions effectively. Given that many embedded systems are safety- and security-critical, this rigorous testing must verify functional requirements and quality of service requirements such as timing, reliability, and resource usage.

Test case organization improves maintainability.

Group related test cases into test suites, use descriptive naming conventions that clearly indicate what’s being tested, and structure assertions to validate both functional correctness and edge cases. For example, when testing a temperature conversion function, create separate test cases for normal ranges, boundary values, and error conditions.

Embedded-specific challenges include memory constraints and real-time timing requirements. With that, design test cases that fit within target memory budgets and verify timing-critical operations meet deadlines.

Testing interrupt handlers and concurrent operations requires special attention to ensure thread safety and correct synchronization. Automated testing for embedded systems helps address these challenges through intelligent test generation and execution.

Can ChatGPT or Any Other LLM Write Unit Test Cases?

Large language models like ChatGPT accelerate unit test creation by generating test code, suggesting scenarios, and identifying potential edge cases. But for embedded C and C++, AI-generated tests may lack important context about hardware dependencies, real-time constraints, platform APIs, requirements, and safety or security considerations.

Generated tests still need to be reviewed and verified by engineers.

Parasoft combines established software verification capabilities with AI in embedded software testing to improve productivity while maintaining test quality through human oversight and embedded domain knowledge.

Parasoft C/C++test for automated test generation uses static analysis to identify:

• Defects
• Security vulnerabilities
• Coding standard violations

AI-assisted remediation helps developers understand findings and generate suggested fixes.

Additionally, AI-assisted unit test creation helps developers build tests and improve coverage.

For teams using existing C and C++ testing frameworks such as GoogleTest, C/C++test CT extends AI assistance to coverage analysis. AI-assisted workflows analyze coverage gaps, including MC/DC, and help identify additional test conditions needed to exercise missing paths.

Model Context Protocol (MCP) integration connects AI assistants and agents with Parasoft verification capabilities and data, providing access to project-specific analysis, testing, and coverage information.

Dig Deeper: Learn more about how MCP servers power agentic development for advanced AI-assisted testing workflows.

AI assists. It doesn’t replace the verification process.

• Static analysis identifies issues.
• Tests verify behavior.
• Coverage measures what’s been exercised.

AI helps engineers act on that evidence faster while keeping them in control of the results.

The Principles for Embedded Test Case Design

Effective embedded test case design follows fundamental principles that address the unique challenges of resource-constrained, safety-critical systems.

Key principles include:

• Designing for testability from the start.
• Maintaining separation of concerns between hardware and software.
• Ensuring test case reproducibility.
• Maintaining independence between test cases to prevent cascading failures.
• Establishing clear traceability to requirements for compliance verification.

Embedded-specific concerns shape test case design.

• Address real-time constraints by validating timing requirements and response deadlines.
• Account for resource limitations through memory usage verification and execution time measurement.
• Handle hardware dependencies through appropriate abstraction and virtualization.
• Consider safety requirements by prioritizing test coverage for critical functions and failure modes.

Build a solid foundation of numerous unit tests that validate individual functions quickly and thoroughly. Add integration tests that verify component interactions and interfaces. Top verification and validation with focused system tests that validate end-to-end behavior in realistic scenarios. This balanced approach maximizes defect detection while maintaining test execution efficiency.

Automated testing for embedded systems and software compliance testing methods help implement these principles effectively across the development life cycle.

Requirement-Based Test Case Design

Requirement-based test case design derives test cases directly from system and software requirements, ensuring comprehensive validation of specified behavior.

Analyze requirements documents to identify testable conditions, create test cases that validate each requirement, and establish bidirectional traceability between requirements and tests to demonstrate complete coverage.

Write test cases that verify both functional requirements (what the system should do) and nonfunctional requirements (performance, timing, resource usage).

For functional requirements, create positive test cases that validate expected behavior under normal conditions and negative test cases that verify proper error handling, input validation, and boundary condition management.

Requirements coverage metrics ensure thorough testing.

1. Track which requirements have corresponding test cases.
2. Identify gaps where requirements lack adequate test coverage.
3. Measure the percentage of requirements validated by passing tests.

This systematic approach reduces the risk of missing critical functionality and supports compliance with safety and security standards.

Requirements traceability solutions provide automated tracking between requirements and test cases, which is essential for regulated industries like medical, rail, energy, and others.

For aviation software, requirements-based testing for DO-178C compliance ensures complete coverage of airworthiness requirements. Similarly, requirements-based testing for ISO 26262 compliance supports automotive functional safety validation.

Boundary Value and Equivalence Class Testing

Boundary value analysis and equivalence partitioning are systematic techniques for designing efficient test cases that maximize defect detection.

Identify input boundaries (minimum values, maximum values, edge values) where defects most commonly occur, and create test cases that exercise these boundaries along with representative values from valid ranges.

Equivalence classes group similar inputs that should produce similar behavior. Select representative test cases from each equivalence class rather than exhaustively testing every possible input value. This approach provides thorough coverage while maintaining practical test execution times.

Embedded systems present specific boundary scenarios:

• Test analog-digital conversion (ADC) value ranges at minimum, maximum, and midpoint values.
• Validate pulse width modulation (PWM) duty cycle limits at 0%, 100%, and typical operating percentages.
• Verify buffer size boundaries to catch overflow conditions.
• Test timer overflow and wraparound behavior.
• Validate communication protocol frame limits for minimum and maximum packet sizes.

Apply these techniques to output verification as well. When a function produces calculated results, verify outputs at expected boundaries and confirm proper behavior when outputs approach limits. Static code analysis for boundary checking can identify potential boundary-related defects before test execution.

Code Coverage to Determine Test Case Coverage

Code coverage metrics measure test case completeness and identify gaps in testing.

• Statement coverage tracks whether each code statement executes during testing.
• Branch coverage verifies that both true and false conditions of decision points are tested.
• Path coverage ensures different execution paths through the code are validated.

Embedded systems require coverage of specialized code.

1. Write test cases that exercise interrupt handlers under various conditions.
2. Validate device drivers with different hardware states.
3. Test error handling paths and exception conditions.
4. Verify initialization sequences and startup behavior.

These often-overlooked code paths are critical for embedded system reliability.

Coverage targets vary by criticality level. Safety-critical functions may require 100% statement and branch coverage with full MC/DC (modified condition/decision coverage) for certification.

Less critical functions may accept lower coverage thresholds. Set appropriate targets based on risk assessment and regulatory requirements.

Learn more about obtaining 100% structural code coverage for safety-critical systems.

Coverage reports guide test case creation. Review uncovered code to determine whether additional test cases are needed or if unreachable defensive code can be justified.

Prioritize creating test cases for uncovered critical paths over exhaustively testing less important code. Code coverage solutions for embedded systems provide detailed analysis and reporting, while measuring code coverage metrics helps track testing progress and identify gaps.

How to Test at Different Levels Within an Embedded System

Embedded systems testing progresses through distinct levels, each with specific scope and objectives.

• Unit-level testing validates individual functions in isolation.
• Integration-level testing verifies interactions between hardware, software components, and subsystems.
• System-level testing validates complete embedded system behavior in realistic operational scenarios.

Test cases differ across levels in granularity and focus.

• Unit test cases are fine-grained, testing single functions with controlled inputs.
• Integration test cases validate interfaces and data flow between modules.
• System test cases are coarse-grained, validating complete workflows and end-to-end functionality.

The progression from unit to system testing provides layered validation.

• Early unit testing catches code-level defects when they’re easiest to fix.
• Integration testing identifies interface problems and component interaction issues.
• System testing validates requirements compliance and overall system behavior.

This staged approach improves efficiency by catching different defect types at the appropriate level.

Understanding testing methods for software compliance helps select the right testing approach for each level. Additionally, regression testing strategies ensure that changes don’t break existing functionality across all testing levels.

Unit-Level Test Cases

Unit-level test cases validate individual C/C++ functions and modules in isolation. Structure each test case with clear setup, execution, assertion, and teardown phases.

Setup initializes variables, prepares test data, and configures mocks for hardware dependencies. For embedded code that accesses GPIO pins or sensors, mock these hardware interactions to enable testing without physical devices.

Execution calls the function under test with specific inputs. Keep the execution phase focused on testing a single aspect of functionality per test case.

Assertions verify expected outputs, side effects, and state changes. Check return values, validate modified variables, and confirm that mocked functions were called correctly. Write assertions that clearly indicate what failed when tests don’t pass.

Teardown releases resources, resets global state, and ensures test isolation. Proper cleanup prevents test cases from interfering with each other. Following unit testing best practices ensures consistent, maintainable test suites.

Automated unit testing with C/C++test streamlines test case creation and execution, while code coverage analysis provides visibility into which code paths have been validated.

Integration-Level Test Cases

Integration test cases validate interactions between components in embedded systems. Focus on testing interfaces between software modules, hardware-software integration points, communication protocols, and subsystem interactions.

Design test cases that verify data flow across component boundaries. Validate that data passed between modules maintains integrity and correct format. Test API usage to ensure components use interfaces correctly and handle return values properly.

Timing and synchronization are critical in embedded integration testing. Verify that components synchronize correctly, especially in multi-threaded or interrupt-driven architectures. Test message passing and event handling between components to ensure proper sequencing.

Error propagation deserves special attention. Verify that errors detected in one component properly propagate to dependent components and that systems handle error conditions gracefully without cascading failures. Using stubs in integration testing helps isolate components and simulate various integration scenarios.

For regulated industries, specific integration testing approaches are essential. Integration testing for DO-178C addresses aviation software requirements, while integration testing for ISO 26262 ensures automotive functional safety compliance.

System-Level Test Cases

System-level test cases validate complete embedded system behavior in simulated or realistic operational scenarios. Design comprehensive test cases that verify system-level requirements, validate use cases and user scenarios, and confirm end-to-end functionality.
Complete workflow testing validates entire sequences. Test startup procedures from power-on through initialization to operational state. Verify normal operations under typical use conditions. Validate shutdown and power management sequences.

System-level performance requirements need thorough validation:

• Measure and verify response times meet specifications.
• Test throughput under realistic load conditions.
• Monitor resource utilization (CPU, memory, bandwidth) to ensure the system operates within constraints.

Safety-critical scenarios require careful test case design. Validate fault detection mechanisms trigger correctly. Test error recovery procedures restore system functionality. Verify failsafe behaviors activate when critical failures occur. Confirm watchdog timers and health monitoring function properly.

Integrating system-level testing into continuous delivery pipelines accelerates feedback. CI/CD test automation for embedded systems enables frequent validation, while implementing QA in CI/CD pipelines ensures quality gates catch issues before deployment. Ensuring requirements traceability from system tests back to requirements demonstrates complete validation coverage.

Get Started With Writing Test Cases for Embedded Systems Using Parasoft

Effective test case development is fundamental to embedded systems quality. This guide covered writing unit test cases in embedded C/C++, principles of effective test case design (requirement-based, boundary value, equivalence class, and coverage-driven approaches), and strategies for writing test cases at different levels (unit, integration, and system testing).

Parasoft provides comprehensive solutions for embedded test case development and execution. Parasoft C/C++test offers automated test generation, unit testing, and code coverage analysis specifically designed for embedded C/C++ applications to help teams:

• Identify defects and security vulnerabilities early with static analysis.
• Enforce coding standards like CERT C/C++ and MISRA C/C++.
• Create and execute unit tests and measure structural code coverage.
• Maintain traceability between requirements, tests, results, and code.
• Integrate verification into developer and CI/CD workflows.

AI adds another layer of automation to established verification capabilities, from assisted remediation and unit test creation to coverage analysis and MCP integration.

However, static analysis, test execution, coverage analysis, and requirements traceability remain the objective foundation of verification. AI helps engineers act on those results faster without replacing the verification process itself.

Parasoft’s embedded testing solutions support the complete testing life cycle from static analysis and test case creation through execution, code coverage, requirements traceability, and reporting.

Automated testing solutions help teams reduce repetitive manual work, improve coverage, and deliver reliable embedded systems with confidence.

Request a Demo

Originally published at https://www.parasoft.com on October 1, 2026.

How to Write Effective Test Cases for Embedded Systems was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

Medical device software failures can have devastating consequences, from insulin pump malfunctions to pacemaker timing errors that directly threaten patient lives.

As embedded systems become increasingly complex in medical devices, rigorous automated testing has evolved from best practice to a de facto regulatory expectation for managing complexity, risk, and compliance evidence.

With software-related issues driving a significant percentage of medical device recalls, organizations developing life-saving technologies face mounting pressure to deliver highly reliable embedded software with demonstrable risk control while navigating stringent FDA and IEC 62304 compliance requirements.

This guide examines the critical role of embedded software testing in medical device development, explores the unique challenges of testing resource-constrained systems with real-time requirements, and provides actionable strategies for implementing comprehensive testing approaches that protect patients while accelerating time to market.

Parasoft’s embedded software testing solutions address the full spectrum of testing challenges in resource-constrained environments, while specialized medical device software testing and validation capabilities ensure compliance with FDA expectations and IEC 62304 requirements.

What Is Embedded Software Testing?

Embedded software testing validates firmware running on dedicated hardware with limited resources and strict real-time requirements. Unlike general software testing, embedded testing must account for:

• Severe resource constraints (memory, processing power, physical size)
• Hardware dependencies including sensors and actuators
• Timing criticality where microsecond delays can prove fatal
• Debugging difficulty without traditional development tools
• Medical devices exemplify these challenges perfectly.

Embedded systems operate within strict physical, power, and timing constraints that distinguish them from conventional software environments. Testing must validate:

• Implantable neurostimulator pulse algorithms that deliver therapy with microsecond precision
• Medical imaging system reconstructions that require flawless mathematical accuracy across all operational modes
• Anesthesia delivery control systems that respond instantly to dynamic patient parameters

The specialized nature of these environments demands testing approaches specifically designed for hardware-dependent code, real-time operating systems, and resource-limited platforms.

A comprehensive guide to automated testing for embedded systems provides the foundational knowledge teams need to implement effective validation strategies that address these unique constraints while maintaining development velocity.

Why Are Embedded Systems in Medical Devices Important?

Embedded systems in medical devices carry unique importance across three critical dimensions.

1. Patient Safety

Patient safety represents the paramount concern. Software defects in medical devices create direct life-or-death scenarios. Real-world recalls illustrate this reality.

• Medtronic insulin pumps experiencing dosage calculation errors.
• St. Jude pacemakers vulnerable to cybersecurity exploits.
• Numerous other cases where embedded software failures endangered patients.

A single coding error can cascade into catastrophic outcomes when embedded systems control drug delivery, cardiac rhythm, or respiratory support.

2. Regulatory Compliance

Regulatory compliance demands comprehensive validation. The FDA requires documentation verification and validation evidence for 510(k) clearance and PMA approval. IEC 62304 classifies medical device software into Class A, B, or C based on risk levels, with Class C devices (highest risk) requiring the most extensive testing and documentation.

Understanding how to streamline IEC 62304 compliance through automated testing and traceability tools dramatically reduces the documentation burden while ensuring all regulatory requirements are met.

Organizations must implement systematic risk management throughout the device life cycle using ISO 14971 as the primary management framework with IEC 62304 -linking software safety classification to testing rigor. ISO 14971 mandates this risk-based approach, while FDA cybersecurity guidance now requires manufacturers to address security vulnerabilities proactively throughout the product life cycle.

3. Business Impact

Business impact extends beyond immediate patient safety to organizational viability.

• Recall costs frequently exceed millions in direct expenses, legal liability, and remediation efforts.
• Lawsuits from device failures create devastating financial and reputational damage.
• Time-to-market delays compound costs as competitive advantages erode.
• Reputation damage proves difficult to quantify but affects market position for years following high-profile failures.

What Are the Types of Embedded Systems in Medical Devices?

Medical devices employ different embedded system types, each presenting distinct testing challenges and regulatory classifications. Modern devices often integrate multiple functions, combining monitoring, diagnostic, and therapeutic capabilities in increasingly sophisticated ways.

Monitoring Embedded Systems

Monitoring systems continuously collect and display physiological data, typically classified as FDA Class II or III devices. Examples include pulse oximeters measuring blood oxygen saturation, ECG monitors tracking cardiac electrical activity, continuous glucose monitors (CGMs) providing real-time blood sugar readings, ICU patient monitoring systems integrating multiple vital signs, and blood pressure monitors.

Testing focuses on:

Key challenges include:

• Electromagnetic interference (EMI) and radio frequency interference (RFI) can corrupt sensor readings.
• Motion artifacts that introduce noise into measurements.
• Real-time sampling requirements that demand precise timing.
• Compliance with IEC 60601–1–8 alarm standards that specify alarm signals and priorities.

Diagnostic Embedded Systems

Diagnostic systems analyze physiological data to inform clinical decisions with accuracy. This is paramount because misdiagnosis directly harms patients. Examples include:

• MRI and CT scanners that generate detailed anatomical images.
• Clinical laboratory analyzers that process blood and tissue samples.
• AI-powered diagnostic tools that identify patterns in medical images.
• Digital pathology systems that analyze tissue samples.
• Cardiac stress test systems that evaluate heart function under exercise conditions.

Testing emphasizes algorithm validation against large, validated datasets representing diverse patient populations, sensitivity and specificity metrics to quantify diagnostic accuracy, edge case handling for unusual presentations, calibration procedures ensuring measurement accuracy, clinical validation studies demonstrating real-world effectiveness, and AI/ML model testing following FDA software as a medical device (SaMD) guidance.

AI diagnostic systems require particularly rigorous validation, including diverse training datasets representing different demographics, continuous monitoring for model drift as data distributions change, and explainability mechanisms allowing clinicians to understand diagnostic reasoning.

Both compile-time and runtime validation prove essential for medical device software quality. Implementing static and dynamic analysis best practices in medical software ensures comprehensive defect detection at every development stage, catching coding standard violations, security vulnerabilities, and potential runtime errors before they reach patients.

Challenges include:

• AI model validation with sufficient statistical power
• Result reproducibility across different devices and operators
• Large dataset management for training and validation

Therapeutic & Control Embedded Systems

Therapeutic and control systems represent the highest-risk category, directly delivering treatment or controlling critical physiological functions. Typically classified as FDA Class III and IEC 62304 Class C devices, failures result in immediate patient harm or death. Examples include:

• Implantable neurostimulators for deep brain stimulation or pain management.
• Automated external defibrillators (AEDs) that analyze and treat cardiac arrhythmias.
• Heart-lung bypass machines controlling oxygenation and circulation during surgery.
• Surgical robots performing precise movements during procedures.
• Radiation therapy systems delivering targeted cancer treatment.
• Anesthesia workstations that continuously monitor and adjust gas delivery.

Testing focuses on:

• Real-time control algorithm validation under all operating conditions
• Failsafe mechanism verification ensuring safe states during malfunctions
• Fault detection capabilities identifying hardware and software errors
• Boundary condition testing at maximum and minimum dosages or rates
• Timing precision verification measuring response times
• Hardware-in-the-loop (HIL) testing with actual hardware components
• Safety interlock validation preventing dangerous operating conditions
• Battery management for implantable devices
• Cybersecurity validation protecting against unauthorized access

The Therac-25 radiation therapy accidents serve as historical reminders of catastrophic embedded software failures, where software race conditions led to massive radiation overdoses and patient deaths. Modern therapeutic devices must demonstrate reliability of 10 years or more for implantable systems, undergo extensive physiological simulation to model patient responses, and meet the highest testing standards. Testing challenges include:

• Validating implantable devices without patient risk.
• Ensuring reliability over extended operational lifetimes.
• Accurately simulating complex physiological responses to therapy.

Best Practices for Testing Embedded Systems in Medical Devices

Effective medical device testing balances thoroughness, efficiency, and regulatory compliance. Best practices emerge from FDA guidance, IEC 62304 and ISO 14971 standards, and industry lessons learned from both successes and failures.

Use a Risk-Driven Testing Approach (ISO 14971)

ISO 14971 mandates risk-based testing prioritization that focuses resources on the most critical safety concerns. The process involves:

• Identifying potential hazards through failure mode analysis and hazard analysis.
• Estimating risk by calculating probability × severity for each identified hazard.
• Determining IEC 62304 software safety class (A, B, or C) based on risk assessment.
• Defining testing rigor accordingly.

For example, drug dosage calculation algorithms typically warrant Class C classification, requiring 100% code coverage, extensive boundary condition testing, and rigorous validation.

Conversely, noncritical user interface elements may receive Class A designation with basic functional validation sufficient. Risk-driven approaches ensure testing efforts align with actual patient safety impact rather than treating all code equally.

Traceability from identified risks through requirements to test cases provides auditable evidence that all hazards receive appropriate mitigation. Risk matrices visually communicate priorities, helping teams allocate testing resources effectively.

Use a Security-Driven Testing Approach (ISO/AWI 81001–5)

ISO/AWI 81001–5–2 addresses requirements and guidance for managing security risks throughout the life cycle of medical devices and health IT systems, specifically from design through production and into post-production, within a risk-management framework aligned with ISO 14971 (the medical device risk management standard).

Security testing serves as verification of implemented security risk controls rather than a standalone activity, ensuring that identified threats and vulnerabilities are effectively mitigated throughout the product lifecycle.

Here’s the process:

1. Identify assets, threats, vulnerabilities, and related risks.
2. Estimate and evaluate security risk levels.
3. Select, implement, verify, and monitor security risk controls.
4. Integrate security processes into design, production, and post-production activities.
5. Coordinate with healthcare delivery organizations (HDOs) on risks and vulnerability disclosure/patching.
6. Establish enterprise-wide processes for post-production security interactions.

For example, an embedded infusion pump that administers medication based on programmed parameters and exchanges data with hospital information systems presents a significant security risk due to its direct impact on patient safety and its network connectivity. Security risk management must address threats such as unauthorized access, manipulation of dosage parameters, and compromise of firmware integrity through controls including authentication, data integrity checks, secure communications, and controlled update mechanisms.

In contrast, a standalone embedded medical module with no external interfaces may present a reduced attack surface but still requires proportionate security controls based on intended use and potential harm. Identified security risks should be traceable to specific security requirements and verified through validation activities, ensuring comprehensive coverage of all relevant assets, attack surfaces, and threat scenarios.

Ensure Complete Requirements Traceability (IEC 62304)

IEC 62304 mandates bidirectional traceability, establishing clear relationships:

system requirements ↔ software requirements ↔ design ↔ code ↔ test cases ↔ test results

This traceability:

• Proves complete coverage for regulatory audits.
• Enables impact analysis when requirements change.
• Satisfies rigorous regulatory scrutiny.

Manual traceability maintenance becomes impractical as medical device software grows in complexity, with thousands of requirements, design elements, code modules, and test cases requiring linkage.

Automated traceability solutions eliminate manual overhead while providing real-time visibility into coverage gaps, impact analysis for change requests, and audit-ready documentation that connects every line of safety-critical code back to its originating requirement and forward to its validation evidence.

Implementation requires traceability matrices or application lifecycle management (ALM) tools that maintain these linkages automatically, reducing the burden on development teams while ensuring no requirement goes untested.

Common gaps include orphaned requirements without associated tests, test cases lacking requirement links making their purpose unclear, and outdated traces following requirement changes. Regular traceability audits identify and resolve these inconsistencies before they become compliance issues during regulatory submissions.

Test Hardware-Software Integration Early

Testing software with actual hardware or high-fidelity simulators early in development proves critical for embedded medical devices. Issues surface during integration that cannot be detected in isolation:

• Timing problems where operations miss critical deadlines.
• Interrupt handling errors causing system instability.
• Hardware interface mismatches preventing proper sensor readings.
• Memory constraint violations leading to crashes.
• Power consumption exceeding specifications.
• Sensor calibration discrepancies affecting measurement accuracy.

Hardware-in-the-loop (HIL) testing, early development boards, and hardware simulators enable a shift-left testing philosophy, which doesn’t wait for final hardware availability.

For example, simulation might indicate software passes all functional requirements, but actual hardware reveals timing issues causing ventilator alarm delays of several hundred milliseconds, potentially fatal for critically ill patients.

Validate Reliability Through Real-World & Fault Conditions

Testing beyond “happy path” scenarios ensures devices perform reliably under adverse conditions patients will inevitably encounter. Real-world conditions include temperature extremes (storage and operating ranges), humidity exposure, electromagnetic interference from hospital equipment, low battery operation, network interruptions disrupting connectivity, sensor failures, and user errors including incorrect operation.

Testing approaches include:

• Environmental testing in climate chambers and EMI/RFI chambers
• Fault injection simulating sensor failures, memory errors, and communication disruptions
• Long-duration testing running continuously for days or weeks to detect intermittent issues
• Stress testing with boundary conditions at physiological extremes

Fault handling proves as critical as normal operation. Devices must detect failures, enter safe states, alert users appropriately, and maintain patient safety despite component malfunctions.

For example, insulin pumps must reliably detect occluded infusion lines that prevent drug delivery and trigger appropriate alarms, preventing dangerous hypoglycemia from missed doses.

Verify Safety-Critical Behavior

Medical device software must reliably perform critical functions under all conditions. Testing approaches include:

• Validating fault detection and handling mechanisms.
• Verifying failure mode responses including graceful degradation.
• Testing alarm functionality for appropriate triggers and escalation.
• Confirming error recovery procedures.
• Validating system state management across transitions.
• Ensuring critical path validation for life-safety functions.

Tools such as fault injection frameworks, failure mode simulators, and state machine analyzers systematically verify safety-critical behavior. For example, pacemakers must maintain safe backup pacing mode if primary sensing fails, and infusion pumps must trigger appropriate alarms when detecting occlusions or air bubbles in fluid lines.

Regulatory standards expect strong objective evidence of structural coverage structural coverage metrics for safety-critical medical device software with IEC 62304 Class C devices typically requiring 100% statement, branch and modified condition/decision coverage as minimum thresholds.

Organizations must achieve required code coverage targets. Using automated tools, systematic unit and integration testing objectively measure which code paths were exercised during validation. The resulting coverage metrics provide quantifiable evidence that all safety-critical functionality has been tested, identifying untested code that could harbor latent defects.

How AI Is Changing Medical Device Software Verification

AI is changing medical device development in two important ways.

1. As part of the device itself, such as an algorithm used for diagnostic or clinical decision support.
2. It helps engineering teams develop and verify the embedded software surrounding those functions.

Static analysis remains an important first line of verification for C and C++ medical device software. Parasoft C/C++test analyzes code without executing it to identify defects, security vulnerabilities, and coding standard violations.

AI-assisted remediation builds on those deterministic analysis results, helping developers understand identified findings and generate suggested fixes.

In short, the static analysis identifies the issue, and AI helps developers act on it faster.

AI accelerates testing. C/C++test supports AI-assisted unit test creation, which helps expand tests and improve coverage. For teams using existing C and C++ testing frameworks like GoogleTest, C/C++test CT uses AI-assisted workflows to analyze coverage gaps, including MC/DC coverage, and identify additional test conditions needed to exercise missing paths.

For medical device software, creating tests and remediating issues faster isn’t enough. Teams still need objective evidence demonstrating that:

• Requirements have been implemented.
• Risk controls have been verified.
• Required testing has been performed
• Appropriate coverage has been achieved.

Traceability, static analysis results, test results, coverage data, and compliance reporting remain essential parts of the verification record.

AI adds another layer of automation to the verification workflow rather than replacing established engineering practices. It helps engineers move from finding an issue to understanding and addressing it and from identifying a coverage gap to developing the tests needed to close it. Engineers remain responsible for reviewing the results and establishing the evidence needed for medical device software assurance.

Get Started With Embedded Software Testing Using Parasoft

Embedded medical device testing presents unique challenges balancing patient safety, regulatory compliance, and development efficiency. Specialized testing approaches address resource constraints, real-time requirements, and hardware-software integration complexities while meeting stringent FDA and IEC 62304 standards.

Parasoft provides integrated automated testing solutions specifically designed for embedded medical device development. Static analysis, dynamic testing, and structural coverage capabilities work together to identify defects across the development life cycle.

Parasoft C/C++test delivers comprehensive analysis for embedded C/C++ applications. It identifies security vulnerabilities and safety defects early in development while supporting compliance with standards including CERT C/C++, MISRA C/C++, and IEC 62304. The unified toolset eliminates gaps between different testing phases, providing consistent quality enforcement from initial coding through final validation.

Organizations developing medical devices face complex regulatory requirements spanning functional safety, cybersecurity, and quality management standards. Parasoft’s compliance testing solutions support safety and security standards across the medical device life cycle, including IEC 62304, ISO 14971, ISO 81001–5–1 and ISO 81001–5–2, and FDA guidance with automated traceability connecting requirements through implementation to test results.

This comprehensive approach provides auditable evidence for certification submissions, dramatically reducing the documentation burden while ensuring all regulatory obligations are met.

Parasoft SOAtest automates API testing, moving beyond unit and component-level checks. It validates the security of communication channels and data exchanges between embedded system components and connected enterprise or cloud services, which are common attack vectors in modern medical devices with network connectivity.

Request a Demo

Originally published at https://www.parasoft.com on September 30, 2026.

Embedded Software Testing for Medical Devices was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

So let’s take a look at what testing actually does for you and what it doesn’t, because I think the confusion does real damage. Don’t misunderstand me, I’m not saying testing isn’t important. It’s critical, and if you’re not doing enough of it you should go do more. I’m saying that a test, by itself, doesn’t fix anything. It tells you that you have a problem, and that’s all it does.

The light on the dash

Everybody reaches for the doctor analogy here, but I think your car works better, because a car has a whole range of testing built into it.

Low tire pressure is a real problem. The car handles worse, takes longer to stop, and you’re a lot more likely to end up with a blowout. The US government took it seriously enough to pass a law about it. In August 2000 Firestone recalled 6.5 million tires, mostly ones fitted to Ford Explorers, because the treads were peeling off, and a big part of the fight in the congressional hearings that followed was over tire pressure ( Ford told Explorer owners 26 psi, Firestone said 30). Congress passed the TREAD Act that November, and NHTSA eventually required a tire pressure monitoring system on every new light vehicle starting in September 2007.

So think about how tire pressure gets tested over the life of a car. When you bought it, the dealer probably went around with a gauge and made sure all four tires were right. That’s a one-time test, and it’s not nearly enough, because tires leak.

You could do better by checking the pressure every time you stop for gas, which is the equivalent of running your tests on every build. I don’t do that. You know I don’t do that, so I’m not even going to pretend I do. My dad, maybe, but not me. It’s a good idea and you should do it.

And if your car is newer than about 2007, there’s a sensor watching the pressure all the time, with a light on the dash that comes on when it’s low. How much that light tells you depends on the car. Some of them show you the actual pressure in every tire, and some are so simple they don’t even say which tire is low, so you get to walk around the car and find out for yourself (and it’s always the last one you check). So we’ve gone from one-time testing to scheduled testing to continuous testing, which is pretty much the path software has taken over the last twenty years, and everybody feels very modern about it.

Now you’re driving down the road, the car feels a little squirrely, maybe you notice and maybe you don’t, and the light comes on. Low tire pressure. Great, the test worked. If tests are medicine, you’re done, because the light came on and the problem is handled, so keep driving.

Nope, it doesn’t work that way. You have to pull over and put air in the tire, or put on the spare, or get it to someone who can patch it. The sensor finished its entire job the moment the light came on, and the tire is exactly as low as it was a second earlier.

That’s the point. Tests detect problems and let you know they’re there, and they don’t do a single thing about them. Somebody still has to.

(And yes, I know people who have driven around for months with that light on. That’s a different problem, and it deserves an article of its own.)

A green light tells you less than you think

The sensor also only knows what it was built to know. The federal standard says the light has to come on when a tire is 25 percent or more below the recommended pressure. So when the light is off, you don’t actually know your tires are fine. You know none of them is a quarter low. And the simple system that just says “a tire” gives you a lot less to work with than the one showing all four pressures, even though both meet the same federal rule. The tire sensor also won’t say a word about your oil, because that’s a different sensor. Every test tells you something different, and only the thing it was built to tell you.

Dijkstra said it better than anybody, back around 1970: “ Program testing can be used to show the presence of bugs, but never to show their absence! “ When your suite runs green, you don’t know the application is good. You know it isn’t bad in the particular ways you thought to check.

“But my tests do make the code better”

To be fair to the other side, there are smarter versions of the “tests are medicine” argument than the one I ran into on Twitter, and they deserve an answer.

If you do test-driven development, you’ll tell me that writing the test first changes the code, because having to make something testable pushes you toward a better design. I agree that happens. But look at what’s doing the work. It’s the thinking you had to do about what the code is supposed to do and how you’d know if it did, and the test is where you wrote that thinking down. The design got better because you thought harder, and the test is the receipt.

You’ll also say that regression tests keep old bugs from coming back, and that sure sounds preventive. It’s still a detector, though, just one pointed at last year’s mistake. If somebody reintroduces that bug, the regression test doesn’t stop them from writing it. It turns on the light, and somebody still has to go fix it.

Then there’s the newest version. Hook an agent up to your test suite, and when a test fails the agent patches the code and reruns until everything’s green. Test and fix in one loop, so isn’t that medicine? I’d say it proves my point. Something other than the test did the fixing, and the agent only knows what “fixed” means because the test told it. If the test checks the wrong thing, the agent will keep changing your code until the wrong thing passes. It’s like the mechanic who keeps swapping parts until the check engine light goes off (in the trade they call that firing the parts cannon). Eventually the light does go off, and you’re left with a big bill, a car full of new parts, and no idea whether the thing that was actually wrong ever got fixed.

Where this actually hurts

Why does any of this matter beyond winning an argument on the internet? Because the medicine mentality is how people end up believing that if they just do enough testing, their software will be safe and secure and reliable. And it won’t be.

Security is where I see this the worst. Teams treat pen testing and DAST and fuzzing as if they take the place of building secure code. They don’t take the place of anything. They tell you the software has problems, which is valuable and necessary, and then somebody has to fix those problems, and ideally figure out why they keep showing up.

Go find the nail

Manufacturing figured this out a long time ago. Harold Dodge, who helped invent statistical quality control at Bell Labs, put it as “You can not inspect quality into a product.” Deming spent decades hammering the same idea into American industry: “ Inspection is too late. The quality, good or bad, is already in the product. “ Swap “test” for “inspect” and you’ve got this whole article, about forty years late.

So what do you do when the light comes on? Three things, in order.

1. Fix what it found. In the code, not in the test (unless the light wasn’t supposed to come on in the first place, but again, that’s a different article). Adjusting the test until it goes quiet is the software version of putting a piece of tape over the dash light. (I hope you aren’t doing this.)
2. Ask why it happened. If the same tire keeps going low, at some point you stop topping it up and go find the nail.
3. Change how you build so that kind of problem is hard to create in the first place. Coding standards, static analysis, memory-safe languages, design reviews, whatever closes off that class of mistake before it ever reaches a test.

Now, I’m not saying prevention is free. Tire makers have been working on airless tires for years (Michelin’s prototype is called Uptis), and you can see the appeal, because a tire with no air in it can’t go flat. But they’re harder to make, they’re going to cost more, and from what’s been reported so far they ride stiffer, pass along more road noise, and have a harder time getting rid of heat at highway speeds. So you weigh the chance of a flat against all of that, and for most of us today the answer is still a regular tire and a pressure sensor. Software works the same way. Every one of those prevention techniques costs something, whether it’s tooling, training, slower builds, or rewriting code in a new language, so look at the risk, the benefit, and the cost, and spend where it pays off. For a pacemaker or a flight controller, that math comes out very differently than it does for your marketing site.

Memory-safe languages are the airless tire of software, and the tradeoffs look a lot alike. The upside is huge. The Chromium team says around 70% of their high-severity security bugs are memory safety problems, and Microsoft has reported about the same for the vulnerabilities in its own products. That won’t be true of everybody’s code, but it shows you how much is on the table. In a language like Rust the compiler stops most of that class of mistake at build time, before there’s anything to test. That’s prevention in its purest form. But it isn’t free either. Somebody has to rewrite or wrap a lot of existing C and C++, your team has to learn a new language, the tooling and certification story for safety-critical work is still catching up, and the moment you call into old C code (or use the unsafe keyword), some of the guarantee goes out the window. And it does nothing at all for logic bugs, so you still need the sensors. Whether it's worth it for your code is exactly the risk, benefit, and cost question, and that's a story for another day.

And then keep testing, because you still need to know when something gets through. Keep the sensors, and keep checking your tires at the gas station if you’re more virtuous than I am. Just don’t confuse the light on the dash with air in the tire.

Originally published at https://codecurmudgeon.com on October 8, 2026.

Tests Aren’t Medicine was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

The fish will die

Picture the meeting where somebody designs an internet-connected thermometer for a fish tank. Someone asks what the risk is, and the answer is pretty simple: if this thing fails, the fish die. So you put a warning on the box (we’re in California, so there’s going to be a warning on the box anyway), you change “may die” to “will die” so legal is happy, and you’re done. Attack surface considered, liability covered, ship it.

And honestly, if you’d walked up to your IT team and said “I want to put a thermometer on the network so I can make sure the fish don’t die,” a lot of them would have said yes. You won’t admit it now, but you might have.

In 2017 the security firm Darktrace described an incident at a North American casino where attackers got in through exactly that kind of fish tank. The tank had sensors connected to a PC that handled temperature, feeding and cleaning, and according to Darktrace, somebody got into the fish tank, used it to move around into other parts of the network, and sent data out. The next year Darktrace’s CEO told the story at a Wall Street Journal conference in London with the detail that makes it hurt: what went out through the thermometer was the casino’s high-roller database. (The casino has never been named, and everything we know comes from Darktrace, which sells the kind of monitoring that caught it, so take the details with the appropriate grain of salt.)

So if you’re a high roller, think about the fact that the casino has your data and not just your money, and the data may be worth more than whatever you left on the table. The part that still gets me is that the data went out through the thermometer. A thermometer should send a tiny bit of data, on a schedule, to one place. According to Darktrace’s 2017 threat report, this one sent about 10GB to a device in Finland, over a protocol normally used for audio and video, and that’s exactly what gave it away. Their monitoring flagged the fish tank because it was suddenly moving unusual amounts of data to a destination it had never talked to before. Nobody had thought of the thermometer as a security problem, but its traffic made the problem obvious to anyone who was watching.

Jumping the goldfish

I told a version of that story in 2018 at Cybersecure LA, a conference where local business leaders work with Pepperdine and government security people. I called the talk “jumping the goldfish,” and I opened by putting a slide full of devices up and asking which of them had been hacked. The answer was all of the above. At the time I kept a running list called the IoT Hall of Shame, and I couldn’t keep up with it, because it was a daily thing. (It’s not current anymore. Keeping up turned out to be a full-time job, and I already have one.)

The question I heard over and over back then was “why does it matter? It’s just a stupid little light bulb.” And that’s the problem, because the risk analysis for these things almost always asks what the device can do. A light bulb can turn a light off. A thermometer can report the wrong temperature. Who cares? The better question is what the device can reach, and a thermometer on the casino network can reach the casino network.

Eight years on, some of those stories have aged, some of my predictions came true, and a few details needed fixing, which is what happens when you fact-check something you said live with a microphone in your hand. So here are a few of the stories across different markets, the tactics they have in common, and what to do about it, both if you build these things and if you buy them.

Who cares about my X-ray?

A family member used to work for a company that did red team work (they attacked people for money, and for a while it ran in the family). We got talking about hospitals once, and the way it was described to me, hospitals think about security like a castle. The bad guys are outside the walls trying to figure out how to get in.

Around the same time my dad had a heart attack, and I walked into his room and counted four devices with USB ports on them. How often is a nurse in that room? Could somebody get a few minutes alone with one of those devices? Absolutely. I work with the safety-critical software industry, which includes medical device makers, so I knew enough about the infusion pump brands to have an opinion. When the nurse asked what I was doing poking at the pump, I told her that if it had been a particular other brand I’d have asked her to take it out of the room. (I’m not going to tell you which one.)

The pumps were what I worried about, because they’re right there with the patient and a bad dose is obviously a safety problem. But the data from the time said I was worrying about the wrong box. A 2018 report from ZingBox, a security vendor focused on connected devices, looked at tens of thousands of devices across more than 50 hospitals and found that imaging systems made up 19 percent of the connected medical devices but accounted for 51 percent of the security issues, while infusion pumps accounted for about 2 percent. Imaging machines run lots of network applications, they’re often built on commercial operating systems, and they tend to outlive their support agreements. Nobody thinks of the X-ray machine as the dangerous one. Someone gets a copy of my X-ray, who cares?

Here’s why you should care anyway, and it has nothing to do with somebody seeing your X-ray. Put a commercial operating system together with a support agreement that ran out years ago, and a lot of those imaging machines are really just old, unpatched Windows PCs with a very expensive peripheral attached. Nobody has to target them. When WannaCry hit in May 2017, it was a worm looking for unpatched Windows anywhere it could find it, and inside hospitals it found plenty, including the imaging gear. The UK’s National Audit Office found that at least 81 of the 236 hospital trusts in England’s National Health Service were affected and an estimated 19,000 appointments were cancelled, and besides the office computers it locked up equipment like MRI scanners and machines for testing blood and tissue samples. The scanners weren’t the target, they were collateral damage, and that’s worse, because it means a device can take a hospital down without anyone ever thinking about it at all. Castle walls are great at keeping out the big things, like armies and wolves and the neighbor’s dog. They don’t do a thing about cockroaches. Cockroaches are small and nasty, they get in through cracks nobody is watching, and once they’re in, they’re everywhere. WannaCry was a cockroach infestation, and those old imaging machines were the cracks. (The Audit Office also noted that the device vendors often weren’t much help with the extermination.) They also got lucky, because a researcher found a kill switch that stopped it from spreading further.

And my worry about the pumps? It didn’t go away, it just took a while. In 2022, researchers at Palo Alto Networks (who, as it happens, bought ZingBox) looked at 200,000 network-connected infusion pumps and found that 75 percent of them had known security issues. More than half of them were exposed to the same pair of 2019 flaws in VxWorks, an operating system used in a huge number of embedded devices, and one of the two was a buffer overflow. Remember that when we get to the part about how we build software.

The tricks are older than the devices

The devices change every year, but the ways in keep repeating. Here are the ones that show up over and over in these stories.

Chatty devices that trust everybody

When I gave the talk I asked how many people in the room had Philips Hue bulbs, and a good quarter of them did. Fewer had ever updated the software inside them. Smart bulbs talk to each other, and in 2017 a group of researchers showed they could put malicious software on a Hue bulb and have it spread to neighboring bulbs, and not just the ones in your house but the ones in your neighbor’s house too, because the bulbs didn’t do much to check who they were talking to. I could pretend to be a bulb and the others would listen to me. Philips fixed the spreading problem, but you could still take over an individual bulb.

Then in 2020 Check Point took the next step and went after the Hue bridge. That’s the little hub plugged into your router that the bulbs in your house talk to (or at least are supposed to talk to, instead of chatting over the fence with the neighbor’s bulbs). They took over a bulb, made it act glitchy so the owner would remove it from the app and then pair it all over again, and when the bridge found it again the bulb hit the bridge with one of the oldest tricks in the book, a heap-based buffer overflow (publicly catalogued as CVE-2020–6007, the ID number known vulnerabilities get), and used it to install malware on the bridge.

If nobody’s ever explained a buffer overflow to you, think of pouring a 16-ounce drink into a 12-ounce cup. The program set aside room for a certain amount of data, the bulb sent more than that, and nothing checked. With a real cup, the extra just makes a mess on the table. In a computer, the extra spills into the memory next door, and if the attacker gets to choose what spills over, they can get the program to run their instructions instead of its own. (The “heap” part just tells you which area of memory the cup was sitting in.) This isn’t some exotic new technique. Writing past the end of a buffer has been one of the most common software weaknesses for decades, and it’s not going away. About a quarter of MITRE’s 2025 Top 25 list of the most dangerous software weaknesses is buffer overflows and their memory-handling cousins.

Back to the light bulb. Once they owned the bridge, they were on your home or office network, so from there they went after the computers using EternalBlue, the same exploit WannaCry used. A light bulb took over your network. Newer bulbs don’t have the problem, but if you’ve got old ones, update them, and if they’re too old to update, throw them away. I’m serious about that.

Devices should be seen and not heard. I don’t mean a light that says “welcome home” when you walk in. I mean how much it talks on the network: how many conversations it has, with whom, and how often. A light bulb really only needs to hear “on” and “off” from one controller. Plenty of devices do a lot more than that. They announce themselves to everything on the network, answer anybody who asks, listen for connections nobody uses, and check in with servers out on the internet. Chatter inside your network means that if anything else on it gets compromised, it can easily find your device and talk to it. Chatter outside your network, heaven forbid, means your device is regularly sending data out of the building to somebody else’s servers, and if that’s normal for it, a little extra data going out is much harder to notice. The more a thing talks, and the less it checks who it’s talking to, the more ways there are in.

And for the people who think an unusual wireless protocol is protection (the radio signals your bulbs, sensors and gadgets use to talk to each other without wires): security through obscurity doesn’t work, and radio isn’t even obscurity. People have been listening in on radio for as long as there’s been radio, and today an inexpensive receiver plugged into a laptop will do it. You can hide a wire inside a wall, but a radio signal goes right through the wall and out into the street.

Something already inside the walls

The fish tank, the imaging machines and the Hue bridge all have this in common. Nobody broke through the firewall. They used something that was already trusted and already inside, and then moved around from there. If your security model is a castle, these are the things somebody carried in through the front gate because they looked harmless.

Devices pretending to be something else

There’s a classic attack where a tiny computer is built to look just like a USB drive. You plug it in, and it tells the computer it’s a keyboard, and then a mouse, and it starts typing and clicking. Walk away from your unlocked laptop for a couple of minutes before the screen saver kicks in, and somebody can plug that in and own your machine. When I plug in a keyboard, I expect it to be a keyboard. If I bought some very cheap thing from somewhere I’ve never heard of, maybe it’s more than a keyboard. Think about where your stuff comes from.

Which brings me to my favorite phone call. A while back I got a voicemail from someone claiming to be from a government law enforcement agency. I don’t expect a call from law enforcement. That’s just not how they operate, so a voicemail like that has “scam” written all over it. Being the kind of guy I am, I didn’t call the number back. I called the agency’s main line and asked whether that number and that person were real. They were, and the agency told me exactly how to make him authenticate himself, which I did, and he put up with it. (He was asking about a former employee I couldn’t remember, so he went through all that for nothing.)

While we were chatting about security, he mentioned he’d found a USB drive in the agency’s parking lot that morning, carried it into the building, and plugged it into his computer to see what was on it. A law enforcement officer, in a big government office with an IT department. I asked him if he knew not to do that, and he said he wanted to see if there was something bad on it. Well, that’s one way to find out. Don’t pick up USB drives. I had planned to leave one lying around at the conference that would phone home if anybody plugged it in, just to see, but I decided that was evil. The odds were pretty good, though.

Setting up the click

A white hat hacker I work with has a favorite spear phishing trick (a scam aimed at one specific person rather than everybody). He sends his target an email with a PDF attachment that’s deliberately broken. There’s no malware in it, so it passes every scanner, it just won’t open. Then he calls and says “hey, I just sent you that invoice, did you get it?” No, it wouldn’t open. “Oh, what version of Acrobat are you using?” Now he sends a second email with an attack built for that exact version, and you’re expecting it, so of course you open it. Notice what happened there. The usual advice is not to open attachments you weren’t expecting, and that’s good advice, but this trick is built to get around it. The first email carries nothing. Its only job is to make the phone call sound reasonable, and the phone call turns the second email from unexpected into expected.

That’s social engineering, which is about the oldest security attack in the world: talk a person into opening the door for you. No device fixes it, and it’s the same pattern as the parking lot USB drive, where you get somebody inside to carry it in for you. The defense is the one I used on my mysterious law enforcement caller. If somebody contacts you about a file, an invoice or anything else, check them out through a channel you already trust, not the one they handed you.

It’s just a tire sensor

At the talk I asked who owned a Chrysler product newer than 2014. One guy admitted it. That was the Jeep that Charlie Miller and Chris Valasek took over remotely in 2015, which ended in a recall of 1.4 million vehicles, so the idea that a car can be hacked wasn’t news even then. What interests me more is the little stuff in the car that nobody thinks of as a computer on a network.

Take tire pressure sensors. They’re required on new cars in the US and Europe because low tires cause accidents, so regulators decided a sensor in every wheel, chattering away over the radio, was worth it. They’re low-power radios, meant to reach only from the wheel to the dashboard, so the thinking was that nobody else could really hear them. And even if somebody did, every brand, and sometimes every model year, spoke a different protocol (its own little radio language), so good luck making sense of it.

Back in 2010 researchers from Rutgers and the University of South Carolina showed that the sensors didn’t check who was talking and didn’t scramble their signals, that you could pick up those signals from 40 meters away, and that you could fake them well enough to trigger the low-tire warning in a car moving next to yours on the road. In one case they confused the system so badly the dealer had to replace it. So much for nobody being able to hear them. And it didn’t get better with time. In 2021, researchers at the University of Colorado Colorado Springs went back and found tire sensors on cars from 2013 through 2019 still broadcasting in the clear and readable from 35 meters away, this time with under $50 of radio gear instead of the original team’s $1,500. (That also means your tires can be used to track your car.)

As for all those different languages, that was never much protection, because an attacker only needs to learn the one your car speaks. And it’s far less true than it used to be. The same 2021 team found that tire sensors across vehicle models use just nine data formats on two radio frequencies, and car makers have been consolidating on common protocols across the rest of the vehicle too. The fallback argument was that the worst case is either a false warning (annoying) or a missed one (maybe dangerous). Who cares?

A couple of years before the talk I was at an IQPC conference in Berlin and got into a conversation with an engineer from a car maker I won’t name. They’d been advertising a self-inflating tire system, so I asked him whether it worked while the car was moving. Yes. And how fast and how hard could it pump? Pretty fast, with a lot of pressure, because tires heat up when you drive and the pressure changes, and the system has to keep up. So I asked what his system would do if a sensor suddenly reported that a full tire was dropping toward zero. He thought about it for a second and said, well, it would try to fix it, and you could blow the tire right off the car.

Then I asked whether that was in his hazard analysis, the safety review the car industry’s ISO 26262 standard requires, and what risk level he’d given it. It wasn’t in there. And I want to be fair to him. This wasn’t a lazy engineer or an unserious company. He was a dedicated guy at a company that builds good vehicles, and he saw the problem the moment I asked. Their analysis assumed the sensor was telling the truth, because the sensor is just a sensor. Safety engineering trains you to ask what happens when something breaks. Asking what happens when somebody makes it break on purpose takes a more devious mind. To be clear, I don’t know of anybody who has actually done this, and I’m not saying it would be easy. But faking the sensor had already been demonstrated, and when they thought about what could go wrong, nobody had connected the sensor to the pump.

That’s the fish tank again, only with more sophisticated people missing it and much higher stakes. And here’s the part that aged well. In 2018, automotive cybersecurity was guidance, not a requirement. SAE had published a recommended practice in 2016, and the US National Highway Traffic Safety Administration had issued voluntary best practices the same year, but nothing made a carmaker do any of it. Since then ISO/SAE 21434 was published in 2021 as the cybersecurity engineering standard for road vehicles, and a United Nations vehicle regulation, UN Regulation 155, made an audited cybersecurity management system mandatory for new vehicle types starting in July 2022, and for all new vehicles starting in July 2024, in the countries that adopted it, including the whole EU. The industry eventually had to be told, by rule, to ask the question I was asking in that hallway.

If you build these things

I spend my days on security from the inside out, at the code level, and I’ve been on the same soapbox since long before this talk. It’s an old adage that you can’t test quality into a product. Somehow we still think we can test security into one. You can’t. By the time the penetration testers (the people you pay to break in) find the buffer overflow, it’s already in the code, and probably in a few other places they didn’t look.

Look back at what actually broke in these stories. The Hue bridge fell to a heap-based buffer overflow. More than half of those infusion pumps were exposed to a buffer overflow in their operating system. The tire sensors accepted any data from anybody without checking it. None of that is exotic. It’s the stuff we’ve known how to prevent for decades, which is the frustrating part.

Think about the little UL mark on almost every electrical thing you own. It means the device was built to engineering standards and isn’t going to shock you under normal conditions. There are standards and lists that do the same job for security, and the point of them is to keep the problem from getting into the code in the first place rather than hunting for it afterward:

• The Common Weakness Enumeration, a shared list of software weakness types, which is the language most vulnerability reports and tools speak. The CWE Top 25 is a reasonable place to start if you don’t know where to start.
• CERT C and CERT C++. Carnegie Mellon Software Engineering Institute’s secure coding standards, built directly around how code gets exploited.
• OWASP. The Open Worldwide Application Security Project, best known for its Top 10 lists. The one that matters here is the OWASP IoT Top 10, the top things to avoid when building, deploying or managing connected devices. Number one is weak, guessable or hardcoded passwords. It’s still the 2018 edition, and most of it still reads like this week’s news.
• UL 2900. The UL 2900 series covers software cybersecurity for network-connectable products, with parts specific to areas like medical devices. I sat on the UL 2900 board, so I’m biased, but it’s the closest thing to that UL sticker for connected software.
• MISRA’s coding guidelines started in the car industry and are now used in embedded software everywhere. People think of MISRA as a safety standard, and MISRA themselves complained about that perception. In 2016 they published Amendment 1 to MISRA C:2012, which added 14 security guidelines (a number of them about tainted data, meaning input you shouldn’t trust), along with guides showing how MISRA lines up with other secure coding rules, including CERT C. That security material is now folded into the consolidated MISRA C:2023 and the current MISRA C:2025, and MISRA C++:2023 picked up the security work too. If you’re writing embedded C or C++ and you’re already doing MISRA for safety, you’re closer to secure code than you think, as long as you’re using the current editions.

Beyond coding standards, two things would have stopped a lot of these stories. First, devices should check who they’re talking to before they believe anything. A bulb shouldn’t take firmware from another bulb because it asked nicely, and a tire pump controller shouldn’t believe any radio message that claims to be a tire. Second, when you think through how your device could be attacked, don’t stop at what the device does. Ask what it can reach, and what else trusts it. If your sensor feeds something that can blow a tire off a car, the sensor isn’t “just a sensor” anymore, and your hazard analysis should say so.

(And yes, memory-safe languages take a whole class of these bugs off the table, but that’s a tale for another day.)

If you buy these things

Most of us aren’t building light bulbs or fish tank thermometers. We’re buying them, plugging them in, and forgetting about them, and that’s where most of the risk actually lives. Here’s what I’d do.

Keep strangers off your network. When I asked the room how many people let a visiting friend or relative onto their home Wi-Fi, nearly everybody raised a hand. You’re all so nice. Practically every router sold in the last several years supports a guest network, so use it, for guests and for the gadgets you don’t fully trust. My plan for the lizard’s tank (more on the lizard below) was to put the whole contraption on the guest network, because I didn’t trust it either. At work, segment your network so the cheap stuff can only reach what it needs. Just don’t assume that’s the end of it. The casino actually did this: according to Darktrace, the fish tank had its own private, separate connection, isolated from the rest of the network, and the attackers got through anyway. That’s not a reason to skip it. People can still steal your car, but you should still lock the doors.

Watch what your devices are saying. Back in 2011 the Wall Street Journal reported that Chinese hackers had been inside the U.S. Chamber of Commerce network for months, and after the Chamber cleaned up, it kept seeing strange things. A thermostat in a Chamber-owned townhouse on Capitol Hill was communicating with an internet address in China, and a printer started spitting out pages of Chinese characters. So the Chamber thought it had the problem shut down, and then, by the way, the thermostat is talking to China. Maybe they’d shut it down and maybe they hadn’t. I don’t expect my thermostat to send packets anywhere interesting, and if it starts sending big ones somewhere I’ve never heard of, I want to know. How many of you have ever checked what your thermostat talks to? At the talk, two people raised their hands. Good on them.

Monitoring is what caught the fish tank, but look at the timing. It caught it after about 10GB had already left the building. Monitoring tells you something is wrong. It doesn’t stop the first gigabytes from going out the door, and it only limits the damage if somebody is watching the alerts and acts on them fast. A high-roller database that’s halfway to Finland is still in Finland.

So use monitoring to back up something stronger. A thermometer’s normal behavior is easy to describe: small readings, on a schedule, to one place you know. Write that down as the rule, and block everything else where your network meets the internet instead of just flagging it. If the fish tank had only been allowed to talk to its vendor’s server, 10GB to a stranger in Finland wouldn’t have been an alert. It would have been a dropped connection. Segmentation limits what a device can reach, outbound rules limit what it can send, and monitoring catches what slips past both. You want all three, because any one of them alone is how you end up in somebody’s conference talk.

Ask whether the connection is worth it. Right before the talk I downloaded a bell app, just to see. You open it, there’s a bell, you shake the phone, the bell rings. That’s the whole app. The top-rated one in the store wanted access to my photos, my files, and my call history. Why does a bell need my call history? No, thank you. For every connected thing, ask yourself whether what the connectivity gives you is worth more than the risk it brings. Sometimes it is. Your kids’ connected toys, though? Just say no. Researchers have found toys that were effectively listening devices, and it gets worse. In 2017 Germany’s telecom regulator banned a talking doll called My Friend Cayla and told parents to destroy the ones they had, because researchers showed that anyone within Bluetooth range could connect to it, listen to the child playing with it, and talk to that child through the doll. Ugh. I can’t think of a creepier thing to bring into the house.

Think about where it comes from. Be careful what you’re buying, where it’s built, how it’s assembled, and who’s standing behind it. The cheapest thing on the marketplace may be cheap for a reason.

Hold vendors accountable. Don’t buy devices whose makers won’t tell you how they handle security and updates. If you’ve got one that turns out to be junk, complain, ask for your money back, and tell people. If you buy at work, this is where you ask vendors what’s in their software, how long they’ll patch it, and how they’ll tell you when something’s wrong. Companies that make insecure devices only change when it costs them money, and you’re the one with the money.

About the lizard. A relative had a bearded dragon, and those need careful temperature control or they die. Naturally I wanted to wire up the tank with thermometers, day and night light cycles, an oxygen sensor, the works, with alerts to my phone. They said no, it’s just a lizard. So we did nothing, the heating element quietly broke during a cold snap, and the lizard died. So I’m not telling you to give up on connected stuff. I’m telling you to connect it on purpose, knowing what it can reach.

Regulation or insurance, pick one (they picked both)

I closed the 2018 talk by saying we were going to get regulation, and that the real argument was regulation versus insurance. Either you make it legally unviable to ship junk, or you make it financially unviable. Either one works.

The regulation showed up. California’s law requiring connected devices to ship without a universal default password took effect in 2020. The UK’s product security law banned default passwords on consumer connected products in 2024, along with requiring a way to report vulnerabilities and a stated minimum update period. The EU’s Cyber Resilience Act entered into force in December 2024, its vulnerability reporting obligations kicked in just this September, and full compliance, including security by design and the CE mark products need to be sold there, applies from December 2027. Add the UN rule for cars and that’s a lot of rules for something everybody told me was just a stupid little light bulb.

The insurance part was less of a guess than it sounded. Some of the people in the Cybersecure LA community were cyber insurers, and we’d had long conversations about where their policies were heading. On stage I said that if I were writing cyber insurance policies, I’d exclude anything with a vulnerability published in the National Vulnerability Database that you hadn’t patched, because insurers are in business to make money. Some insurers seem to be doing roughly that. Chubb’s Neglected Software Exploit endorsement gives policyholders 45 days to patch a vulnerability once it’s published in that database, after which more and more of the risk shifts to the policyholder at 45, 90, 180 and 365 days. It isn’t universal, and some insurers, Coalition for one, argue publicly that exclusions like this undermine the point of having insurance. But the idea that “you knew about it and didn’t patch it” will cost you at claim time is no longer hypothetical.

So the next time somebody tells you it’s just a thermometer, or just a light bulb, or just a tire sensor, don’t ask what it does. Ask what it can reach. Then make sure the answer is “not much.”

Stay secure out there.

Originally published at https://codecurmudgeon.com on October 2, 2026.

Jumping the Goldfish: IoT Insecurity Eight Years Later was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

A friend asked me a question this week. He’d been getting a lot of spam, and he wanted to know the right way to deal with it: report it, reply with “unsubscribe,” or leave it sitting in the inbox undeleted. That last one was in the running because another friend had explained to him, with great confidence, that leaving it alone was the only correct thing to do. Emphatically. As settled fact.

He asked me because it sounded wrong to him. Hold that thought. I’ll come back to it.

Notice what happened first, though. Somebody told him. He believed it for a while. And the only reason he got a second opinion is that he happens to know a guy.

I wrote this list in 2017, as a joke. Nine years later some of it is out of date, a good deal of it isn’t, and I’m not sure which half bothers me more. Old problems are comfortable. I know what they look like. What I didn’t expect was how many of them are still here.

Here’s the 2026 edition. As before, this is really how to spot someone who is NOT a cybersecurity expert.

Also, I wasn’t wearing a suit. That’s probably why he trusts me.

#10 — Wears a suit and tie

Have you ever met someone who really got cybersecurity who was wearing a tie?

I’ll wait.

#9 — Carries a phone that stopped getting security updates

In 2017 I said a phone more than a year old was a red flag. That one aged badly and I’ll own it. Apple, Google, and Samsung now ship security updates for five to seven years, so a four-year-old phone in the right hands is perfectly respectable.

The tell was never the age. The tell is a phone that stopped getting patches and a person who has no idea, because he has never once looked.

#8 — Still carrying a BlackBerry

This was a joke in 2017. It’s an archaeological finding now. BlackBerry shut down the services for its classic devices in January 2022, which means the thing in his jacket pocket is a paperweight with a keyboard.

He will tell you it’s more secure. It is, in the sense that a car with no engine is harder to steal.

#7 — Doesn’t use the command line

The reigning champion from the original list, demoted purely on seniority. Everyone with a hacker mentality uses the command line, whatever the operating system. That hasn’t changed at all. It’s just less funny than it used to be, which I suppose is a kind of progress.

#6 — Has password opinions from 2005

Two beliefs, same vintage. That eight characters is plenty, and that the real strength is in the punctuation: P@ssw0rd! and similar theater.

NIST has since come down on both. The current guidance says a password standing on its own should be at least 15 characters, and it tells sites to stop imposing composition rules altogether. No more mandatory capital-number-symbol. Length beats gibberish, and a long passphrase you can actually remember beats a short one on a sticky note under the keyboard.

I’ve been saying this since the first version of this list, and it’s still true.

Here’s a freebie while we’re here. If a site still demands a capital, a number, and a symbol, it’s running on guidance NIST retired in 2017, the same year I first wrote this list. That tells you something about how much attention anyone there has paid since. Be careful what you keep in that account.

#5 — Says “AI-powered” when you ask him how it works

Ask three simple questions. What does it actually find? What happens when it’s wrong? Who reads what it produces?

Someone who has used the thing answers all three in about a minute, and volunteers the part where it’s wrong, because it has annoyed him personally. Someone who has been briefed on the thing says “it’s -powered” again, slightly louder.

The technology is real. The sentence is not an answer. It’s a dodge.

#4 — Thinks the code that arrives by text is the good kind of two-factor

That code you get in a text message when you log in is called two-factor authentication. It’s better than no two-factor, so if that’s what your bank offers, turn it on today. It is not what you should be using in 2026.

Here’s why. The code goes to your phone number, and your phone number can be moved onto somebody else’s phone with a convincing call to your carrier. That’s called a SIM swap, and it has been emptying accounts for over a decade. A passkey, or a code from an app on your phone, doesn’t travel with your number.

The fake expert doesn’t know there’s a difference. The real one can tell you which of his accounts still fall back to text messages, because those are the accounts he expects to lose.

#3 — Won’t touch the airport Wi-Fi, but tapped the link in the “your package is delayed” text on the way to the gate

Skipping open Wi-Fi is good hygiene. So is carrying your own charger and finding a wall outlet instead of plugging into the public USB port. So is locking your car, even though your car is a big metal safe with four panes of easy-to-break glass in it.

A determined attacker beats all three. You do them anyway, because hygiene is cheap and habits are what hold up when you’re tired in an airport at eleven at night.

But look at what actually happened to him. A text said a package was delayed and needed a small delivery fee. He tapped the link, got a page that looked like the shipping company’s, and typed in a card number. That’s the entire attack. No Wi-Fi, no USB, nothing clever. It works because he was tired, because he really was expecting a package, and because it took four seconds.

He lectured me about the terminal Wi-Fi and then handed his card to a stranger before we boarded. The precaution wasn’t wrong. It was just the only one he had, and it was pointed in the wrong direction.

#2 — Plugged in the USB stick he found in the parking lot

“I just wanted to see what was on it.”

Researchers have been dropping sticks in parking lots and on campuses for years, and a large share of them get picked up and plugged in, by people who will swear they’d never fall for a phishing email. Curiosity is the exploit. There’s no patch for it.

I have had this conversation with a man whose job title contained the word “cybersecurity,” about a stick he found in the parking lot of a government building. He knew the trick. He had watched it happen on Mr. Robot. He was embarrassed, and he should have been.

I want to be clear that this is not a story about a stupid person. Knowing an attack and recognizing it while it’s happening to you are two completely different skills, and only one of them shows up on a résumé.

#1 — Took the “What’s your superhero name?” quiz, then tagged five friends

First pet plus the street you grew up on. Mother’s maiden name plus your first car.

These are not personality quizzes. They are the security questions your bank still uses to let a stranger reset a password over the phone, and the quiz collects the answers from you, in public, voluntarily, for fun.

Then it asks you to tag friends so they’ll post theirs. That’s the part that makes it work at scale. He didn’t just hand over his own answers. He recruited.

The guy who won’t play along isn’t a killjoy. He’s the one who read the questions before answering them.

Oh, and just one more thing

If he says “cyber” as a noun, turn around and walk the other way.

“We need more cyber.” “The cyber is a big problem.”

Nobody who has ever actually fixed anything talks like this. It’s the verbal tell that the speaker was briefed on the subject rather than having worked in it, and everything that follows will be a summary of a summary.

Here’s the part that isn’t funny. The suit and the vocabulary aren’t incidental to how he got the job, they’re how he got the job. Somebody needed a person who could stand in front of a room and say the word “cyber,” and the résumé that matched was the one that looked the part. And he isn’t merely useless in that chair. He’s a mark. He’s the one who will buy whatever the next fellow in a better suit is selling, with your budget, and put the receipt in a slide deck.

As always: if he uses a term you don’t know, make him explain it. If he can’t explain it, he probably doesn’t understand it very well.

You need somebody real in your life for this. Even more than you did in 2017.

Sorry, just one more last thing. I mean it this time.

Just delete the spam. Don’t reply, don’t click.

My friend’s friend wasn’t making it up, by the way. “Don’t reply and don’t click” is good advice. It just decayed, somewhere along the way, into “don’t touch it.” That’s how most bad security advice happens. It’s real advice with the reasoning worn off.

Stay sharp. Stay safe. And don’t tell anybody the name of your first pet.

Originally published at https://codecurmudgeon.com on September 24, 2026.

Top 10 Ways to Spot a Cybersecurity Expert (2026 Edition) was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

Finding and fixing bugs early in development pays off in many ways. It can reduce development time, cut costs, and prevent data breaches or other security vulnerabilities. In particular with DevOps, incorporating testing into the SDLC early and continuously can be extremely helpful.

This is where both dynamic and static analysis testing come in. They each serve different purposes within the SDLC while also delivering unique and almost immediate ROIs for any development team.

Static vs. Dynamic Analysis: Understanding the Differences

Static code analysis is a broad term used to describe several different types of analyses. However, all of these feature a common trait: they do not require code execution to operate.

In contrast, dynamic analysis does require code execution. Though there are other differences, this characteristic is what drastically separates the two types of testing approaches.

This also means that each approach offers different benefits at different stages of the development process. In order to understand these differences, let’s review the following.

• What each strategy requires.
• Testing types under the umbrella terms.
• Tools that assist the process.

What Is Static Analysis?

Static code analysis testing includes various types with the main two being pattern-based and flow-based.

Pattern-based static analysis looks for code patterns that violate defined coding rules. In addition to ensuring that code meets uniform expectations for regulatory compliance or internal initiatives, it helps teams prevent defects such as resource leaks, performance and security issues, logical errors, and API misuse.

Flow-based static analysis involves finding and analyzing the various paths that can be taken through the code. This can happen by control (the order in which lines can be executed) and by data (the sequences in which a variable or similar entity can be created, changed, used, and destroyed). These processes can expose problems that lead to critical defects such as:

• Memory corruptions (buffer overwrites)
• Memory access violations
• Null pointer dereferences
• Race conditions
• Deadlocks

It can also detect security issues by pointing out paths that bypass security-critical code such as code for authentication or encryption.

Additionally, metrics analysis involves measuring and visualizing various aspects of the code. It can help detect existing defects, but more often, it warns of potential difficulty in preventing and detecting future defects when code is maintained. This is done by finding complexity and unwieldiness such as:

• Overly large components
• Excessive nesting of loops
• Too-lengthy series of decisions
• Convoluted intercomponent dependencies

What Is an Example of Static Analysis?

A simple example of static analysis is using automated tools to inspect source code for issues without running the program. These tools analyze the code’s structure, logic, and data flow to detect problems early in development.

For example, a linter scans C or C++ code to enforce coding standards and flag issues like unused variables, unreachable code, or unsafe language constructs.

A static type or semantic analysis examines how variables and functions are used across the codebase to identify runtime failure causes, including:

• Type mismatches
• Uninitialized variables
• Division by zero
• Incorrect API usage

Static analysis is also commonly used for security scanning. By tracing how data flows through the code, tools can detect vulnerabilities like buffer overflows, null pointer dereferences, or missing input validation, without executing any tests.

Another example is code complexity analysis, which highlights functions that are difficult to test or maintain by measuring factors such as complexity and dependency depth.

In practice, these analyses run automatically in IDEs or CI pipelines, giving developers immediate feedback and allowing defects, security risks, and compliance issues to be addressed early-before the software is built or deployed.

What Is Dynamic Analysis?

Sometimes referred to as runtime error detection, dynamic analysis is where distinctions among testing types start to blur. For embedded systems, dynamic analysis examines the internal workings and structure of an application rather than external behavior. Therefore, code execution is performed by way of white box testing.

Dynamic analysis testing detects and reports internal failures the instant they occur. This makes it easier for the tester to precisely correlate these failures with test actions for incident reporting.

Expanding into the external behavior of the application with emphasis on security, dynamic application security testing (DAST) is analytical testing with the intent to examine the test item rather than exercise it. Yet the code under test must be executed.

DAST also extends the capability of empirical testing at all levels-from unit to acceptance. It does this by making it possible to detect internal failures that point to otherwise unobservable external failures that occur or will occur after testing has stopped.

What Is an Example of Dynamic Analysis?

Dynamic analysis examines software while it runs to detect issues that only appear at runtime. It evaluates how the program behaves, interacts with memory, and responds to inputs.

A common example is unit and integration testing, where functions or components are executed with controlled inputs. During these tests, runtime errors, such as failed assertions, incorrect logic, or unexpected edge cases, can be detected immediately.

Another example is runtime memory analysis, which monitors memory allocation and usage to catch problems that only appear during execution:

• Leaks
• Buffer overflows
• Null pointer dereferences

Dynamic analysis is also applied to security testing, such as fuzzing, where the application is executed with malformed or unexpected inputs to uncover crashes, undefined behavior, or vulnerabilities.

In practice, dynamic analysis is often integrated into CI pipelines and test environments, providing immediate feedback on runtime behavior, validating functionality, and helping teams catch defects before deployment.

Pros & Cons of Static Analysis

As with all avenues toward DevSecOps maturity, there are pros and cons with static analysis testing.

PROS

• Evaluates source code without executing it.
• Analyzes the code in its entirety for vulnerabilities and bugs.
• Follows customized, defined rules.
• Enhances developer accountability.
• Capable of automation.
• Highlights bugs early and reduces the time it takes to fix them.
• Reduces project costs.

CONS

• Can return false positives and false negatives that might distract developers.
• Can take a long time to operate manually.
• Can’t locate bugs or vulnerabilities that come about in runtime environments.
• Deciding which industry coding standards to apply can be confusing.
• May be challenging to determine if deviating from a rule violation is appropriate.

While the list of cons might look intimidating, the holes of static analysis can be patched with two things.

1. Automating static analysis.
2. Using dynamic techniques.

Pros & Cons of Dynamic Analysis

Dynamic analysis, like all testing approaches, has its advantages and limitations.

PROS

• Evaluates software behavior while it is running.
• Detects runtime errors that static analysis cannot catch.
• Identifies memory, resource, and performance issues.
• Reveals security vulnerabilities that emerge only under execution.
• Can validate actual functional behavior with real or simulated inputs.
• Provides precise correlation between test actions and observed failures.
• Supports CI/CD automation for continuous feedback on runtime behavior.

CONS

• Can be time-consuming, especially for large or complex systems.
• May require comprehensive test coverage to find all runtime issues.
• Can miss defects in code paths not executed during testing.
• Test environment setup can be complex or resource-intensive.
• Some issues, like deep logic flaws, may remain hidden if test inputs are insufficient.

While the cons may seem important, dynamic analysis becomes most effective when combined with:

• Comprehensive automated test coverage
• Static analysis to catch issues early, before execution

Why Static Code Analysis Is So Valuable

All these types of static analysis have one thing in common: they involve scanning or having a program examine source code.

This is a fast and easy way to expose critical defects. It achieves 100% coverage with 100% objective results.

Doing it continually just makes sense as it delivers these actionable results, reduces costs and development time, increases code coverage, and more.

Beyond the Scope of Static Analysis

Static scanning provides information to help predict what may happen when code is integrated and executed. It detects defects based on what the tool considers a defect. Typically, this can be customized to suit your preferences and priorities.

However, it cannot tell you when the system under test or in production delivers unexpected, inappropriate, or inaccurate results.

The challenge here is to observe unexpected behavior. For example, a transaction may appear to proceed correctly to a user, tester, or test execution tool when, in fact, a component has thrown an unhandled exception and failed to process it correctly. A control system may respond quickly and correctly under test for three days but could be leaking memory and heading for a crash on day four in production.

Fixing all defects detected by using a static code analysis tool gives no assurance against other defects that will cause failures like these. That’s why it’s important to apply the definition of failure to internal as well as external behavior-even after integration. The internal failure must be detected before it manifests itself externally.

How AI Is Changing Static & Dynamic Analysis

AI adds another layer of automation to static and dynamic analysis. Instead of replacing these proven techniques, AI helps you:

• Understand results faster.
• Remediate issues.
• Create tests.
• Close coverage gaps more efficiently.

Specifically in Parasoft C/C++test, AI-assisted workflows help you investigate and remediate static analysis findings. AI uses information about a reported violation, the associated coding rule, and supporting analysis data to give context and suggest fixes. These capabilities extend from the developer’s IDE into CI workflows, helping your team address quality, security, and compliance issues earlier in development.

AI also accelerates dynamic testing. C/C++test supports AI-assisted unit test creation to help expand tests and improve coverage. If your team uses existing C and C++ testing frameworks such as GoogleTest, C/C++test CT uses AI-assisted workflows to analyze coverage gaps, including MC/DC coverage. It also helps identify additional test conditions needed to exercise missing paths.

The important distinction is that AI doesn’t replace the underlying verification evidence. Static analysis still identifies potential defects and coding-standard violations. Tests still execute the software and verify its behavior. Coverage still measures what code has been exercised. AI helps you act on that evidence faster while keeping you in control of the verification process.

Best Practices for Combining Static & Dynamic Analysis

Combining static and dynamic analysis is the best option to get actionable results, reduce bug occurrences, increase bug detection, and create more secure code overall. One is not better or worse than the other. They work in tandem like all the gears of a perfectly crafted Swiss watch.

To use static and dynamic analysis together, follow these best practices.

• Use them both with manual and automated solutions that fit your needs.
• Make the code readable and reusable for other developers.
• Use the right approach at the right point in your SDLC — static early on and dynamic in runtime environments.
• Make use of both approaches for a more holistic overview of your project.
• Avoid the pitfall of relying on only one testing method, a small oversight that can lead to big problems.

Combining static and dynamic analysis empowers teams to locate a wider range and number of exploitable threat vectors.

Get the Whitepaper

Originally published at https://www.parasoft.com on September 16, 2026.

Static Analysis vs Dynamic Analysis was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everybody knows you’re supposed to check the license before you pull an open source component into your product. Almost nobody checks it again afterward. Since 2018 that second part has been costing people real money, and it’s what this article is mostly about.

Open source projects come with a wide variety of license types, and some of them conflict with each other. They carry restrictions against commercial use, requirements to distribute source code, attribution obligations, and more. If you’re pulling in several projects at once, staying in compliance across all of them turns into an administrative headache. Some projects even offer multiple license choices, and you need to understand which one you’re taking and which you can ignore.

So you do the sensible thing. You review a license type once, decide whether it’s acceptable, and then clear every component that carries it. MIT is fine, Apache is fine, GPL needs a conversation, and once that’s settled you go back to work.

That worked for about twenty years. It stopped working in 2018, and not because somebody drafted a tricky new license. It stopped working because the license stopped being a fixed property of the thing you adopted.

The license can change after you adopt it

Most of us treat a component’s license the way we treat its API, as something that’s settled once we pick the thing up. That hasn’t been true for a while now, and here are four examples that show the pattern. It runs the same way each time. A project with a single commercial owner finds somebody else making money from it, often a cloud provider but not always, and the owner responds by relicensing the next release. The owner does the relicensing every time. Nobody else can.

• October 2018. MongoDB moves Community Server to the Server Side Public License. Red Hat pulls it from the RHEL 8 beta, Fedora bans SSPLv1 outright, and Debian drops the package. (MongoDB)
• January 2021. Elastic moves Elasticsearch and Kibana off Apache 2.0 to a dual SSPL / Elastic License. AWS forks 7.10.2 into OpenSearch three months later. (Elastic)
• August 2023. HashiCorp moves Terraform, Vault and Consul to BUSL 1.1. OpenTofu forks within weeks, and OpenBao follows. (HashiCorp)
• March 2024. Redis leaves BSD 3-clause for dual RSALv2 / SSPLv1, saying plainly that “Redis is no longer open source under the OSI definition.” Valkey launches at the Linux Foundation eight days later, forked from 7.2.4. (Redis, Linux Foundation)

Confluent, Mapbox and Lightbend (Akka) ran versions of the same play between 2018 and 2022. Grafana, Sentry and Cockroach Labs get lumped in with them and shouldn’t be. Grafana moved to AGPLv3, which is still an OSI-approved license. Sentry’s move shortened its conversion clock rather than lengthening it. Cockroach Labs retired a free tier without relicensing code that was already under BSL. Those are all worth knowing about, but they aren’t this.

And it doesn’t only run one direction, either. Elastic and Redis have both since added AGPLv3 back, in 2024 and 2025, and they’re tri-licensed now.

Which raises the obvious question. If everybody hated the SSPL that much, why did MongoDB adopt it? Because users were never the target. MongoDB CTO Eliot Horowitz said so pretty plainly at the time: “once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value while contributing little back to the community.” CEO Dev Ittycheria put a number on what they were defending, roughly $300 million of R&D over the preceding decade. That’s an understandable grievance, and every relicensing in the list above is some version of it.

Whether it actually works is another matter. AWS announced DocumentDB on January 9, 2019, less than three months after the SSPL move, and they built it from scratch to emulate the Apache-2.0-licensed MongoDB 3.6 API rather than use MongoDB’s code at all. So the license change didn’t stop the competitor it was aimed at, but it did get the package pulled from Red Hat, Fedora and Debian. ( AWS)

That’s the part worth remembering. The shot gets fired at a competitor, usually a big one, and the people who reliably get hit are the ones who had the component sitting in their dependency tree.

Notice that none of them is a case of anybody picking the wrong license. In every one of these, whoever made the call did exactly the review-it-once check I described above, cleared the component correctly, shipped it, and then had the terms change underneath them.

Look at what that cost the people downstream.

Apache Flink pinned to the last Apache-licensed Akka, then opened FLINK-32468 to replace it entirely, and they said why right in the ticket: “Akka 2.6.x will not receive security fixes from September 2023 onwards.” That’s not a licensing task, it’s a serious engineering project, and they didn’t really have a choice about it either. The alternative was to keep running a core subsystem that had stopped getting security patches, and good luck explaining that one to a customer or an auditor. The community’s answer was to fork Akka’s last Apache-licensed release into Apache Pekko, which became a top-level Apache project in May 2024. Forking a library and standing it up as its own Apache project is a lot of work to do because somebody else changed a license.

Elasticsearch fragmented, in several directions at once. Some shops accepted the new terms and stayed with Elastic. Some moved to AWS’s fork, which became OpenSearch and now runs as its own Linux Foundation project with AWS, SAP and Uber as premier members. Some pinned an old version and stopped upgrading. Some used the disruption as their excuse to leave the category altogether. Then in late 2024 Elastic added AGPLv3 back and announced that Elasticsearch was open source again, which turned out to be a narrower opening than it sounded. When Platform.sh customers asked for a free build under that option, its engineers found that “the code to build the OSS flavor of Elasticsearch has been removed,” and passed on rebuilding it themselves. ( Upsun, Linux Foundation, Elastic)

I can’t tell you the proportions, and neither can anybody else with a straight face. What I can tell you is that adopters who used to have a default now have a decision.

And Fedora 41 just replaced Redis with Valkey outright. The valkey-compat package carries Obsoletes: redis, migrates your config and data, and aliases the systemd units, so the whole substitution is "mostly transparent to users," which is Fedora's own description of it. ( Fedora) If Redis was in your dependency chain by way of a distro package, your supply chain changed and nobody on your team ever filed a ticket. That one has consequences for your SBOM that are worse than they look at first, and I'll come back to it.

So license review isn’t a gate you pass once at adoption. It’s something you keep watching for as long as the dependency is in your product. Checking the license when you adopt a component and never again is like checking the oil when you buy the car. It tells you something true on that day and nothing at all about the next hundred thousand miles. That’s a different job than the one most of us set up, and it needs tooling that almost nobody has.

What the source-available licenses actually say

Two of these licenses account for most of the confusion, the Business Source License and the SSPL, and both of them get described sloppily almost everywhere. For each one there are really only two things you need to know: what it forbids, and whether that ever lapses.

Business Source License 1.1. In plain terms, you can use it for anything you like, production included, as long as you’re not selling it as a hosted service that competes with the vendor’s own paid product. And the restriction has an expiration date on it. Each release converts to a normal open source license on its own Change Date, which can be up to four years after that version shipped, and the conversion happens automatically. The license spells it out: on that date the licensor “grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.”

That promise is finally testable, because the first conversions are coming due, and the early results aren’t encouraging. Akka went BSL in late 2022 on a three-year clock, so Akka 2.7 should have turned back into Apache 2.0 sometime in late 2025. Go look at the license file for that release, though, and there’s no date in it. Where the Change Date belongs, it says “TBD ( 3 years after 2.7.0 release ),” and I can find no announcement that the date ever arrived. A formula is not a date. If you’re counting on a Change Date to get you out of a BUSL component someday, you may end up working out for yourself whether it has passed, using a document that declined to tell you. ( Akka 2.7.0 LICENSE)

The other catch is that the license never defines “compete.” It leaves a blank called the Additional Use Grant and lets the vendor fill it in. (Yes, the one term that decides whether you’re in violation is the one term the license hands to the party you’d be violating it against.)

You can go read Terraform’s and try to work out what it means, but it’s rough going. It opens with “You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work…” and carries on in that vein for about 380 words across six paragraphs, stopping along the way to define what counts as a “competitive offering,” what counts as a “Product,” what counts as “Embedded,” and which internal uses inside your own company and its affiliates don’t count against you.

Go read it anyway. I’m not going to summarize it for you, because the summary is where you get in trouble, and because every BUSL component in your stack has a different one. It’s the only part of that license somebody wrote specifically about you.

Then notice whose name is on it now. The Licensor field reads “International Business Machines Corporation (IBM).” IBM completed its acquisition of HashiCorp on February 27, 2025, so the terms telling you what you may not do with Terraform are written by a different company than the one you originally adopted it from. ( BSL 1.1, Terraform LICENSE, IBM)

SSPL. This is MongoDB, and Redis from 7.4 onward. It differs from BUSL in two ways, and both of them cut against you.

First, nothing expires. There’s no Change Date and no conversion, so the obligation is permanent.

Second, what sets it off is broader than most people assume, and it isn’t just “are you a cloud provider.” Section 13 says that “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.”

And if it does trigger, you don’t just owe your changes to the database. Service Source Code is defined to include “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software,” enough that somebody else could stand up your service from whatever you published. In practice that’s your deployment tooling and your whole operational stack, not just the component you adopted. Whether “available to third parties as a service” describes your own internal platform is a question worth asking out loud, preferably before somebody else asks it for you. ( SSPL)

Functional Source License. This is Sentry and Codecov. It’s the same shape as BUSL but with a shorter fuse and no blank for the vendor to fill in, so each release converts to MIT or Apache 2.0 two years after it publishes. If you have to carry one of these in your stack, this is the friendliest version of it. ( fsl.software)

None of the three is open source under the OSI definition, and the OSI has been blunt about it, calling SSPL “fauxpen source” and saying that claiming otherwise “is deception, plain and simple.” Whether that’s the right label is a fight for another time and place. It isn’t the issue here. The issue is that every license in your software has to be assessed and addressed properly, whatever anybody calls it.

The pitfalls, revisited

Ambiguity. Some licenses are ambiguous because they’re drafted without the benefit of professional legal advice, so get legal advice before you adopt one. The standard advice is that this is a one-time cost per license type, and half of that still holds, since you don’t re-review MIT every time you add an MIT component. What’s changed is that you now have to review on update as well as on adoption. And the ambiguity that costs you money isn’t in MIT’s 170 words. It’s in the Additional Use Grant, where the vendor writes their own meaning for “compete,” and where every new release can carry a different one, because BUSL applies separately to each version.

Jurisdiction. Still a real pitfall, and it turned out to matter for a reason I didn’t see coming in 2016. Entr’ouvert v. Orange spent more than a decade in the French courts over Lasso, a GPLv2 SSO library that Orange built into a French government portal without publishing its modified source. Watch the sequence, because it is the whole point. In March 2021 the Paris Court of Appeal ruled that Entr’ouvert could not even bring an infringement claim, since French law generally makes you pick between suing on the contract and suing in tort. The Cour de cassation overturned that on October 5, 2022, holding that a copyright holder stays entitled to sue for infringement even though a license contract exists, because a contract claim would not give them the enforcement remedies that EU Directive 2004/48 provides. On remand, a differently composed Paris Court of Appeal found on February 14, 2024 (case 22/18071) that Orange had infringed, and awarded €500,000 for economic harm, €150,000 for the profits Orange made and €150,000 for moral prejudice, plus €60,000 in costs. Around €860,000, against the €4 million Entr’ouvert had asked for. I’m not aware of a larger monetary award in a GPL case, and it happened in a jurisdiction that reasons about the copyright-versus-contract question differently than US courts do. ( Legalis, DLA Piper, Heather Meeker)

Unintended open source. The GPL still requires derivative works to carry the same terms, but what’s changed is where this bites you. In 2016 the GPL question was about shipping binaries. Today the sharper question is AGPL, which extends the source obligation to network use, and which now sits under Grafana, Loki, Tempo, Elasticsearch, Redis 8 and a growing pile of other infrastructure. Plenty of large engineering organizations ban AGPL outright in their dependency policies. If yours does, and you also have a policy of taking whatever the distro package manager hands you, those two policies are in conflict right now and nobody has told you about it.

Patent rights. Most developers have never had this one explained to them, so here it is. A license that gives you the code doesn’t automatically give you the right to do what the code does. Copyright covers the code itself. Patents can cover the technique the code implements. So somebody can hand you their software under a perfectly good open source license and still hold a patent that you infringe by running it. An express patent grant closes that gap. The contributors license you the patents covering their own contributions along with the code, so they can’t turn around and sue you for using the thing they just gave you.

Whether a license does that depends on the version more than the family. GPLv3 grants patent rights in section 11 and Apache 2.0 in section 3. GPLv2 grants none at all.

Both Apache 2.0 and GPLv3 also take rights away if you sue claiming the software infringes your patents, and they take different amounts. Apache terminates your patent license and leaves you free to keep using the code. GPLv3 treats that suit as a license violation, which reaches termination of the whole license. Apache takes away your shield. GPLv3 can take away the code.

That’s as far as I’m going to take it here. If patents matter to your business this is a conversation with counsel, and the sections to put in front of them are 10 and 11 of GPLv3, section 3 of Apache 2.0, and section 7 of GPLv2, which grants nothing but can stop you distributing at all.

Enforcement. Jacobsen v. Katzer (Fed. Cir. 2008) established that violating an open source license is legally actionable in the United States, and for years that was the case everybody cited. It’s still good law, and it’s also now the least interesting thing you can say on the subject, because the question has split into two: enforceable by whom, and on what theory.

On theory, Artifex v. Hancom (N.D. Cal. 2017) got a court to hold that the GPL can form an enforceable contract without anybody signing anything. It settled before trial, so it’s persuasive rather than binding, but it opened a door.

On who, Software Freedom Conservancy v. Vizio is the live one, and it’s the one that should interest you. SFC bought TVs and sued in contract as an alleged third-party beneficiary of the GPLv2 and LGPLv2.1, asking for source code rather than damages. In December 2023 the court denied Vizio’s summary judgment motion, finding triable issues and observing that third-party enforcement is “not only consistent with the GPLs’ objectives; it is both essential and necessary to achieve these objectives.” In December 2025 Vizio won a narrower point, that the GPLs don’t require you to enable reinstalling modified software back onto the device. Trial was set for August 2026 and no decision has been reported as of this writing. If that theory holds up, the people who can come after you over a copyleft component include your own customers. ( SFC, LWN)

A lot of coverage has already announced that “courts have ruled consumers can enforce the GPL.” No court has held that. A California trial court found the question triable, which is a state trial court order with no precedential weight, in a case that hasn’t finished yet.

Meanwhile the quieter case is the one worth copying into your compliance runbook. Sebastian Steck, a German software developer, sued the router maker AVM in the Landgericht Berlin in July 2023, because the firmware source AVM shipped left out the scripts used to control compilation and installation for LGPL-2.1 libraries. AVM never took it to judgment. It handed over complete source for the FRITZ!OS versions at issue, including the missing installation information, covered Steck’s legal costs of €7,500, and the parties ended the case by agreement in 2024. So there’s no precedent to cite here. What there is instead is a manufacturer who looked at the claim and decided complying was cheaper than arguing, which for your purposes is arguably more informative than a ruling. The same theory is one of the live claims against Vizio, and there’s a lesson in it for anybody shipping a device with copyleft code inside. What trips companies up is rarely the source code itself, which they usually do hand over. It’s everything that has to come with it: the scripts and instructions somebody needs to actually build that code and get it onto the device.

New pitfall: provenance you can’t see. Every tool your organization uses for license compliance works the same way. It reads the files where your project lists the outside components it depends on, then looks up what license each one carries. That’s what software composition analysis is. -generated code never shows up on that list. It arrives as ordinary code inside your own files, checked in under your own developer’s name, with nothing anywhere declaring where it came from. So it’s invisible to the tooling you bought for exactly this problem, and not because the tooling is bad. It’s invisible because there’s nothing for the tooling to look at.

How often that turns into a real license problem, nobody credibly knows. What’s documented is that it happens. In July 2021 Copilot autocompleted Quake III’s fast inverse square root implementation and then autocompleted a BSD-2 license header naming the wrong copyright holder. GitHub’s own 2021 study found roughly one recitation event per ten user-weeks at a 60-token threshold. GitHub’s product claim is that matches turn up in “less than one percent” of suggestions, and that number comes with some important qualifiers: the matching only runs against public GitHub repos, over roughly a 150-character window, against an index that’s refreshed every few months. So it’s a floor on a narrow definition, not a measure of your exposure. ( GitHub, The Register)

The legal question is live and a lot narrower than the headlines suggest. In Doe v. GitHub, the DMCA claims over stripped copyright management information were dismissed on an “identicality” reading of section 1202(b) and certified for interlocutory appeal, and the Ninth Circuit heard argument in February 2026. But the breach-of-contract claims based on the open source license terms were never dismissed and they’re still live in the district court. Anyone telling you the Copilot suit got thrown out is reading the wrong half of it.

Vendors have responded with indemnity rather than provenance, and indemnity is a contract term they control. Microsoft’s Customer Copyright Commitment used to require customers to run the duplicate-detection filter to stay covered. As of April 3, 2026, Microsoft dropped that requirement for GitHub offerings and the filter is optional now. That’s a loosening in your favor, which is exactly why it’s worth noticing, because the condition moved once and it can move again. ( Microsoft)

License types

Currently v3. This is called “copyleft” to differentiate it from copyright. If you distribute a work based on GPL code, you distribute your source under the same terms. GPLv3 includes an express patent grant in section 11 and GPLv2 includes none at all. GPLv3 also added a cure provision in section 8, so if you stop violating, your license is reinstated provisionally, and permanently if the copyright holder doesn’t notify you within 60 days or if you cure within 30 days of a first notice. Used by Bash and GIMP. Works fine if you don’t distribute, or if you don’t mind open-sourcing your own work.

GNU LGPL. Like the GPL, but it distinguishes “based on” from “uses.” If you merely use the library you don’t have to publish your code. The trap in practice isn’t the distinction, it’s the obligations that attach even when you’re on the right side of it. You still owe the build scripts, and for static linking you still owe whatever a user needs to relink against a modified library. See the AVM case above.

GNU AGPL. This is the one to watch. It closes the software-as-a-service gap by treating network interaction as distribution, so if you run a modified AGPL program and let users interact with it over a network, you owe them the source. It’s an OSI-approved license, unlike SSPL, and its recent growth is mostly commercial vendors relicensing rather than new projects picking it. Grafana actually moved to it, off Apache 2.0, in 2021. Elastic and Redis didn’t move so much as add it, in 2024 and 2025, alongside the source-available licenses they already had. Both are tri-licensed now, and that matters to you, because when a project offers you three licenses you get to pick which one you’re taking.

Permissive. Do pretty much what you want, don’t hold the contributors liable, keep the attribution, and it carries an express patent grant in section 3, so contributors can’t sue you over patents covering the code they contributed, and that grant terminates if you file patent litigation alleging the work infringes. Used by Android and most of the Apache Foundation, and it’s the default for corporate-originated open source for exactly that patent reason.

MIT. About 170 words. Attribution and a liability disclaimer, and that’s it. Used by jQuery and Rails. Still the most common license by most measures, with a caveat about what “most common” means that I’ll get to shortly.

BSD and ISC. Effectively MIT with different wording. ISC is enormously common in the npm transitive dependency graph and almost invisible if you count repositories instead, which is that same caveat again.

The source-available family: BUSL, SSPL, Elastic License 2.0, FSL, Confluent Community and their relatives. Not open source, not proprietary in the shrink-wrap sense, and not interchangeable with each other. Treat each one as a bespoke commercial agreement, because that’s what it is. The generalization that holds up is that each one exists to stop a specific competitor from doing a specific thing, and you’re almost certainly not that competitor. But “almost certainly” is a different risk posture than “MIT,” and it belongs in a different bucket in your inventory.

Two sites worth bookmarking: the OSI license list and choosealicense.com, though note that the second one is built for people picking a license for their own project rather than for people consuming somebody else’s.

What “most popular” actually means

This is worth a short detour, because it’s the number everybody quotes and almost nobody reads correctly.

Black Duck’s 2026 OSSRA report, drawn from 947 commercial codebases audited between November 2024 and October 2025, lists MIT at 95%, Apache-2.0 at 93% and BSD-3-Clause at 88%. Those figures are the percent of codebases containing at least one component under that license. Add up the ten licenses on that list and you get about 670%, which tells you they were never shares of anything. So “MIT is 95%” doesn’t mean MIT is 95% of the code, or of the components, or of anything else. It means 95% of commercial codebases (almost every one) have at least one MIT component somewhere in them, which you already knew. ( OSSRA 2026)

Count packages instead and you get a different picture. An MSR 2024 study across 33.7 million versioned packages in Maven, npm, PyPI, RubyGems and Cargo found permissive licenses at 91% of usage, with MIT around 56% of all packages. ( MSR 2024)

Count what’s actually deployed and it shifts again. RedMonk’s 2026 analysis found that GPL-2.0 is 34 times more common on GitHub than in the deps.dev dependency graph, while ISC is 31 times more common in deps.dev than on GitHub. Same software universe, opposite rankings, and the only thing that changed was what got counted. GPL concentrates in standalone repositories that nothing depends on, and ISC concentrates in npm’s transitive graph, where nobody chose it deliberately. RedMonk also points out that a large majority of public repositories carry no license at all and get silently excluded from every analysis above. ( RedMonk)

So what developers choose when they publish and what enterprises ingest when they build are two different populations, and every license popularity chart is measuring one of them without telling you which. If you’re setting policy you want the second one, and most published charts give you the first.

One thing I’m not going to tell you is which way the permissive-versus-copyleft trend is running. RedMonk reports permissive peaking around 2022 and declining since. GitHub’s own quarterly licenses dataset, which is public and which you can go compute yourself, shows the opposite over the same window. They use different populations and different bucketing, so anybody stating that trend confidently is picking whichever dataset agrees with them.

For what it’s worth, that same GitHub dataset does show AGPL-3.0 roughly doubling as a share of pushing developers between early 2020 and early 2026, with the sharpest movement in the most recent quarters. People reach for the Elastic and Redis relicensings to explain that, and I’d be careful with it, because both of those projects added AGPL alongside other licenses rather than switching to it, and it isn’t obvious how a tri-licensed repository even registers in a dataset that files each project under one license. Something is moving. I couldn’t tell you what.

And the honest answer on how common source-available licenses are in dependency trees is that nobody knows. RedMonk’s assessment is that these licenses “are not measurable in a statistically significant way.” GitHub’s Innovation Graph tracks 30 SPDX licenses and BUSL, SSPL and the Elastic License aren’t among them. Neither instrument can see them at all, so any percentage you get shown for BUSL or SSPL dependency prevalence is made up. Not estimated. Made up.

Who’s asking now

In 2016 nobody outside your legal department cared what licenses you shipped. Plenty of legal departments weren’t paying much attention either. For a sense of how much has moved since then, the NTIA multistakeholder process that eventually produced the SBOM minimum elements hadn’t even been convened when the first version of this article ran. It was announced in June 2018 and first met that July. ( Federal Register)

That’s changed, though not as cleanly as the compliance vendors would like you to think.

The EU Cyber Resilience Act (Regulation 2024/2847) entered into force 10 December 2024, and if you sell software in the EU, you are the manufacturer it’s talking about. Reporting obligations for actively exploited vulnerabilities applied to manufacturers from 11 September 2026, and the substantive requirements apply from 11 December 2027. The open source sitting inside your product is inside the thing you’re now answerable for.

It also creates a lighter category, the open source software steward, for foundations and similar entities that sustain projects used commercially. Those obligations start later, in December 2027, and they land on the steward rather than on you. If you personally maintain something you aren’t monetizing, or you contribute to a project you don’t run, the CRA doesn’t reach you at all. ( European Commission)

The CRA does require an SBOM, in Annex I, “covering at the very least the top-level dependencies.” Three things most coverage gets wrong about it: it doesn’t name SPDX or CycloneDX, top-level is the legal floor rather than transitive depth, and there’s no publication requirement. It also doesn’t require license data.

Which brings me to the uncomfortable part. I wrote years ago that the license management some SCA tools do is an important issue, but it isn’t a security issue, it’s a business problem. Let me be precise about how narrow that claim is, because SCA and SBOMs are largely about security and should be. Knowing which of your components carries a known vulnerability, and being able to find every copy of it across everything you ship so you can chase it down and fix it everywhere, is exactly what they’re good for. Anybody who spent December 2021 trying to work out where all their log4j was knows precisely what that’s worth. That’s real security work. Getting a license wrong is a different kind of trouble. Nobody gets breached because you shipped AGPL code. You get sued, or you lose a deal in diligence, or you rip something out on somebody else’s deadline. That distinction is worth holding onto here, because the artifact everybody now points to for license data was built by people solving the security problem. If you assumed SBOMs were going to solve license compliance for you, go check the field list. The 2021 NTIA minimum elements had seven fields and license wasn’t among them, it showed up as a “recommended” field. SPDX 2.2 made license fields mandatory and then SPDX 2.3 relaxed them back to optional. CycloneDX has always treated license as optional. OpenSSF documented what that produces in the real world: generators emitting absent license fields, invalid placeholders like NULL and UNKNOWN instead of the specified NOASSERTION, and malformed expressions like "MIT, LGPLv2, BSD". ( NTIA, OpenSSF)

CISA’s 2026 minimum elements, released in July 2026, finally fix this. The list grew from seven fields to eighteen, and Component License is now one of them: “the identifier(s) for the license(s) under which the software component is available,” conveyed “in a machine-processable fashion, such as by using System Package Data eXchange (SPDX) license identifiers.” Nothing in that document is marked optional, and where you don’t know something you mark it unknown rather than leaving the field out. That’s the first major SBOM baseline to require license at all. (Five years after the NTIA minimum elements came out, which tells you roughly where license compliance has been sitting on everybody’s priority list.) Read it alongside OMB M-26–05, though, which rescinded the federal secure-software attestation mandates and left agencies “permitted, but not directed” to ask for SBOMs at all.

There’s a second problem sitting underneath the field list, and that Fedora example from earlier is the cleanest way to see it. CISA’s rule for when to regenerate is producer-triggered: “when a component producer issues a new build or release, they (or the SBOM author) should also generate a new SBOM to reflect the changes.” That’s the right trigger for the case everybody designs around, which is your own software changing. It’s the wrong trigger for what happened to Redis users. Fedora issued the build, your producer did nothing, a component got removed from the running system and a differently-named component from a different upstream project took its place, and no event in your pipeline ever fired.

Notice which way the license moved, too. Redis 7.4 was source-available and Valkey is BSD 3-clause, so a license policy scan run after that swap reports an improvement. Nothing escalates, because nothing looks wrong.

The reassuring answer here is that disciplined shops pin everything, so this can’t reach them. I sat on the NTIA working groups that produced the original SBOM minimum elements, and later on the CISA effort that inherited the program, and I wouldn’t lean on that answer. The bar it describes gets failed more often than it gets met, and being in a regulated industry doesn’t clear it for you. Validation is a statement about a process and an intended use, and it isn’t a guarantee that the build is reproducible. A build that resolves dnf install at build time, or that names a base image by tag instead of by digest, inherits whatever the distro decided that week, and plenty of validated products are assembled exactly that way and then patched in the field for years afterward. The artifact you filed and the system you fielded drift apart, and you can't see the drift, precisely because nothing in the pipeline reported a change.

What actually closes the gap is narrower than “have good change control.” Pin by digest. Generate the SBOM from the built artifact rather than from a manifest that describes your intentions. Regenerate on any input change instead of only on your own release. All three of those are ordinary engineering, and all three are rarer in practice than the compliance conversation assumes.

So here’s where the pressure actually comes from today. The EU is tightening while the US is loosening, the tightest real constraint on most teams is a vendor indemnity condition rather than a regulation, and the SBOM you generate isn’t a license compliance artifact unless you went and configured it to be one.

What to actually do

“Take the time before committing to a project” is the usual closing advice, and it isn’t something anybody can act on. So here’s the replacement.

1. Inventory by license, including transitive dependencies, and make it machine-readable. Not a PDF. Queryable is the floor: you should be able to ask “what do we have under BUSL” and get an answer in under a minute. But the whole direction of this tooling, from static analysis through SCA to SBOM, has been toward artifacts a machine reads instead of a person. So use SPDX identifiers, keep the output structured, and let the pipeline do the work. Pull every license on every build, compare it to the last build and to whatever policy you’ve actually written down, and flag what moved. More and more, the thing reading that file isn’t a person at all, and it can only act on what it can parse.
2. Make license delta a gate on version bumps, and track the support clock on your last acceptable version. Relicensing almost always lands on a new release rather than retroactively, as with Terraform 1.6.0, Akka 2.7, Elasticsearch 7.11, Redis 7.4 and Mapbox GL JS 2.0. So your pinned version is safe, and the exposure shows up the moment something upgrades you. Your dependency bot opens a showing a version diff and a changelog, and it doesn’t show you that the license changed inside that bump. Meanwhile the clock on the last version you can accept is running, because the vendor stops backporting security fixes to it. That second part is what forced Flink’s hand, and it’s the one to put a date on.
3. Classify into three buckets instead of two. Permissive, copyleft, and source-available. That third bucket isn’t really a licensing question, it’s a commercial one, and it needs a named owner and a renewal date rather than a one-time legal sign-off.
4. Read the Additional Use Grant on every BUSL component you depend on. It’s the only part of the license the licensor wrote, and it’s the part that can get rewritten for you when the company gets acquired.
5. For anything copyleft you ship on a device, make sure you can produce the build scripts, and for LGPL static linking, the relinkable objects. That’s the gap in every embedded enforcement action I could find, including the two that are currently live.
6. Decide your position on -generated code before somebody asks you in diligence. You’ve got three real options: rely on vendor indemnity and document its conditions, run a code-similarity check independent of the suggestion tool, or accept the exposure on purpose. Doing nothing while assuming your SCA tool has it covered isn’t one of the three, because structurally it doesn’t.
7. Add license to your SBOM configuration explicitly, and then validate the output. Don’t assume the generator populated it. The failure mode here is a field that’s present, empty, and wrong.

What I got wrong in 2016

The first version of this article ran in August 2016, and one sentence in it has aged badly enough to be worth quoting:

“Once you’ve accepted for example the MIT license (currently the most popular open source license) you’re ready for all projects that use open source components with that license.”

Clear the license type and you’re done. I wrote that without hesitating, because in 2016 it was true and because everybody said it. What it assumed is that the license is a stable property of the component, and for most of open source history it effectively was.

A few smaller ones while I’m at it. I described the GPL as including “an express grant of patent rights from the contributors,” in a paragraph that also noted it comes in many versions. GPLv3 does. GPLv2 doesn’t, and if patents matter to your business then that distinction is the whole ballgame. I left the AGPL out of the license list entirely, which was defensible in 2016 and would be negligent now. And I titled that same section “Patentability,” which is a real word that means something else: whether a thing can be patented in the first place. The section was never about that. It’s about what patent rights a license hands you and what suing costs you. Nobody called me on it for ten years, which tells you something about how closely any of us read our own headings.

But the first one is the one that matters. The most expensive open source licensing events of the last eight years didn’t happen to teams that chose badly. They happened to teams that chose correctly and then stopped looking.

Summary

Vibrant, actively maintained open source projects with licenses that are compatible with your business are still a great asset, and that part I’d write again word for word.

What’s changed is that compatibility isn’t something you establish once. So check the license before you adopt, and then keep checking, because the company that wrote it is still out there making decisions about its business, and you’re downstream of every one of them.

Check your licenses. Then check them again.

Originally published at https://codecurmudgeon.com on August 3, 2016.

Understanding Open Source Licenses was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

How Test Automation Accelerates Both Verification & Validation

Ensuring the correct operation, quality, safety, and security in embedded software is a substantial portion of the software activities for embedded systems. In large part, teams accomplish this through software testing and throughout development via analysis, traceability, documentation, and so on. Safety-critical software has rigorous approaches to verification and validation that are often codified in industry standards. It begs the question: what’s the difference?

What’s the Difference Between Verification & Validation?

The official definitions of validation and verification are defined in the IEEE Standard Glossary of Software Engineering Terminology.

Verification: The process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase.

Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements.

Barry Boehm wrote in Verifying and Validating Software Requirements and Design Specifications more succinct definitions:

Verification: “Am I building the product right?”

Validation: “Am I building the right product?”

These definitions get to the crux of the difference between these two key aspects of testing.

The Goal of Verification & Validation

The ultimate goal is to build the right product. More than that, it’s to ensure the product has the quality, safety, and security to ensure it remains the right product.

Verification is part of the software development process that ensures the work is correct. Software verification usually includes:

• Conformance to industry standards, ensuring process and artifacts meet the guidelines.
• Reviews, walkthroughs, inspections.
• Static code analysis and other activities on artifacts produced during development.
• Enforcing architecture, design, and coding standards

Validation is demonstrating that the end product meets the requirements. Those requirements encompass functionality plus reliability, performance, safety, and security.

For physical products, validation includes customers seeing, trying, and testing the product themselves. But for software, validation consists of the execution of the software and demonstration of it running. It typically involves:

• Code execution to demonstrate correct functionality.
• Execution in target environments.
• Stress, performance, penetration, and other non-functional testing.
• Acceptance testing to customers directly and often.
• Using artifacts from verification processes to illustrate traceability of requirements to end functionality, especially for specific safety and security functions.

It’s important to understand the differences between verification and validation goals, and that software development needs both. These activities are a major part of the effort that goes into software development. Organizations are always looking to streamline them without compromising safety, security, or quality.

How to Approach Verification & Validation

The V-model shows the approach for more formal verification and validation, which developing safety-critical software uses. It illustrates the activities at each stage of development and the relationships between them.

The V-model is good for illustrating the relationship between the stages of development and stages of validation. At each testing stage, more complete portions of the software are validated against the phase that defines it. However, the V-model might imply a waterfall development method. There are ways to incorporate Agile, DevOps, and CI/CD into this type of product development.

Verification, on the other hand, ensures that each stage is complete and done properly:

Verification involves reviews, walkthroughs, analysis, traceability, test and code coverage, and other activities to make sure teams are building the process and the product correctly. As an example, the execution of unit tests is a validation activity, and ensuring traceability, code coverage, and testing progress of the unit tests is verification. The key role of verification is to ensure building delivered artifacts from the previous stage to specification and in compliance with company and industry guidelines.

Verification and Validation Naming Confusion

Organizations are likely to use verification and validation in slightly different ways. It’s common practice to consider validation an activity that happens near the end of software development where teams present the product to the customer (or testers acting as their proxies) and demonstrate meeting all the requirements. Embedded development still uses the concept of a factory acceptance test (FAT).

Another notable difference in philosophy is DO-178B/C and related standards for the development of safety-critical avionics software for which validation isn’t a known term. In fact, validation is considered redundant if verification is complete.

“Validation is the process of determining that the software requirements are correct and complete. DO-178C does not provide guidance for software validation testing because it is reasoned that software that is verified to be correct should, in theory, have no validation problems during software integration testing, unless the software requirements are incomplete or incorrect.” — Certification of Safety-Critical Software Under DO-178C and DO-278A, Stephen A. Jacklin, NASA Ames Research Center

Although I think Boehm’s definition corresponds to the more common usage of the terms, there are likely people who might consider unit and software integration testing as verification steps rather than validation.

Hybrid DevOps Pipelines for Safety-Critical Software

In many embedded software organizations, the implementation of a fully Agile process isn’t compatible with the restrictions that industry safety and security standards place on them. Artifacts, code, test results, and documentation often have required and set delivery dates. Progress is based on these deliverables (milestones).

In some cases, such as large military and defense projects, milestone deliverables are built into the contract and payment arrangements. Although this implies a waterfall approach, there’s no reason to limit software development to it. Teams can use hybrid models to achieve milestones for deliverables using iterative and Agile methods internally.

The reason to bring this up in a discussion of verification and validation is that teams can use many of the benefits of continuous integration and testing on complex safety-critical applications. Part of that is shifting left verification and validation to as early in the development process as possible. For example, there’s no reason to delay unit testing until all the units are coded or to wait to analyze code with static analysis until it is ready for integration.

Similarly, developers should attempt integration testing as soon as there are unit tested components ready. Combining automation with a continuous, iterative approach provides huge benefits for software validation and verification. Parasoft has tools that address testing, quality, and security at all phases of the SDLC as shown below.

The V-model shows the approach for more formal verification and validation, which developing safety-critical software uses.

Accelerating Verification

Verification involves the work to ensure each phase of development is fulfilling the specification of the previous step. In terms of software coding and testing, verification is making sure that the code satisfies the module design and, ultimately, the high-level design and requirements above that.

Furthermore, verification ensures meeting project-level requirements. Such requirements include compliance with industry standards, risk management, traceability, and metrics (code coverage and compliance). Parasoft’s software test automation tools accelerate verification by automating the many tedious aspects of record keeping, documentation, reporting, analysis, and reporting:

• Use static analysis as early as possible to ensure quality and security as developers write code. Further, static analysis prevents future bugs and vulnerabilities, reducing the downstream impact of bugs missed during inspection and testing.
• Automating coding standards compliance to reduce manual effort and accelerate code inspections.
• Two-way traceability for all artifacts to make sure requirements have code and tests to prove they are being fulfilled. Metrics, test results, and static analysis results are traced to components and vice versa.
• Code and test coverage to make sure all requirements are implemented and to make sure the implementation is tested as required.
• Reporting and analytics to help decision making and keep track of progress. Decision making needs to be based on data collected from the automated processes.
• Automated documentation generation from analytics and test results to support process and standards compliance.
• Standards compliance automation to reduce the overhead and complexity by automating the most repetitive and tedious processes. And, tools can keep track of the project history and relating results against requirements, software components, tests, and recorded deviations.

Watch On-Demand Webinar

Accelerating Validation

Validation is proving a product meets its requirements where the execution of code is necessary either in isolation for unit tests or in various stages of integration. Automating these suites of tests is a huge time saver for embedded software development.

Validation requires execution on target hardware. Optimizing regression testing makes the best use of available resources, people, and hardware. Parasoft test automation tools accelerate the validation process by reducing the dependence on manual testing-maintaining traceability and code coverage from all results:

• Automation of all test suites minimizes manual testing and reduces the testing bottleneck from limited hardware availability.
• Target and host-based test execution supports different validation techniques as required.
• Shift-left testing starts as soon as teams develop code. It leverages unit testing frameworks and automatically generates harnesses to test as soon as code is ready. Support for test-driven development and continuous testing is available as an organization’s process matures.
• Manage change with smart test execution to focus on tests only for code that changed and any impacted dependents.
• Two-way traceability among code, tests, static analysis results, and requirements and support for company-wide application lifecycle management (ALM) tools.

How AI Is Accelerating Verification & Validation

AI is extending test automation by helping engineers act on verification and validation results more efficiently. Rather than replacing established engineering practices, AI can reduce the manual effort required to investigate findings, remediate problems, create tests, and close coverage gaps.

With Parasoft C/C++test, AI-assisted workflows can help developers understand and remediate static analysis violations. AI can use information from the analysis, including the violation, coding rule, and supporting documentation, to provide context and suggest fixes. These capabilities can be incorporated into developer and CI workflows, helping teams address quality, security, and compliance issues earlier in development.

AI can also accelerate testing. Parasoft C/C++test supports AI-assisted unit test generation to help developers create tests and expand coverage. For teams using existing C and C++ testing frameworks such as GoogleTest, Parasoft C/C++test CT can use AI-assisted workflows to analyze coverage gaps, including MC/DC coverage, and help identify additional test conditions needed to exercise missing paths.

This is particularly valuable in safety-critical development, where simply generating more code or tests isn’t the objective. Teams still need objective evidence that requirements have been verified, software has been adequately tested, required coverage has been achieved, and results can be traced and documented. AI can accelerate the work, while established verification and validation techniques provide the evidence needed to demonstrate software quality, safety, security, and compliance.

In this way, AI becomes another layer of automation across the V-model: helping engineers investigate issues, create and improve tests, close coverage gaps, and move from verification results to corrective action faster while keeping engineers in control.

Summary

Software validation ensures that teams build the right software to meet customer and marketplace requirements. Validation is proof that you meet requirements and that your product is reliable, safe, and secure to protect your customers.

Software verification ensures that teams build the product in accordance with your organization’s own processes and standards and those required by the marketplace. In other words, validation proves the product works while verification ensures that you cross all the t’s and dot all the i’s.

Validation and verification consume a large part of the resources in embedded product development. Parasoft’s software test automation suite provides a unified set of tools to accelerate testing by helping teams shift testing left to the early stages of development while maintaining traceability, test result record keeping, code coverage details, report generation, and compliance documentation.

Request a Demo

Originally published at https://www.parasoft.com on September 29, 2023.

Verification vs Validation in Embedded Software was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

Autonomous driving is all the rage. Every week, tech marketing teams herald the dawn of fully autonomous freight, while social media endlessly bickers over neural nets and machine vision.

We like to think mobility is moving faster than ever. But if you look at the fundamental engineering trade-offs we’ve made over the last century, we haven’t moved forward, we took a massive step backward.

We spent 100 years building dumber transportation, and now we’re spending billions trying to match what a 19th-century farm animal did right out of the box.

The Century-Long Downgrade

There is a great scene in Robert A. Heinlein’s Time Enough for Love where a time traveler visits rural America just before World War I. He gives a local country doctor a ride home in his fancy automobile. You’d think the doctor would be thrilled by the modern marvel, but instead, he’s complaining.

His problem? When he finished a brutal 36-hour shift, he used to climb into his horse-drawn buggy, nod off, and let the horse take him home. The horse knew the route. It didn’t plunge off embankments, it didn’t smash into trees, and if the doctor fell completely asleep at the reins, he still woke up safe in his driveway.

With the shiny new “horseless carriage,” one second of fatigue meant wrapping the vehicle around an oak tree.

Sure, a horse is undeniably slower than a modern vehicle. But when you are exhausted at 2:00 AM, arriving safely at 6 miles per hour beats ending up in a ditch at 60. Unfortunately, our modern transportation infrastructure doesn’t give us that choice.

When we transitioned from horses to internal combustion engines, we removed biological intelligence from the loop and replaced it with an inert hunk of steel that knew absolutely nothing. For over a century, cars have been completely blind and stupid. Today’s push toward “autonomous AI” is just an elaborate, expensive attempt to claw back the baseline situational awareness a country doctor took for granted in 1910.

Why Ground Autonomy Is Such a Mess

People love to ask: Why have we had reliable aircraft autopilot for decades, while consumer car autonomy still panics over highway paint?

Because flying in clear air is a vastly simpler engineering problem.

In aviation, the sky is largely empty. You don’t have pedestrians crossing at altitude, no potholes, and no erratic tailgaters. More importantly, the system relies on structured external infrastructure: Instrument Landing Systems (ILS) and precise air traffic telemetry feed the aircraft exact vectors, glide slopes, and corridor boundaries.

Ground vehicles have none of that. We don’t have transponders embedded in the asphalt guiding our cars down every lane. Instead, we force vehicles — some relying purely on optical cameras, others juggling radar and LiDAR suites — to interpret an inherently hostile environment:

• The Highway (On-Ramp to Off-Ramp): This is theoretically the “easiest” slice of autonomy, but it’s loaded with caveats. Add torrential rain, sharp curves, stop-and-go speed whips, and aggressive drivers cutting across your nose with inches to spare, and the system easily gets overwhelmed.
• City Surface Streets: A relentless sensory circus. Traffic signals, unpredictable cyclists, jaywalkers, and someone diving off a curb into traffic to chase a runaway dog or rolling object.
• Edge-Case Chaos: The absolute death of brittle logic. An optical system mistaking the broad white side of a turning semi-truck for empty horizon, or emergency vehicles blowing through red lights and driving on the wrong side of the road — violating every standard traffic rule the machine expects.

Machine Learning vs. Real Intelligence

Let’s be clear about the terminology. Modern driving suites aren’t general artificial intelligence. They are narrow machine learning models processing raw sensor streams against fixed parameter thresholds.

They lack context.

I’ve seen this firsthand. On the highway with lane-keeping active, my car has spotted a dark patch of fresh asphalt, misidentified it as a catastrophic pothole, and jerked the steering wheel at 65 mph.

Think about that logic: the vehicle would rather execute an evasive swerve, potentially side-swiping the car in the next lane, than roll over a harmless dark circle on the road. That isn’t intelligence; it’s an algorithmic panic attack.

A horse may not understand the trailer attached to it, but it possesses hard-coded biological self-preservation. It won’t walk into a ditch, it won’t barrel into another animal, and it certainly won’t jump into oncoming traffic to dodge a shadow.

Until autonomous platforms can parse basic physical context and self-preservation the way a biological system does, we aren’t engineering super-intelligence. We’re just spending billions trying to upgrade our cars to the common sense of an average 19th-century mare, like, say, a Mustang.

Originally published in 2020 as a video.

Your “Smart” Car Is Dumber Than a Horse was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.

Choosing the right embedded unit testing tools requires more than selecting a popular test framework. Embedded C and C++ teams must account for hardware dependencies, cross-compilation, host versus target execution, test doubles, structural code coverage, and, in regulated environments, traceability and compliance evidence-the embedded unit testing fundamentals that shape which tool actually fits.

The best choice depends on both of the following:

• How developers want to write tests.
• How the organization needs to verify software across the lifecycle.

Best Unit Testing Tools for Embedded Software at a Glance

Embedded teams have several strong choices, but they do not all solve the same problem. Some tools provide a complete verification environment, while others focus primarily on test authoring.

Some provide a complete verification environment spanning static analysis, coverage, traceability, CI/CD automation, compliance reporting, and AI-assisted verification. Others focus primarily on test authoring. The table below highlights where each option fits, so you can match the tool to your team’s scope of work.

How We Evaluated Unit Testing Tools

This comparison evaluates unit testing tools against the needs of embedded C and C++ development rather than popularity alone. Key criteria include:

• Compiler and cross-compiler support
• Execution on hosts, simulators, emulators, and physical targets
• Creation of test harnesses, stubs, and mocks
• Structural coverage, including MC/DC where required

We also consider:

• Requirements traceability
• Reporting
• Functional safety and qualification support
• IDE and command-line workflows
• Build-system and CI/CD integration
• Ability to retain existing test frameworks and assets
• AI-assisted verification capabilities like test generation, coverage gap analysis, and remediation assistance

These criteria matter because embedded unit testing is often part of a larger verification process. A framework that makes it easy to write tests may still require additional infrastructure for target execution, coverage, traceability, and audit evidence. AI can further reduce manual effort, but teams should distinguish between AI that simply generates tests and AI that helps engineers complete broader verification tasks.

Parasoft publishes this comparison and offers C/C++test and C/C++test CT, which are included below alongside other tools.

Best Commercial Unit Testing Platforms for Embedded Software

Commercial unit testing frameworks go beyond basic test authoring, adding the capabilities most embedded teams need-execution on target hardware or simulated environments, structural coverage analysis, requirements traceability, and built-in reporting for standards like ISO 26262, DO-178C, and IEC 62304-all in one integrated package.

1. Parasoft C/C++test and C/C++test CT

Overview

Parasoft C/C++test and C/C++test CT support embedded C and C++ teams that need unit testing as part of a broader software quality, compliance, and verification workflow.
C/C++test provides guided unit testing, while supporting host and embedded target execution. It also connects unit testing with static analysis, structural coverage, including statement, branch, and MC/DC, requirements traceability, and centralized reporting through Parasoft DTP.

Through Parasoft’s MCP-enabled AI capabilities, engineers can generate unit tests, identify edge cases, create mocks and assertions, and expand code coverage.

C/C++test CT serves teams that prefer developer-authored frameworks that let them retain existing tests while adding coverage, bidirectional traceability, target-oriented workflows, CI/CD automation, and compliance evidence-for example, with its certified GoogleTest integration.

C/C++test CT additionally extends AI-assisted verification into MC/DC closure by analyzing coverage gaps, identifying uncovered conditions and decision outcomes, recommending missing test vectors, generating targeted tests, and assisting with coverage justification. Parasoft also applies AI to static analysis remediation and developer guidance.

This breadth is especially valuable in safety- and security-critical development, where AI-generated artifacts remain reviewable, and verification evidence must remain controlled and auditable.

Best for: Embedded teams that need unit testing integrated into a larger verification and continuous compliance process, rather than as a standalone task.

Key Capabilities

Core C and C++ unit testing capabilities include:

• Automated or guided generation of tests, mocks, stubs, and assertions
• Host and embedded target test execution
• Statement, branch, and modified condition/decision coverage
• Requirements traceability and compliance reporting
• Integration with static analysis

Embedded and Compliance Fit

Parasoft C and C++ testing tools fit teams working under functional safety or security standards where test evidence has to hold up to audit, not just pass a build. Because traceability, coverage, and reporting are part of the same workflow rather than bolted-on tools, evidence stays consistent as projects scale across teams, targets, or standards. Organizations without formal certification requirements may not need this level of governance, and should weigh it against tools with a lighter footprint.

Evaluation Considerations

Teams should determine whether C/C++test or C/C++test CT better fits their existing workflow. C/C++test is appropriate for organizations seeking a built-in, guided testing framework, while C/C++test CT is designed for teams retaining GoogleTest or another supported framework.

2. VectorCAST

Overview

VectorCAST is a commercial proprietary platform for unit and integration testing of embedded C and C++ software.

Best for: Established safety- and mission-critical verification programs.

Key Capabilities

• Test environment and harness creation
• Execute on-host and target platform
• Structural code coverage
• Requirements-based verification

Embedded and Compliance Fit

Its focus on regulated embedded development makes VectorCAST a natural candidate for organizations with formal verification processes or existing investments in the Vector ecosystem.

Evaluation Considerations

Choose VectorCAST if your pipeline prioritizes execution speed and a minimal footprint. It uses lightweight, container-friendly test execution tailored for ephemeral Docker agents in decentralized CI systems.

3. LDRAunit and LDRA Tool Suite

Overview

LDRAunit a standalone unit and integration testing tool for embedded software, while the broader LDRA Tool Suite expands into software analysis, traceability, coverage, and standards-oriented assurance.

Best for: Requirements-driven software assurance and compliance.

Key Capabilities

LDRAunit

• Unit testing
• Integration testing

LDRA Tool Suite

• Software analysis
• Traceability
• Coverage
• Standards-oriented assurance

Embedded and Compliance Fit

Together, these offerings address host and target execution, test automation, structural coverage, requirements-driven verification, and reporting for safety- and security-critical development.

Evaluation Considerations

Organizations evaluating LDRA should first determine whether they need the focused unit testing product or the broader suite. That distinction can affect how testing, analysis, traceability, and compliance activities are assembled across the development lifecycle.

4. Cantata

Overview

Cantata is a commercial C and C++ unit and integration testing solution designed for software running on native hosts and embedded targets.

Best for: Dedicated regulated C/C++ unit and integration testing.

Key Capabilities

• Automated test framework and harness creation
• Stubbing and wrapping
• Call interception
• Error injection
• Structural coverage
• Test reporting

Embedded and Compliance Fit

These features make it relevant for regulated and safety-related development where teams need controlled, repeatable dynamic testing.

Evaluation Considerations

When evaluating Cantata, embedded teams should consider whether their primary requirement is a specialized dynamic-testing environment or a broader verification workflow. This is an important distinction when testing must connect with static analysis, requirements, CI/CD quality gates, and centralized compliance evidence.

5. TESSY

Overview

TESSY is designed for unit and integration testing of embedded C and C++ software across a range of target systems. Its workflow emphasizes structured test design and execution, requirements traceability, regression testing, and structural code coverage. Capabilities such as support can be useful for teams following highly structured or requirements-led verification processes.

Best for: Requirements-based embedded unit and integration testing.

Key Capabilities

• Classification tree-based test design
• Variant-oriented testing
• Fault injection

Embedded and Compliance Fit

TESSY is a relevant option for safety-related development where test design itself is a central part of the engineering methodology.

Evaluation Considerations

Teams should evaluate how that methodology fits their developers, existing test assets, target environments, and automation strategy.

MathWorks Polyspace TestPolyspace Test

Overview

MathWorks Polyspace Test supports authoring, managing, and executing C and C++ unit and integration tests using graphical workflows and an xUnit-style API.

Best for: Requirements-based C/C++ unit and integration testing within embedded and functional safety workflows.

Key Capabilities

• Test execution
• Stubs and mocks
• Requirements traceability
• Regression testing
• Structural coverage
• Host and embedded-target execution
• Test generation for coverage objectives and boundary conditions

Embedded and Compliance Fit

MathWorks Polyspace Test can support coverage objectives such as MC/DC and fits naturally with organizations already using MathWorks or Polyspace engineering workflows.

Evaluation Considerations

Teams should evaluate supported targets, test-authoring preferences, integration with their existing MathWorks environment, and how dynamic testing connects with static analysis and compliance activities.

Best Open-Source Unit Testing Frameworks for Embedded Software

Open-source frameworks give teams the core building blocks for writing and structuring unit tests, but they typically stop there. Running tests on real embedded targets, generating audit-ready coverage and traceability reports, and meeting compliance standards like ISO 26262 or DO-178C usually requires pairing them with additional tools or custom in-house infrastructure.

6. GoogleTest and GoogleMock

Overview

GoogleTest is a widely adopted C++ testing framework with assertions, fixtures, parameterized tests, and other features familiar to developers, while GoogleMock helps isolate dependencies through mocking.

Best for: Developer-led C++ unit testing.

Key Capabilities

• Writing tests

Embedded and Compliance Fit

C/C++test CT extends existing GoogleTest workflows with code coverage, traceability, embedded execution, CI/CD automation, standards-oriented reporting, and TÜV certification for safety-critical applications.

Evaluation Considerations

Embedded teams may need complementary capabilities for target execution, advanced structural coverage, requirements traceability, centralized reporting, and compliance evidence.

7. Unity, Ceedling, and CMock

Overview

Unity provides a lightweight C unit testing framework, CMock generates mocks and stubs, and Ceedling coordinates builds and test execution. The tradeoff is that organizations generally assemble and maintain additional infrastructure for target execution, structural coverage, traceability, reporting, and compliance.

Best for: Lightweight embedded C testing.

Key Capabilities

• Generate mocks and stubs.
• Coordinates builds and test execution.

Embedded and Compliance Fit

A flexible open-source ecosystem for embedded C teams that want control over their testing stack.

Evaluation Considerations

For teams that want a lightweight foundation and can maintain the supporting target, coverage, traceability, and compliance infrastructure. And whose verification needs do not extend beyond test authoring.

8. CppUTest

Overview

CppUTest is a lightweight xUnit-style framework designed for C and C++ with an emphasis on portability and support for testing and mocking in embedded environments.

Best for: Portable embedded C and C++ testing.

Key Capabilities

• Testing
• Mocking

Embedded and Compliance Fit

Portable framework for smaller or less regulated C and C++ projects.

Evaluation Considerations

CppUTest can be a practical foundation for smaller projects or teams that prefer to assemble their own testing infrastructure. As verification requirements grow, however, separate solutions may be needed for target integration, structural coverage, requirements traceability, centralized reporting, and compliance evidence.

Commercial Platforms vs. Open-Source Frameworks

Commercial embedded testing platforms and open-source unit testing frameworks address related needs but operate at different levels of the verification problem.

Open-source frameworks such as GoogleTest, Unity, and CppUTest can be excellent choices when the primary goal is developer-authored testing, and the organization is prepared to build and maintain the surrounding verification infrastructure.

For safety-critical development, however, the distinction becomes much more significant.

Open-source frameworks generally do not come with the independent tool certification, qualification support, documentation, or compliance evidence required to establish confidence in the testing environment. So teams may need to perform and document their qualification activities while integrating the following capabilities:

• Embedded-target execution
• Structural coverage like MC/DC
• Requirements traceability
• Reporting
• Audit evidence

Commercial solutions designed for safety-critical development can substantially reduce this burden.

Independent certification from organizations such as TÜV SÜD provides objective evidence that a testing solution has been assessed for use in functional safety development workflows. This can be particularly important for standards like ISO 26262, IEC 61508, IEC 62304, and EN 50716, where tool confidence and qualification must be addressed.

How to Choose a Unit Testing Tool for Embedded Software

Start with the realities of your software and development environment. Is the codebase C, C++, mixed, legacy, generated, or model-derived?

Confirm that each candidate supports the following parts of the toolchain the project uses:

• Compilers
• Cross-compilers
• Debuggers
• IDEs
• Build systems
• RTOS environments

Next, evaluate where tests must run.

Host execution may be sufficient for some components, while others require simulators, emulators, processors, or physical embedded targets, particularly when code coverage on an embedded target is required. Determine:

• Can the tool create and maintain the required harnesses, mocks, stubs, and fault-injection scenarios?
• Can the tool collect statement, branch, or MC/DC coverage where required?

AI assistance is increasingly worth evaluating as well.

Determine whether AI is limited to basic test generation or can help with edge cases, mocks, assertions, coverage-gap analysis, MC/DC closure, static-analysis remediation, and other verification tasks. For regulated development, also consider whether AI-generated artifacts remain reviewable and compatible with the organization’s verification process.

Governance is equally important.

Safety- and security-critical teams should examine:

• Requirements traceability, reporting, tool qualification support
• Compliance evidence
• How results are managed across projects and releases

For functional safety projects, also determine whether the tool has been independently certified by an organization such as TÜV SÜD for use in safety-critical development workflows.

Independent certification can provide important evidence of tool confidence and reduce the qualification burden compared with adopting a testing framework that does not provide comparable certification or qualification support. Existing assets also matter. A team with a substantial GoogleTest suite should not assume it must abandon those tests to gain stronger embedded verification.

Finally, evaluate automation and scale. Look at command-line use, CI/CD integration, containers, centralized analytics, and how results from static analysis, testing, coverage, and requirements can be brought together.

The best validation is a proof of concept using your own code, compiler, target, test assets, coverage objectives, and compliance requirements.

Which Unit Testing Tool Is Best for Embedded Software?

There’s no single best unit testing tool for every embedded project. The right fit depends on how your team writes tests, where they need to run them, and how much verification and compliance evidence the project requires.

• GoogleTest, Unity/Ceedling/CMock, and CppUTest are strong foundations for teams prioritizing lightweight developer-authored tests.
• TESSY emphasizes structured requirements-based test design.
• Cantata specializes in regulated dynamic testing.
• VectorCAST, LDRA, and Polyspace Test address broader safety-critical verification needs.
• Parasoft C/C++test is well-suited when unit testing must connect with static analysis, structural coverage, requirements traceability, target execution, CI/CD, compliance reporting, and AI-assisted verification. AI helps generate tests and edge cases, create mocks and assertions, and remediate static-analysis findings.
• C/C++test combined with C/C++test CT analyzes and closes MC/DC coverage gaps. For teams already invested in GoogleTest or another supported framework, C/C++test CT provides a path to retain those tests while adding embedded verification capabilities.

If you’re still building a foundation in core testing concepts before comparing tools, our unit testing guide covers unit testing types, benefits, and best practices.

Evaluate Embedded Unit Testing With Parasoft C/C++test

The most useful way to evaluate an embedded unit testing solution is against the environment you actually need to verify. With Parasoft, teams can assess C/C++test or C/C++test CT using their own C or C++ codebase, compiler and cross-compiler, embedded target, existing test framework, coverage objectives, CI/CD pipeline, and functional safety requirements.

C/C++test is designed for teams that want unit testing integrated with static analysis, coverage, requirements traceability, and compliance reporting. Its MCP-enabled AI workflows assist with unit test generation, edge cases, mocks and assertions, developer guidance, and static analysis remediation.

C/C++test CT adds AI-assisted MC/DC coverage gap analysis, missing test vector recommendations, targeted test generation, and coverage justification assistance. It’s a strong option when developers already use frameworks like GoogleTest and want to preserve those assets while adding target execution, coverage, traceability, and automated reporting.

That flexibility lets teams evaluate Parasoft C/C++test around the workflow they already have and the verification maturity they need to achieve.

Request a Demo

Unit Testing Tools FAQs

How do unit testing tools isolate hardware dependencies in embedded software?

Unit testing tools use stubs, mocks, and test harnesses to replace hardware dependencies such as sensors, peripherals, and drivers. This allows C and C++ units to be tested independently on a host or embedded target.

Can existing GoogleTest tests be reused with a commercial embedded testing platform?

Yes. Parasoft C/C++test CT extends existing GoogleTest workflows, so teams retain their tests while adding capabilities like embedded target execution, code coverage, requirements traceability, reporting, and CI/CD automation.

What should teams validate during an embedded unit testing tool proof of concept?

Test the solution with your actual code, compiler, target, and existing tests. Validate target execution, test automation, structural coverage such as MC/DC, traceability, CI/CD integration, reporting, and any AI-assistance capabilities. When developing safety-critical software, validate tool qualification and independent certification like TÜV SÜD.

How do embedded unit testing tools support legacy C and C++ code?

Stubs, mocks, and test harnesses allow teams to test legacy code without extensive changes to production software. Combining unit testing with static analysis and structural coverage can also identify defects, risky code, and untested functionality.

Can unit testing results be traced to software requirements and compliance evidence?

Yes. Advanced solutions such as Parasoft C/C++test can connect requirements with tests, results, and coverage to provide bidirectional traceability and support RTMs, compliance reporting, and audit evidence.

Originally published at https://www.parasoft.com on August 20, 2026.

8 Best Unit Testing Tools for Embedded Software was originally published in Commit to Code Quality on Medium, where people are continuing the conversation by highlighting and responding to this story.