The job as a software developer is pretty crazy: You need to learn constantly about new technologies, understand topics within the domain you’re working, estimate how long it will take to build stuff you have never built before, explain issues to people who have absolutely no clue. On top of all that, you need to protect your software system against attackers. But the attackers are usually not a problem — until they are. This means it can happen that security receives little attention as it seems not to provide direct value. And when the value becomes apparent, it’s too late.
Considering that developers are so busy with many other topics and might have a hard time to justify the need for security improvements, the security improvements need to be part of the normal workflow. You want to have something running completely automatically which takes care of that for you.
There are many different topics in security and many different tools. One group of tools do so-called software composition analysis — SCA in short. After reading this article you will understand what SCA is and how it helps you.
Problem 1: Malicious Third-Party Software
Software that is written to cause harm can get into your dependencies. Either by a typo and typosquatting attacker or by a trojan horse. A trojan horse is software that seems to be useful but does something else.
Problem 2: Vulnerable Third-Party Software
The more complex software becomes, the harder it is to have all relevant aspects of it in your mind. This can lead to vulnerabilities — especially with many contributors.
Problem 3: Licenses of Third-Party Software
You can also run into legal issues. As an organization, you want to make your mind up about which licenses are acceptable. The acceptable ones will be in an allowlist. Then you want to automatically check any dependency regularly against this allowlist.
Typical licenses are MIT, BSD, Apache 2.0, LGPL, GPL, MPL.
Have a look at tldrlegal.com to get a quick overview.
How SCA works
Checking for malicious and vulnerable third-party packages is simple: Blocklists. If a version of a package (or the complete package) is known to cause problems, it gets on a blocklist. SCA tools can check the blocklists and prevent you from installing problematic software.
For the licenses, you need to have a way to extract the licenses from a package. Some important things to consider:
- Package authors can add alternative licenses
- Package authors can add multiple licenses which all need to be fulfilled
- Package authors can (technically) not give any license — that means you cannot use it!
- Package authors can give inconsistent licenses, e.g. in Python, there are at least 3 different common ways where you can denote the license.
Prerequisite: Bill of Materials (BOM)
You need to know which third-party software you are using. For that, you create a so-called Bill of Materials. Sounds fancy, but it really is just a list of the software you use. The programming languages typically come already with solutions for that:
-
Java: pom.xml (see dependencies)
-
JavaScript: yarn.lock
- PHP: composer.lock
- Python: requirements.txt files with transitively-pinned dependencies, e.g. via pip-compile from pip-tools
- Ruby: Gemfile.lock
- Rust: Cargo.tom — I’m uncertain if that contains transitive dependencies (see dependencies)
Please let me know about how this is called in other languages — I will expand this list then.
Examples for SCA Tools
Free solutions:
- JavaScript: yarn audit for vulnerabilities and yarn licenses + scripting around it for licenses.
- Python: safety for vulnerabilities, pip-licenses for licenses.
Commercial solutions:
- Blackduck
- Dependabot: I’ve seen this on Github some times.
- Snyk for vulnerabilities: You can see it in Github pretty often. It’s free for open-source software.
Summary
Software Composition Analysis (SCA) tools can help you a lot and usually stay in the background. Integrate them in your Continuous Integration (CI) pipeline, run them regularly as a scheduled task. In most cases, you don’t have to do anything. But when the tool complains, it is important.
What’s next?
In this series about application security (AppSec) we already explained some of the techniques of the attackers 😈 and also techniques of the defenders 😇:
- Part 1: SQL Injections 😈
- Part 2: Don’t leak Secrets 😇
- Part 3: Cross-Site Scripting (XSS) 😈
- Part 4: Password Hashing 😇
- Part 5: ZIP Bombs 😈
- Part 6: CAPTCHA 😇
- Part 7: Email Spoofing 😈
- Part 8: Software Composition Analysis (SCA) 😇
- Part 9: XXE attacks 😈
- Part 10: Effective Access Control 😇
- Part 11: DOS via a Billion Laughs 😈
- Part 12: Full Disk Encryption 😇
- Part 13: Insecure Deserialization 😈
- Part 14: Docker Security 😇
And this is about to come:
- CSRF 😈
- DOS 😈
- ReDoS 😈
- Credential Stuffing 😈
- Cryptojacking 😈
- Single-Sign-On 😇
- Two-Factor Authentication 😇
- Backups 😇
Let me know if you are interested in more articles around AppSec / InfoSec!