Many Static Application Security Testing (SAST) tools struggle with false positives. They often report that a vulnerability is present, while, in reality, it does not exist. This inaccuracy weighs down the engineering team, as they spend productive hours triaging the false alarms. By setting a benchmark of false positives — a limit, above which is unacceptable — you can establish a point of reference or standard against which to measure the efficacy of your SAST tool.

Static application security testing (SAST) tools automatically scan the source code of an application. The goal is to identify vulnerabilities before deployment. SAST tools perform white-box testing, which involves analyzing the code based on inside knowledge of the application. SAST offers granularity in detecting vulnerabilities, providing an assessment down to the line of code.

Static Application Security Testing (SAST) is an effective and well-established application security testing technology. It allows developers to create high-quality and secure software that is resistant to the kinds of attacks that have grown more prevalent in recent years. However, the challenge with SAST is that it tends to produce a high number of false positives that waste the time of your engineering team. In this blog we take a look at SAST and the problem of false positives.

Everybody’s talking about securing the DevOps pipeline and shifting security left.. AppSec tools like SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and others that address issues in proprietary software have become staples of the developer’s security toolbox.

I conducted research based upon existing Python vulnerabilities and identified a common software pattern between them. By utilizing the power of our in-house static analysis engine, which also drives Snyk Code, our static application security testing (SAST) product, I was able to create custom rules and search across a large dataset of open source code, to identify other projects using the same pattern. This led to the discovery of a stored command injection vulnerability in Celery.

Today, we announced our entrance into the Static Application Security Testing (SAST) market. It’s a significant development for WhiteSource, which has until now been solely focused on open source software security. In this post, I explain why we decided to make this move beyond open source into proprietary code security, and the value it will bring to developers, security teams, and their organizations.