Legacy SAST has grown stale: It’s time for a new approach

Static Application Security Testing (SAST) tools have been the foundation of application security programs for 2 decades, along with security code reviews and penetration tests. But any AppSec practitioner will tell you that after 20 years, SAST still generates 40-80% false positives. Marginal improvements are no longer good enough. It’s time for a complete re-think of what SAST must become in order to remain an essential tool that helps organizations reduce risk while accelerating software delivery.

Gartner defines SAST as:

Static application security testing (SAST) is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state.

Unlike other types of security scans, such as dynamic testing, SAST tools look at a snapshot of code in order to identify “vulnerabilities”. The most glaring problem with current SAST technology is that it is missing the context needed to fundamentally understand risk. This is why existing tools generate between 80% false positives with default configurations and 40% with constant fine tuning.

Legacy SAST tools are overwhelming for the AppSec engineer. As waterfall methodologies have shifted to agile, on-premises servers have moved to the cloud, and manual handoffs between Development and Operations teams have turned into “DevOps”, SAST hasn’t been able to keep up, constrained by its inherent inability to have a more in-depth and contextual knowledge of the code.

There is little differentiation between traditional SAST scanners. They all scan code, identify potential vulnerabilities like SQL injection or buffer overflows on a snapshot of code, and spit out a series of alerts that overwhelmed and overworked AppSec engineers have to manually investigate. Vendors have only made marginal improvements to reduce false positive rates and they will continue to spin their wheels without embracing a fundamentally new approach.

Code risk is multidimensional and it is no longer enough for a scanning tool to identify unknown vulnerabilities without context. SAST needs to become less “static” and evolve to examine new data sources and more intelligently analyze risk instead of producing endless streams of unhelpful vulnerability alerts, many of them false positives.

Ask yourself this question: is it better to mitigate a vulnerability categorized as “High Risk” on an internal application with low business impact that’s protected by multiple layers of security or a vulnerability categorized as “Medium Risk” that’s on your attack surface? The only correct answer is: it depends. To make an informed decision, you’d need to understand the relevant data, the business impact of a breach, the details of the existing security controls, and more. Now ask yourself which vulnerability is remediated first in most organizations.

Cloud-Native Application Security Testing is the next-generation of SAST

Static analysis needs to do four essential things in order to solve modern risks:

1. Analyze application code, Infra-as-Code, and open-source code in one engine and connect all code elements in a unified risk graph.
2. Enrich risk assessments with context by analyzing text from the commit message, pull request discussions, and user stories.
3. Profile developers’ knowledge and skill sets to enrich the risk assessment.
4. Enrich data from 3rd-party sources such as API Gateways and vulnerability scanners to generate more risk-based context and reduce false-positives.

These four fundamental enhancements combine to provide contextual insights that make findings more risk-based and actionable.

A New Approach: Contextual, Risk-Based, Cloud-Native Application Security Testing

Apiiro looks at application security testing using a new lens. Instead of providing vulnerability alerts, Apiiro focuses on risk, which is multidimensional. This is accomplished by understanding code, but going beyond to incorporate new sources of data that can provide AppSec practitioners with deep visibility into their applications – even allowing them to understand the applications better than their developers. On top of that, Apiiro automatically identifies critical risks that could impact the business across the SDLC, from design to code to cloud.

Apiiro automatically and continuously maps the attack surface of the application with asset discovery, followed by capabilities in a number of areas that are blind spots for existing SAST solutions:

1. Asset discovery. Discover your assets across the SDLC, including applications, security controls, data stores, infrastructure components, cloud configurations, APIs, and more.
2. Security at the Design. Leverage natural language processing (NLP) to semantically process design documentation, use cases, user stories, commit messages, and pull request discussions that indicate potential risks that may be added to the application.
3. Infrastructure-as-Code (IaC) security analysis. Identify cloud misconfigurations, vulnerabilities, and compliance issues and connect them to the application risks. Using this context, remediate configuration changes with business risk before they reach production.
4. Secrets in code. Continuously and automatically perform secrets discovery, remediation, and prevention so you can reduce risks as new secrets are committed to Git before reaching the cloud.
5. API security analysis. Identify sensitive APIs that expose sensitive data, missing security controls, and when inputs are not properly validated.
6. PII/Payment data exposure. Identify sensitive data exposures by combining an understanding of application data with infrastructure settings.
7. Architecture drifts / changes. Identify material changes/drifts and trigger a contextual threat model, security code review, or even a penetration test. Software is a living organism! Every day developers change the application logic and DevOps teams change the cloud infrastructure. Determining which changes matter is at the heart of any AppSec program.
8. Compliance violations. Continuously analyze code commit / PR for compliance violations (such as PCI and GDPR) and trigger the appropriate remediation workflows.
9. Supply chain attacks. Protect your development environments and SDLC to prevent your applications and CI/CD pipelines from being the source of a supply chain attack.