SAST and SCA: Better together with Snyk

As applications become more complex, so does the task of securing them.

While the source code making up applications consists of proprietary code, a great deal of it is also third-party, open source code. Development and security teams looking to release secure code while also maintaining a rapid pace of development, need to therefore combine static application security testing (SAST) and software composition analysis (SCA) as part of a comprehensive software security strategy.

That’s easier said than done, though.

The older and more established testing strategy, SAST has traditionally been the logical application security approach to lead with. There are scores of SAST tools available for practitioners to select from, with well-documented methodologies and best practices to accompany them. SAST solutions, however, suffer from a nasty reputation when it comes to speed, accuracy, and overall ease of use. These negatives could dissuade a team from using SAST, or push them to choose SCA instead.

Traditional SCA solutions are not that much different, with a track record of being difficult to integrate with and a high rate of false positives. Despite the fact that vulnerabilities in open source packages have helped bring SCA into focus, SCA adoption is still marginal with only 38% of organizations confirming the use of open source security controls. And while they scan your dependencies (and their dependencies), SCAs cannot scan for vulnerabilities in the code you write.

But using both SAST and SCA independently runs counter to the growing preference by organizations to minimize tool sprawl and consolidate application security tooling and so the thinking process is often SAST or SCA rather than considering SAST and SCA as part of a combined approach.

In this post, we’ll take a look at why SAST and SCA is the right approach, and how to implement both without creating sprawl.

What’s the difference between SAST and SCA?

Understanding the difference between SAST and SCA will go a long way towards adopting a combined approach.

What’s SAST used for?

SAST is a structural application security testing methodology that scans the application source or byte code for security vulnerabilities, such as OWASP’s Top 10 and CWEs. Besides the source or byte code, it can evaluate a range of other sources such as documentation and specifications. Modern SAST tools transform the original code into an intermediate representation and perform various test types using a rule set commonly running on a logical solver.

The benefit of a SAST is that it covers all possible paths and states an application could be in and even discovers bugs that the developers initially were not looking for. When detected, these issues should be marked with their precise location or path through the application, including the file names and line numbers, along with additional information about the issue itself.

One downside of traditional SAST tools is that the tool vendor has to optimize between a triangle of showing true issues, showing all possible issues, and computing resources used. The tools, therefore, are a compromise by overestimating the behavior of applications, and accepting a certain rate of false alarms and overlooked issues in favor of computing time. Still, it sometimes takes days or even weeks to scan larger projects on traditional SAST tools.

What’s SCA used for?

Modern applications rely on dozens if not hundreds of open source packages often referred to as dependencies. In fact, 98% of applications contain open source software. These dependencies, in turn, rely themselves on other open source packages, called transitive dependencies. Open source packages cover a wide variety of tasks, ranging from simple tasks such as formatting text to more complicated frameworks and runtimes.

It is a common best practice to treat open source packages as a unit. Patching or changing the code is welcome as long as it is donated back to the package and merged into it. Local changes break the package versioning and changes might be overwritten when a new version of the package is downloaded.

SCA is an application security methodology that focuses on scanning applications for the open source dependencies being used, either directly or indirectly, and correlating this analysis with vulnerability data to track any known security vulnerabilities these dependencies might include. When detected, these vulnerabilities are flagged with information about the vulnerability itself and in some cases, also the recommended fix. Importantly, SCA also helps map the legal risk introduced via open source usage by identifying the licenses included in open source packages.

The case for using both SAST and SCA

Based on the functional differences between the two testing methodologies, it is clear that any apples-to-apples comparison is wrong.

While they do share some common denominators, such as being implemented early in the development process and testing source code, they cover two distinct core types of code building up an application with SAST helping to mitigate the risk introduced by the code written in-house and SCA helping to mitigate the risk introduced by code written outside the organization.

An effective application security approach, therefore, should seek to include security testing tools capable of managing and mitigating both types of risk. This type of approach results in comprehensive visibility across proprietary code and open source components, identification and remediation of issues earlier on and throughout the development lifecycle, and so overall minimizes risk.

Key requirements for a combined approach

Opting for a combined approach is not a straightforward decision, and implementing both SAST and SCA as part of an application security program can be culturally and technically challenging.

