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

December 06, 2022

The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, announced the graduation of Argo, which will join other graduated projects such as Kubernetes, Prometheus, and Envoy.

December 06, 2022

Wib announced API PenTesting-as-a-Service (PTaaS) designed to help organizations proactively cover the latest PCI-DSS 4.0 mandates for testing application security, APIs, and vulnerabilities in Business Logic.

December 05, 2022

Harness announced Harness Cluster Orchestrator to allow customers to optimize their Kubernetes cloud workload costs and realize up to 90% cloud cost savings with Amazon Elastic Compute Cloud (Amazon EC2) Spot instances from Amazon Web Services (AWS).

December 01, 2022

Salesforce introduced a new Automation Everywhere Bundle to accelerate end-to-end workflow orchestration, automate across any system, and embed data and AI-driven workflows anywhere.

December 01, 2022

Weaveworks announced that Flux, the original GitOps project, has graduated in the Cloud Native Computing Foundation (CNCF®).

December 01, 2022

Tigera announced enhancements to its cluster mesh capabilities for managing multi-cluster environments with Calico.

December 01, 2022

CloudBees achieved the Amazon Web Service (AWS) Service Ready Program for Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances.

November 30, 2022

GitLab announced the limited availability of GitLab Dedicated, a new way to use GitLab - as a single-tenant software as a service (SaaS) solution.

November 30, 2022

Red Hat announced an expansion of its open solutions publicly available in AWS Marketplace.

November 30, 2022

Sisense announced the availability of the Sisense CI/CD Git integration module.

November 29, 2022

Codenotary announced TrueSBOM for Serverless, a self-updating Software Bill of Materials (SBOM) for applications running on AWS Lamda, Google Cloud Functions and Microsoft Azure Functions that is made possible by simply adding one line to the application source code.

November 29, 2022

Code Intelligence announced its open-source Command-Line Interface (CLI) tool, CI Fuzz CLI, now allows Java developers to easily incorporate fuzz testing into their existing JUnit setup in order to find functional bugs and security vulnerabilities at scale.

November 29, 2022

Parasoft announced the 2022.2 release of Parasoft C/C++test with support for MISRA C:2012 Amendment 3 and a draft version of MISRA C++ 202x.

November 28, 2022

Kasm Technologies announced the release of Kasm Workspaces v1.12, providing major enhancements to its portfolio of digital workspaces delivering Desktop as a Service (DaaS), Virtualized Desktop Infrastructure (VDI), Remote Browser Isolation (RBI), Open-Source Intelligence Collection (OSINT), Training/Sandboxes, and Containerized Application Streaming (CAS).

November 28, 2022

Cloud4C has achieved Amazon Web Services (AWS) DevOps Competency status.