SCA — testing 'third-party' code for vulnerabilities

Imagine you are building a house. You designed the walls yourself, checked every brick, and made sure you didn’t leave the keys in the lock. But what if the concrete you bought from a third-party supplier starts crumbling over time? Or the finished window frames you installed have hidden defects?

In modern development the situation is exactly the same. The average application today is 80–90% made up of Open Source libraries. You write only a small portion of the code (the tip of the iceberg) that orchestrates a huge mass of someone else’s code hidden “under the water”.

What is SCA and why does a newcomer need it?

SCA (Software Composition Analysis) is the process of analyzing the composition of your software. Simply put, it’s a tool that lists all the libraries you use (including those you might not even be aware of) and checks them against databases of known vulnerabilities.

Why is this critical?

You can be a programming genius and write perfectly secure code, but if you use a popular logging or image-processing library that has a hole in it — your application will be compromised.

A classic example: Log4Shell (2021). A critical vulnerability was found in a tiny Java library (Log4j) used by millions of servers worldwide. Attackers only needed to “feed” a specially crafted string where it would end up in the logs to get remote code execution and full control of the server. Companies spent weeks just trying to find which of their projects used that library.

How does it work? Transitive dependencies

When you add one library to a project (for example, requests in Python or express in Node.js), it in turn pulls in other libraries. Those pull in others. This is called transitive dependencies.

In the end, by adding one package you can unknowingly drag 50 more external modules into your project. SCA scanners analyze your manifest files (package.json, requirements.txt, go.mod, pom.xml) and build a full dependency tree, checking each element.

Tool: meet Trivy

For a beginner, a good choice is Trivy from Aqua Security. It’s a security “Swiss Army knife”: it can scan project files, Docker images, Git repositories, and other targets.

Why Trivy?

• It’s fast.
• It can find known vulnerabilities in dependencies and packages.
• It produces clear reports: what was found, where it is, and which version you need to upgrade to.

Practical example: scanning a project

Suppose you have a Node.js or Python project.

Installation

macOS:

brew install aquasecurity/trivy/trivy

(There is also a trivy formula available in Homebrew, so you can also install it like this: brew install trivy.)

Linux/Windows: Download the binary from the Trivy releases and install it into your PATH.

Running a filesystem scan

trivy fs ./путь/к/вашему/проекту

What will you see in the terminal? Trivy will output a table. It will include:

• Library: the name of the library (for example, django or lodash).
• Vulnerability ID: the vulnerability number in the global registry (for example, CVE-2023-1234).
• Severity: how dangerous it is (LOW, MEDIUM, HIGH, CRITICAL).
• Installed Version: which version you currently have.
• Fixed Version: which version you need to upgrade to in order to fix the hole.

Survival strategy: what to do with the results?

When you run an SCA scanner on a real project for the first time, you might be horrified: “I have 200 vulnerabilities! What do I do?!” Calm down. They are not all equally dangerous.

1) Priorities (Triage)

First fix CRITICAL and HIGH. These are the holes that are most often exploitable relatively quickly and with high impact. LOW-level vulnerabilities are often more theoretical and can wait.

2) Updating — the best remedy

In most cases the SCA problem is solved simply by updating dependencies:

npm update

pip install --upgrade ...

But be careful: major upgrades (for example, from 2.0 to 3.0) can break your code. Always verify functionality after updating.

3) Automation (Dependabot and similar)

If you use GitHub, be sure to enable Dependabot. It’s a bot that scans dependencies and automatically creates a Pull Request with the upgrade when it finds a vulnerability. You only need to go through the usual review/tests process and click “Merge”.

SCA pitfall: license compliance

Besides security, SCA tools often check licenses. Imagine you accidentally used a library with a GPL license in a commercial project. Depending on the distribution scenario and legal interpretation, this could create obligations to disclose source code or other requirements. Advanced SCA scanners warn about this ahead of time so your company’s lawyers don’t have questions.

Summary: rules for working with dependencies

• Less is better: don’t pull a library into the project just for one feature you can write in five lines of code. Every new package is a potential security hole.
• Scan regularly: new vulnerabilities are discovered constantly. What was safe yesterday can become a critical threat today.
• Use lock files: always pin versions (package-lock.json, poetry.lock) so that a version you haven’t tested doesn’t end up in production.