We continue the series of posts about the tools of an AppSec engineer. Because the last p…

We continue the series of posts about the tools of an AppSec engineer. And then the last post about MAST It was already November 3rd. Today we'll talk about SCA 🤌

What is SCA?

SCA stands for Software Composition Analysis, software composition analysis. But since these posts are needed for a simpler explanation of all this, I would say this: this is a check of all other people’s code that you brought into your project. And in a modern application, someone else's code is usually 80–90%. Sometimes more

Any library, npm package, Maven dependency, pip module, etc. - all this must be analyzed by SCA. The tool looks at what the application actually consists of and checks whether the version of the library you are using is vulnerable 🤓

What is SCA used for?

SCA is needed so as not to wake up one day with news in the format “vulnerability in Log4j / OpenSSL / left-pad / insert_random_library_name_here breaks half of the Internet - and yes, you suffered too.” It solves several problems at once. First, look for known dependency vulnerabilities ( CVE, GHSA, NVD and all this joy ). Secondly, license control: MIT - okay, Apache - okay, GPL in production - hello lawyers. Thirdly, inventory: do you at least know which versions of libraries you actually use?

How does it work?

The SCA tool takes manifests and lock files ( package.json, package-lock.json, pom.xml, requirements.txt, go.mod, etc. ), sometimes binaries and containers, and builds a complete dependency tree 🌳

And not only direct ones, but also transitive ones. Those that are trailing behind, although you did not add them ( and were not aware of their existence at all ). And then there is a correlation of library versions with vulnerability and license databases. For every vulnerability found, a finding arrives. A license was found that is incompatible with the distribution model - go there

It is worth mentioning here SBOM ( Software Bill of Materials ). In fact, this is a detailed list of all components, dependencies ( including open source libraries ) and metadata ( licenses, versions, vulnerabilities ), which are included in the software

How to use SCA?

Most often, SCA lives in CI/CD. Each commit or merge request triggers an automatic check. This is the most adequate option, because vulnerabilities in libraries appear faster than you can write code 👨‍💻

In more mature processes, SCA also breaks the pipeline. If a critical vulnerability without a fix or a prohibited license arrives, there will be no release. Pain but, but effective. This approach is called Quality Gate, by the way

Tools for implementing SCA

Open source feels confident here. Of the most popular options I can highlight OWASP Dependency-Check and Trivy

Among the commercial solutions there are Snyk . In the domestic segment - Solar appScreener ,CodeScoring and a combination of SCA+SBOM in the ecosystems of large vendors 🤑

#information_security
#sca