The DevSecOps model calls for more security ownership by developers, but past and present experience with traditional solutions makes it difficult for developers to adopt one testing methodology, not to mention two. Some teams might be more averse to adding yet another security tool into the mix of tools already being used.

The easy solution might be to integrate the SAST and SCA tools into the CI/CD pipeline and revert the findings back to developers. But this decouples the process and forces deployments to wait for scans and fixes to be applied. In the agile world of DevOps, delaying a release for weeks is simply not a viable option.

And so to be successful, a combined application security program can be enabled by solutions that are, first and foremost, developer-friendly. Developers are more likely to use SAST and SCA tools that integrate quickly, easily, and early into their existing development workflows than those that are slow, difficult to use and that can only be deployed during later stages of development.

Additionally, a consolidated workflow, where both SAST and SCA scanning takes place simultaneously or is facilitated within the same tool, reduces complexity for developers and overall costs for security.

The Snyk approach: Snyk Code and Snyk Open Source

The Snyk platform provides a combined SAST and SCA application security approach, enabling all the different parts of what make up an application today to be built both securely and rapidly.

Used in tandem, Snyk Code for SAST and Snyk Open Source for SCA, provide easy-to-use, self-help, fast and accurate testing, enabling developers and security teams to easily find, prioritize, and fix both security issues in their own proprietary code as well as known vulnerabilities in their open source dependencies, reducing risk and improving the pace of secure development.

The application is fixed before it enters the CI/CD pipeline, taking away the delay for scanning and the burden of triaging and filing issue reports and freeing up the application security team to focus on the overall security posture of the organization.

Snyk’s consolidated testing takes place early and across the development lifecycle, starting for example, within the IDE:

One tool, two scanning methodologies: Snyk’s JetBrains IDE plugin in action.

Scans are quick and results are presented in the developer workbench with clear and understandable explanations. A data flow through the application is overlaid with the original code including jumping through different files. Examples from open source projects are provided to illustrate how others tackled the issue in a similar context. Best of it all, since it is fast and unlimited, developers can scan small changes frequently and fix issues before they hit the source code version management system.

Snyk automatically implements consolidated scanning during other, subsequent stages of development. When importing a new project from GitHub, for example, Snyk automatically executes SAST (1) and SCA (2) testing on the source code within the repository:

A project imported into Snyk. SAST and SCA scanning results in one consolidated view.

Importantly, the Snyk platform is based on the Snyk Intel Vulnerability Database which combines several public sources, feedback from Snyk’s large development community, and Snyk’s own dedicated research team to provide the most comprehensive, most timely, and most actionable vulnerability data on the market. This ensures that scanning results and corresponding fix advice are accurate.

The Snyk UI offers the opportunity for development and security teams to regularly monitor their code base for recently uncovered vulnerabilities. In the case of the recent Log4shell vulnerability, for example, Snyk Open Source enabled Snyk users to easily and quickly run scans over their entire application codebase, identify vulnerable repositories, and act accordingly.  And using PR checks or integrating Snyk into a CI/CD pipeline, these tests can be automated and made mandatory.

Snyk is not licensed per scan, per line of code, or per project. Application security teams do not need to limit their scans to core projects or a set scanning frequency due to license costs and can scan as much code as they like and as often as they need.

Finally, the Snyk platform also scans for vulnerabilities in containers and infrastructure as code (as you may have noticed in an earlier screenshot), providing a holistic view across all the different parts of code making up an application.

The winner is… both

Combining SAST and SCA are better together, giving organizations a complete view of all the software being used.

The task of securing modern applications needs to be as agile as the processes driving their development. Using both tools is now a de-facto standard for application security and is increasingly a requirement for complying with various types of regulatory specifications, such as PCI DSS and various government initiatives around the globe tackling application security and the growth in software supply chain attacks.

Organizations seeking to deliver secure applications should not need to choose one methodology over another because of previous experience, bias towards one methodology, or even limited budgets. SAST and SCA provide indispensable and comprehensive visibility into ALL the source code making up an application and should therefore be key elements of any application security program.

Not sure how to get started with SAST and SCA?  Try Snyk for free!