SAST and SCA: Choosing the best tools to keep your data and apps safe

Modern applications are increasingly large and complex and so must look to increasingly more sophisticated tools to keep them secure. 

Developers and security experts have relied on two key categories of tools to keep their applications and data safe from intruders. The first is Static Application Security Testing (SAST), and the second is Software Composition Analysis (SCA). These two types of tools have different targets — SAST for testing in-house developed code, and SCA for managing imported open-source components. Ideally, application creators would use both, to cover both these areas for possible security flaws, but as we shall see, that’s been much easier said than done until recently.

SAST is a well-established security approach, with dozens of tools to choose from in the marketplace. It scans the application source code or byte code for known software vulnerabilities — defects that could allow an attacker to gain access. These tools automatically cover all possible paths and events an application could be in and can discover bugs that the developers weren’t even aware of, alongside the ones they were searching for. 

SAST tools do have some downsides, however. They have a reputation for being slow, for generating false positives and for being unwieldy to use. Ultimately, their creators will have had to make a compromise between how long it takes to run a test, how exhaustive the testing is, and the number of false positives deemed acceptable. Of course, none of these compromises are desirable, but historically, application developers have had to choose at least one.

Dependencies need attention too

Where SCA comes in is in helping to mitigate risks that lie outside the developer’s source code. The recent Log4Shell vulnerability brought to the foreground the potential impact of attacks against third-party and open-source software packages that are used as the underlying building blocks beneath owned applications.

Modern software applications might rely on hundreds of open source packages, described as dependencies. These dependencies then also rely on other open-source packages, which the developers might not even know about, called transitive dependencies. Open-source packages are available to cover thousands of operations and tasks developers would otherwise need to code for themselves: and there’s no point in reinventing the wheel. Thus, it should come as no surprise that 98% of applications contain open-source software, and upwards of 75% of the code in a given application will be open source. 

Unfortunately, though, the rigor and extent to which open-source packages are tested for security flaws can be very variable, especially with many packages that are no longer actively maintained. Many packages have multiple variants and older versions remain in active circulation.

SCA testing specializes in this domain, scanning applications for their dependencies and transitive dependencies, and correlating this with vulnerability databases to understand where risks and security flaws have been inherited from the code taken from outside the organization. Ideally, it will identify the type and severity of vulnerabilities found, and advise on fixes and workarounds. SCA also helps organizations cover their legal risks, by identifying the licenses included with packages, and any responsibilities or liabilities these might incur. 

Both SAST and SCA have a genuinely important role to play in the software development lifecycle. By combining both, developers can obtain a holistic view of their application’s security: SAST for testing your source code to find security vulnerabilities; and SCA as an application security methodology for managing open-source components. 

Unfortunately, though, many SCA tools, just like SAST tools, have a reputation for being difficult to integrate and creating large numbers of false positives. Perhaps, as a result, adoption remains low, with only 38% of organizations reporting use of open-source security controls. And combining both approaches has therefore found very little favor in the development community. While their flaws might be annoying in themselves, doubling the time required for testing and sifting through twice as many results for false positives has generated little appetite. But modern developments have seen the arrival of new tools that overcome these objections and offer a way forward that improves both security and speed.

What to look out for in SAST and SCA

In modern software development pipelines, which have thoroughly embraced CI/CD and devops, waiting a day for tests to complete and then several more for flaws to be fixed simply isn’t an option. Development teams might make hundreds of changes every day. For this to be manageable, they need to be able to conduct security checks themselves as they code, empowered by tools that mean they don’t need to suddenly learn to also be experts in a different, specialized domain. 

What is required is that SAST and SCA tools be, first and foremost, developer-friendly, adapting themselves to the workflow and tools used by the developers, rather than forcing them to bend to whatever is required by new tools. A DevSecOps workflow means developers do their best to ensure code is secure as it is being written, not as a separate, later step that creates delays and sees code passed continually back and forth between development and security teams.

Second, in today’s software environment, the two sets of tools, while fulfilling different purposes, have a common end in empowering developers to take the lead in application security, as the code is created and edited. Therefore, there’s considerable benefit in the two tools being consolidated in some ways, running simultaneously or facilitated within the same tool, to reduce the number of steps, lessen the learning curve and the complexity required.

Finally, the testing software needs to be cloud-based and the code optimized so that it does not create delays for the developer. The agile, continual nature of the modern software development world requires tools that work at the same pace. Practices and tools that were common historically, when software releases came at a much more gradual pace, are thankfully disappearing and both the quality and choice now available because of this is the reward. Security cannot be imperiled as a consequence, though, and thus choosing tools fit for purpose in today’s conditions is imperative.

Daniel Berman is the product marketing director at Snyk.