Software Composition Analysis (SCA) Vulnerability Assessment
Knowing that specifics vary among vendors and customer practices, at its core, and for a typical “day in the life of DevOps” where an app’s composition relies heavily on OSS, SCA attempts to answer the question “what known security flaws are in here?” and follows up with “here are some remediation options” (e.g., upgrade).

While succinct, that description is not intended as an oversimplification since SCA’s primary concern is not–nor can it even infer–potentially-problematic internally-written code, such as a developer-written OWASP Top 10 or other vulnerability. Additionally, all products reviewed by market reports mentioned in License Compliance utilize hash matching against databases to identify components, any known security concerns, and remediation options. Notice again SCA’s focus on OSS and not internally-written code: Because the former is public, SCA takes advantage of identification, open and ongoing review and disclosed vulnerabilities, and remediation addressing exact findings whereas none of these are necessarily the case with the latter thus introducing a potential blind spot. Enter SAST.

Static Application Security Testing (SAST) Vulnerability Assessment
SAST may be a more familiar term than SCA, namely since the practice, vendors, and tooling have been fairly ubiquitous for a while. However, rather than identifying packages and any known security flaws, SAST examines the code for vulnerabilities recognizing that, e.g., this particular statement is clearly a SQL injection waiting to happen or this block uses compromised encryption. In essence, it’s secure code review expanded and automated to an extent and in a manner that manual review cannot reasonably achieve.

However, and subject to code volume and churn, statically testing an application historically has taken time; all relevant things held equal, SAST is computationally more demanding that SCA. As a result, and with today’s delivery pace, SAST review may risk becoming out-of-band, i.e., not integrated. This is not to claim that organizations are jettisoning SAST to meet delivery, but rather that the math may no longer work as well since certain practices and expectations may outpace integrated SAST. Plus, while SCA’s primary concern is OSS, nothing prohibits SAST from evaluating OSS as well and even if a repo’s own pipeline incorporates SAST, a “second opinion” so-to-speak by leveraging SAST for OSS components may be prudent to at least consider, but in all likelihood will increase SAST’s pressure.

Not to Pick on SAST, But…
Knowing no two pipelines and all they entail are identical, how then may SAST be positioned better for pipeline good citizenship without being a longer tent pole (or, being relegated to out-of-band thus eliminating its integration entirely)?

And what about remediation? Since SCA checks for known vulnerabilities, and virtually all such vulnerabilities have remediation options, it’s essentially second nature for SCA to relay back that information. But SAST generally references generic practice or implementation—perhaps an OWASP entry. While valuable, it necessarily must lean heavily toward advisory remediation rather that SCA’s prescriptive remediation. “Advisory” by definition, design, and itself does not close loops, but when the context is ridding code of exploit risk, advisory remediation will leave more unanswered (and raise more) questions than prescriptive with developers routinely fending for themselves and navigating unfamiliar territory for the next SAST scan to pass and move the code along.

Don’t Panic
Although code vulnerability analysis and remediation is as critical as any other obstacle in defense-in-depth’s sequence (if not of categorically-highest criticality since threats universally exploit vulnerabilities), the picture presented above may appear to place SAST in a catch-22: SAST’s benefit is hardly debatable, but the perceived value may drop if pipeline integration causes undue delay and remediation is actually guidance.

However, 2022 remains quite young but nevertheless has witnessed interesting vulnerability assessment M&A movement, namely increased focus on SAST addressing the main points above: Faster analysis and remediation. Some developments are quite recent, and thus specific vendors are not mentioned here, although quick searches on SCA and SAST market leaders are suggested to the interested reader. Regardless, this post would not have been written if what’s been observed in the SAST space was determined to be without merit: Speed and targeted remediation (and, thus, false positive reduction) are receiving non-trivial attention.

Final Thoughts
Despite the year being young and thus SAST advances also recent, nevertheless SCA and SAST were reviewed here to differentiate the two, highlight SAST’s potential, context-dependent limitations, and, most importantly, market leader response.

Lastly, and as a point of opinion, since SCA and SAST are of obvious and recurring market research interest, a Gartner MQ SAST report, for example, reasonably could be expected in Q2, perhaps sooner, and the criteria by which vendors are evaluated and categorized may be interesting compared to prior reports. Also of opinion, speed, remediation, and integration efficacy should receive appreciable weighting.