Embedded software: why SAST is not enough | Blog | Code Intelligence

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.

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 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.

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.

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.

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 Analysis vs. Static Analysis+Code Fuzzing

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.