DEVOPSdigest

Static application security testing (SAST), which scans code to find vulnerabilities and bugs, is increasingly considered a best practice for detecting problems early in the development cycle.

When integrated into the development environment, SAST can detect fundamental security errors that can introduce vulnerabilities, and help developers avoid making similar mistakes in the future. It also reduces costs. Savings from finding and fixing vulnerabilities during development range from a low of 20% up to a high of 100% when a defect is detected at the initial design phase.

However, to gain broader adoption both within an organization and across the industry SAST must overcome several barriers based on lingering perceptions. Let’s look at these in more detail.

False positives

Easily the biggest criticism of SAST (and static analysis in general) is false positives or more importantly, the impression that the tools are imprecise and waste developer’s time. SAST is designed to balance incorrect warnings (false positives) with missed vulnerabilities (false negatives.)

Understanding warnings

Most Static analysis provides compiler-like warnings, but little more in the way of guidance and understanding of these alerts. Without detailed information including links to related software weaknesses (Common Weakness Enumeration or CWE reference) and complete trace information, developers are forced to determine the root cause of an alert on their own and whether it is a real vulnerability.

Developer overload

Developers are busy and under pressure to deliver on tight schedules. Modern continuous integration practices, while beneficial, do limit any slack time to tackle "extra tasks" that improve quality and security. It’s critical that SAST (and other security practices) be integrated into the developer workflow as seamlessly as possible. SAST should provide usable and actionable information for developers. A key aspect of this is prioritizing and focusing on critical vulnerabilities. A common cause of overload with SAST is to take on too much too soon.

Slowing development

Related to both the impression that SAST is imprecise or "noisy" and overloads developers, is the belief that it slows down development. Which often leads to relegating security testing until later in the development cycle. Proper integration of SAST into workflows and continuous integration/continuous development (CI/CD) pipelines is the key to improving security without impacting development velocity.

Missed vulnerabilities

SAST is effective for detecting certain classes of vulnerabilities. For example, vulnerabilities related to buffer overflows, memory management errors, and pointer misuse. SAST is also excellent for enforcing secure coding standards such as SEI CERT C/C++, MISRA C/C++ and even custom rules.

However, other classes of vulnerabilities such as configuration issues are more difficult to detect with SAST. This perception is interesting because organizations would certainly miss more vulnerabilities without SAST, which is meant to be used in conjunction with a comprehensive security-first approach to software development.

Removing SAST Roadblocks

Despite these barriers, there are ways to efficiently process and eliminate false positives in bulk. Software teams new to static analysis tend to want all the bells and whistles enabled until they get their first full analysis report. Configuration plays an important role in reducing human workloads by automatically prioritizing warnings based on risk.

Even for software teams that are motivated to integrate SAST into their DevSecOps pipeline, high rates of warnings can be a deterrent to getting the most out of testing early in the project when it benefits them most.

Here are three best practices to facilitate the adoption of SAST:

■ Filter and Focus: Filter viewed data from the SAST interface, focusing on what is most important for the project and assigning developers to fix critical issues in priority order.

■ Mark and Defer: Lower the priority, or change the state to "later," for example, on all or a subset of the warnings based on some set of conditions that are less crucial to the project.

■ Stop the Bleeding: Use the above techniques to temporarily defer existing warnings with the emphasis on fixing new defects that are introduced as code is changed or new code is developed.

To implement these recommendations, use a scoring system which indicates both the severity of an error and the likelihood of the analysis being correct. A high score indicates a possible serious error with a high confidence in being a true positive result versus a false positive. A filter could choose to ignore low scoring warnings to focus on high impact, high confidence warnings.

Visualization

Visual representation helps developers both understand the root cause of warnings and fix the detected bug more easily. This typically will include a detailed description at the location of the warning in the code, the path visualization in code and a visual call tree for more complex issues. This approach greatly reduces the average mean time for discovering the root cause of an alert and remediation. Meanwhile, SAST processes should be configured to record and maintain findings so investigating previously resolved warnings isn’t repeated with each analysis.

Toolchain Integration

Finally, SAST must be integrated within the software automation tool chain as well as development methodologies and processes. This is mainly due to the fact they can be used locally by developers on their desktop for instantaneous feedback and to analyze a complete build at the time of their choosing. Since SAST is completely autonomous from the development workflow, it can be invoked whenever it makes sense to check for bugs and security vulnerabilities in code as shown in the following diagram.

Integration points for SAST tools in a DevSecOps pipeline

Summary

Proper use of SAST in developer workflows and integrated development environments (IDE) is critical to moving security to the earliest stages of development, commonly known as shifting left. Implementing the best practices listed above will result in as little disruption as possible for developers, which will go a long way to alleviating the barriers to adoption and negative perceptions often associated with SAST.