Why developer-first SAST tools are the future of code security

Application security has a broad scope for teams that build and ship cloud native applications. The landscape spans many processes, tools, and team members, and includes anything from automating secure pipelines (hello DevSecOps) to open source security to cloud infrastructure security testing. Some of those application security testing methodologies focus on code security, and are officially recognized as static application security testing (SAST) tools—sometimes referred to as static code analysis tools.

If you’re not familiar with the technical term SAST, let’s begin with an introduction that covers the basics, and then learn how developer-first SAST tools are going to shape the security industry as a whole.

What are SAST tools?

SASTs are static application security testing tools that analyze source code to see how data flows from potential user input vectors all the way down to sensitive application program interface operations. For example, a SAST can identify if user input in a search box could potentially be used to trigger a database-related function that performs a query in an unsanitized, insecure, and unplanned way (a.k.a. a SQL injection security vulnerability).

Conventional SAST tools and why they failed

Static application security testing isn’t a new concept. In fact, there are many tools and companies that have ventured into this space decades ago. To understand what the future of code security looks like, we need to first look at how conventional SAST tools work and why we aren’t seeing them adopted more commonly as we would have liked to.

Traditional SAST tools are slow to run

In conventional security and DevOps teams, it’s not uncommon to hear feedback like,“the SAST is taking too long” or “Continuous integration? More like, continuously waiting for the SAST to finish!”It had become the norm for SAST tools to run for hours—or days—in the build or continuous integration (CI) phase as they analyzed source code repositories.

Some tweaks have been made to accommodate the need to provide faster results, such as by working with source code deltas, or scheduling the SAST CI job to run at night or over the weekend. However, these are workarounds that signal a tool is inadequate and unable to adapt to modern day development processes and expectations.

Security is usually misplaced in the SDLC

To handle their aforementioned delayed feedback loop, SAST tools had been implemented as a separate CI process, so as to not block developers with long-running assessments. But this misstep of embedding SAST tools in a CI conflicts very much with the original intention, as SASTs should be able to focus on source code. That means SASTs should be used while software is built, rather than being an afterthought that gets reviewed only in CI.

Embedding security tools in both your build and continuous integration processes is a great way to introduce security, but to not hinder developer’s productivity, these tools need to be fast and provide actionable feedback.

False positives lead to SAST tools abandonment

Another major pain point for SAST adopters is accuracy, or more specifically, the lack thereof. Traditional SASTs tend to create too many false alerts that trigger too many unnecessary notifications. Security alerts require a developer’s undivided attention, and when a significant amount of these notifications are false reports, it will slow down actual development.

False positives create frustration and antagonizes the application security team. This ultimately leads to developers ignoring security alerts as a whole, and abandoning the tool entirely.

Traditional SASTs can find, but can’t fix

Lastly, when a SAST tool's findings are actually accurate, they still don’t tell you how to fix your problem. This problem is rooted with how SAST tools were engineered to begin with. Originally, SAST tools were built with the security team in mind, AppSec and the like. This meant that the findings may lack context about the flow of execution, or may simply report the problem with a CWE code (known as a Common Weakness Enumeration, a description of a potential vulnerability).But if you weren’t a security expert already, a SAST wouldn’t help you remediate a problem or fix a vulnerability.

Those who were able to address the security problems were skillful application security experts and their community, and this created yet another bottleneck for security to be addressed. It also generated further frustration for developers who had been handed the results of a SAST tool scan, but couldn’t take action to fix the problems.

Modern developer-first SAST tools must increase developer productivity

At its most basic, a SAST is focused on code security. SAST tools find issues like sensitive data exposure, SQL injection, code injection and other sorts of vulnerabilities. Who introduced these security issues? Developers like you and me. So who should be fixing them? That’s right. Developers should also be the folks who fix them.

Developer-first  is the secret sauce of best-of-breed SAST tools, and that’s how Snyk is revolutionizing the application security space. Snyk has its roots in the developer-first mindset.

Let’s explore what it takes for a SAST to create a productive security experience for developers

Code security that is embedded in developer workflows

If developers are an essential ingredient in fixing security vulnerabilities, then a key feature of a  SAST tool is that it integrates in the most developer-friendly way possible.

Where do developers spend most of their time (besides Google and StackOverflow)?

1. In their IDE, such as IntelliJ or Visual Studio Code

2. In the command line interface (CLI), where they might interact with their Git repositories, run commands, debug, and manage their project’s source code and routines

3. In their code review activities

To be adopted, SAST tools need to help developers find and address security issues directly in the tools they already use. And the results need to be context-rich, so developers can find and fix security vulnerabilities in their code.

For developers that spend their days in an IDE, here is an example of the Snyk Code SAST tool in action, showing what a seamlessly integrated security tooling looks:

On the left side, it provides a list of potential vulnerabilities from poor secure coding practices. On the right side of the bottom panel, it provides a line-level context of how a vulnerable flow of data will manifest and can be exploited.

