Skip to content
Natalia Kazankova

Why Static Analysis (SAST) isn’t enough to prevent critical bugs in embedded software

Static code analysis is widely adopted among organizations for its ability to provide fast feedback loops and identify bugs early in development. However, despite its advantages, numerous bugs and vulnerabilities remain undetected and are only found when they've made their way into production or been caught by late-stage penetration testing. The best security practice involves leveraging both static and dynamic testing, such as fuzz testing. Read on to learn the benefits of adding fuzzing to your code-testing toolkit.

Embedded software: why static analysis is not enough


What is static code analysis

Static application security testing (SAST) or static code analysis tools identify certain types of bugs and vulnerabilities in software by analyzing the source code without executing the program.

Despite widespread static code analysis use, vulnerabilities in embedded software are increasing

Static code analysis is widely adopted among organizations. According to Forrester’s research, 94% of companies use SAST.

Nonetheless, the number of uncovered vulnerabilities in embedded software is on the rise. For example, in the automotive space, each year the number of reported CVEs increases. Since 2019, more than 200 CVEs have been uncovered each year.

CVE counts automotive industry

CVE counts in the automotive industry from 2000 to the first half of 2023

Another example is medical devices. In 2023, there were 993 vulnerabilities within 966 medical products and devices, a 59% increase from 2022.

Identified vulnerabilities healthcare

993 vulnerabilities were found in 2023 spanning 966 healthcare products; these vulnerabilities can potentially be exploited by attackers to target healthcare organizations (source).

At the same time, 72% of manufacturing companies and 53% of healthcare companies have been adopting static analysis.

Graph - Plans to adopt static application security testing

Why SAST can’t prevent all vulnerabilities  

While static analysis has undeniable advantages, such as immediate feedback loops, the moment developers write code in the IDE, it also has a few disadvantages.

Reason #1: Some bugs and vulnerabilities cannot be identified through static analysis
Static analysis is valuable for identifying certain bug and vulnerability types by statically analyzing the code without executing the program. However, there are specific categories of issues in C/C++ code that may be challenging or impossible to detect solely through static analysis. Some examples include:

  • Runtime or Dynamic Behavior Issues: Static analysis may not capture issues related to the program's run-time behavior. Issues like race conditions, deadlocks, or majority of memory corruption problems might be missed.
  • Memory Buffer Overflows: These often occur during program execution, while static analysis tools analyze source code without executing it. 
  • Input-Dependent Flaws: Bugs based on specific input conditions or external factors during runtime may not be apparent through static analysis alone.
  • Integration and Environment-Related Issues: Problems arising from the interaction of different components or dependencies in a specific runtime environment might be challenging for static analysis to uncover.
  • Security Misconfigurations: Some security misconfigurations, especially those dependent on the actual deployment environment, may not be easily identified through static analysis.
  • Behavioral and Logic Flaws: Issues related to logical errors or flawed business logic, often context-dependent and emerge during runtime, may not be fully captured by static analysis.

Reason #2: The fatigue among developers due to false positives 
Static analysis produces many false positives (code that does not actually contain vulnerabilities) and duplicates (previously assessed findings that reappear). In large projects, it's common to encounter hundreds of thousands of warnings. This noise makes SAST considered unreliable, eroding the trust of developers and testers. Consequently, this leads to adoption issues and a 'crying wolf' situation. When SAST identifies another vulnerability, developers often dismiss it, as many previously flagged issues turned out to be false alarms, not actual vulnerabilities.

When teams turn off some checkers (security rules) to get fewer alarms, the risk of missing some crucial bugs increases. 

As a result, alternative testing technologies such as penetration, dynamic, or fuzz testing continue to reveal bugs and vulnerabilities in projects previously scanned by SAST.

Fuzz testing is gaining momentum

Fuzz testing, or fuzzing, is a dynamic application security testing method. During a fuzz test, a program is executed with invalid, unexpected, or random inputs, aiming to uncover vulnerabilities or crash the application.

More and more companies are turning to new application security technologies like fuzz testing. According to Forrester, 65% of security decision-makers are adopting fuzz testing, while 16% plan to implement it.

Adoption Fuzz testing tools

Tech corporations like Microsoft, Facebook, and Google were early adopters of fuzzing technologies to test their own systems. Since launching in 2016, Google's OSS-Fuzz, a free fuzzing platform for critical open-source projects, has helped fix over 8,800 vulnerabilities and 28,000 bugs across 850 projects, including libraries written in C/C++. As a common practice, such libraries usually get tested by SAST before undergoing fuzzing.  

In the realm of commercial C/C++ projects, companies with embedded systems turn to commercial fuzzing platforms like Code Intelligence.

How companies benefit from using both Static Code Analysis and Fuzz Testing

To maximize the strength of your security posture, it’s a best practice to use both SAST and fuzz testing. Integrating fuzz testing and SAST helps cover a broader range of potential issues early in development, reduce false positives and negatives, and meet compliance requirements.

  Static Code Analysis Static Analysis + Code Fuzz Testing 
End users Developers and Testing teams

Developers and Testing teams

Application knowledge Full Knowledge
Analyzes the internal structure of a program, understanding the entire context of the code.
Full Knowledge
Analyzes the internal structure of a program, understanding the entire context of the code.
Access to source code Required Required
Type of code analysis Static
Scans the source code without actually executing it.
Static + Dynamic
Scans the source code and the running application.
When executed Early in development Early in development and testing
Bugs&Vulnerability detection
  • Insecure coding practices
  • Malicious Code
  • Authentication and Authorization Issues
  • Code Tampering and Injection Flaws
  • Insecure coding practices
  • Malicious Code
  • Authentication and Authorization Issues
  • Code Tampering and Injection Flaws.
  • Memory Corruption Problems
  • Input Validation Issues
  • Protocol Parsing Flaws
  • Complex Logic Flaws
  • Interaction with External Systems
  • Environment-specific Issues
  • Security Misconfigurations
Results reliability  Low
Produces a large number of false positives and duplicates.
Fuzz Testing only flags actual issues with zero false positives.
Issues reproducibility Limited
Struggle to offer inputs that allow developers to reproduce identified vulnerabilities easily.
Code Fuzz Testing provides inputs that developers can use to reproduce bugs and pinpoint the exact location in the source code.
Integration into the development process Full
Runs directly from IDE.
Static analysis runs directly from an IDE, whereas code fuzz testing can be run through any IDE in the same way as unit testing.

Static Analysis vs. Static Analysis+Code Fuzzing

White paper - Fuzz Testing + Staticc Analysis (Mockup)

An automotive company using static analysis detects 32% of vulnerabilities solely through fuzz testing. Download a free white paper to learn the details, or book a demo to see fuzz testing in action. 

Related Articles