How to Help Developers Make Friends with Security Testing
June 21, 2021

Walter Capitani
GrammaTech

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.

Walter Capitani is Director of Technical Product Management for GrammaTech
Share this

Industry News

January 13, 2022

Infragistics announced the release of Infragistics Ultimate 21.2.

January 13, 2022

Jitterbit acquired PrimeApps, a Turkey-based innovator in low-code application development.

January 13, 2022

Mirantis announced the release of Mirantis Secure Registry (MSR) 3.0, which supports usage across any Kubernetes distribution.

January 12, 2022

DevOps Institute announced its lineup for 2022 events and webinars and plans for two new DevOps certifications.

January 12, 2022

Oxeye unveiled an open-source initiative with the introduction of Ox4Shell.

January 12, 2022

Quali Torque platform is now available to Microsoft Azure users on the Azure Marketplace.

January 11, 2022

CircleCI announced a free tier for CI/CD.

January 11, 2022

GlobalLogic, a Hitachi Group Company, announced availability of OpeNgine version 2.1.

January 11, 2022

The Application Security Division of NTT introduced the next phase of The WhiteHat Vantage Platform, Vantage Prevent, a patented solution that enables enterprises to conduct dynamic application security testing (DAST) at each phase of the development cycle and prevent exploitable vulnerabilities from reaching production.

January 10, 2022

BrowserStack announced the acquisition of Nightwatch.js, the open-source test automation framework.

January 06, 2022

BMC announced new capabilities and integrations across its BMC AMI (Automated Mainframe Intelligence) and BMC Compuware portfolios.

January 06, 2022

ShiftLeft announced that its Intelligent-SCA product added scanning and attackability analysis for JavaScript (JS) and the TypeScript (TS) language to the ShiftLeft CORE platform.

January 06, 2022

Progress announced the latest release of Progress Fiddler Everywhere, its popular web debugging proxy tool.

January 05, 2022

Solo.io announced a new open-source project, BumbleBee, that simplifies the developer experience for building, packaging, and distributing eBPF tools.

January 05, 2022

Forty8Fifty Labs and Old Street Solutions announced that they are partnering in the development and delivery of solutions that simplify the collaboration and use of Atlassian Jira and Confluence.