If you’re a developer who enjoys spending most of your time in terminal user interfaces, then a command line interface would be more appropriate for you. In this case, you can use the Snyk Code CLI exactly for these purposes.

In fact, if you’re a fan of Git hooks, such as running a linter, a test suite, or other automations  before developers commit or push their code, then you can use the Snyk CLI for these purposes as well.

Following is the output of running a code security test by Snyk CLI on the same project:

❯ snyk code test

Testing /Users/lirantal/projects/repos/goof ...

 ✗ [Medium] Cleartext Transmission of Sensitive Information
     Path: Users/lirantal/projects/repos/goof/app.js, line 12
     Info: http (used in require) is an insecure protocol and should not be used in new code.

 ✗ [Medium] Information Exposure
     Path: Users/lirantal/projects/repos/goof/app.js, line 27
     Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 77
     Info: This endpoint handler performs a system command execution and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 166
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 223
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [High] SQL Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 39
     Info: Unsanitized input from the HTTP request body flows into find, where it is used in an SQL query. This may result in an SQL Injection vulnerability.

 ✗ [High] Command Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 86
     Info: Unsanitized input from the HTTP request body flows into child_process.exec, where it is used to build a shell command. This may result in a Command Injection vulnerability.

 ✗ [High] Cross-site Scripting (XSS)
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 109
     Info: Unsanitized input from the HTTP request body flows into send, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS).

✔ Test completed

Test type:         Static code analysis
Project path:      /Users/lirantal/projects/repos/goof

8 Code issues found
3 [High]  5 [Medium]

Real-time security scan results

For any of the above mentioned developer workflows to be supported by a SAST tool, it needs to be fast enough to provide real-time security scan results. Being fast is a trait that supports secure coding from the start. It means that developers can find and fix security issues while they code, rather than have the security team or a DecSecOps integration find them only after a code push. The latter would potentially lead to more frustration, as the code now needs to be refactored and create unneeded churn and an overall slower process to release the changes.

Our frictionless approach to secure coding makes Snyk Code unique and helps it excel as a static code analysis security tool. How fast is Snyk Code? Try it out and see for yourself.

High accuracy, low false positives

Integrated workflows and quick feedback loops are important, but an often overlooked factor of good developer experience is the data itself.

Developers need to trust their tools in order for them to fully adopt and embrace them in their workflows. The quality of the security data which a SAST tool reports on will determine if developers will happily integrate such a tooling, or abandon it due to large false positive results.

To achieve its industry-leading accuracy, Snyk Code is backed by machine learning that’s been trained with real code security issues from all the open source projects on GitHub. It is then able to apply that knowledge to identify patterns in your own code. To further help train such machine learning models, the Snyk Code AI engine relies on Snyk’s very own hand-curated vulnerability database, and reference commits as its training set. All of this helps to significantly reduce false positives.

Empowering developers to fix code security issues

A StackOverflow thread is a developer’s best friend, right? Only partly joking, but developers do appreciate helpful examples, where others show them how coding issues are solved. So why should security related issues be any different?

Let’s look at an example where a SAST tool flags a potential command injection vulnerability, often referenced as CWE-78: improper neutralization of special elements used in an OS Command ('OS Command Injection'). That’s a mouthful, right? Developers don’t usually have the security background to understand CVEs, CWEs, their impact, or perhaps even how to fix them while following secure coding practices. That’s the problem that Snyk as a whole took on to solve.

It is quite possible that as a developer you don’t have any security expertise to fix this command injection issue in line 86 which uses an insecure Node.js API: exec(). So, what will you do if you are presented with such a security report telling you that?

Here is another area where Snyk Code outshines conventional SAST tools:it helps you solve the code security issues that it found. In the bottom right corner of the following screenshot from the IntelliJ IDE, you can see that for this Node.js project, Snyk Code is displaying commit diffs from several open source projects which address the code injection issue that is raised here.

Having this information developers can see how others have fixed similar security issues. With this broader context of the suggested fix, developers can make a more informed decision about the fix.

Summary

So in conclusion, developers need a SAST that can find security issues in their code, as well as in the open source dependencies they use. On top of that, their SAST also needs to be able to recommend actionable fixes for the vulnerabilities it finds. And to ensure adoption, developers need a SAST that's fast, accurate, and integrated into their tools and workflows. It may seem like a tall order, but any developer-first SAST needs have all of these capabilities in order to be effective — and that's exactly why all of these features are offered in Snyk Code. Check out  our SAST buyers guide  to help you choose the right SAST tool for your organisation.

Did you reach this far and are curious how SAST and DAST testing are connected?

What is SAST and DAST testing?

SAST is static application security testing, in which a tool only needs an application’s source code to perform source to sink analysis, and derive potential security vulnerabilities or weaknesses by the way data flows. DAST, being a dynamic application security testing procedure, requires an application to be live and running in an applicable environment, in which it can a tool can observe the traffic, crawl a the webpage, and generally automate interaction with the application, in order to determine if an application is vulnerable to security issues. Read more about SAST vs DAST, what is the difference and how to combine the two of them.