DevSecOps Series V - SCA

April 28, 2025 // echel0n

Hello guys! This is the fifth blog of DevSecOps Series! In this blog, I will give some details about what SCA is and why we should use it and then I will provide an example of a local deployment of OpenSCA with the Jenkins pipeline step. Hope you will enjoy!

Table of Contents

Used Tools, Tested Hardware/Software and Warnings
SCA - Software Composition Analysis
The Action - Installation of OpenSCA

0 Used Tools, Tested Hardware/Software and Warnings

Some configurations here and in the repository I referenced may be insecure, and it is recommended that you act with awareness. Since this is a lab environment, we will not be making many security configurations of the tools.

These are the tools we will be setting up. (Check previous blogs if something is missing!)

OpenSCA as a SCA Solution

Provided configurations were tested on this hardware

CPU: AMD Ryzen 9 5900X (24) @ 5.619GHz 
Memory: 23904MiB 
Swap: 4GB 
OS: ArchLinux 6.13.8-zen1-1-zen
Terminal: 5.2.37 
Docker version 27.3.1, build ce1223035a 
k3s version v1.31.3+k3s1 (6e6af988)
go version go1.22.8

This setup is using a lot of resources. Be careful after deploying the tools, as they can quickly exhaust your resources. Do not forget to save your critical data while the instances are running. I am pretty new to Kubernetes so I am open to fine-tuning suggestions, please feel free to get in touch, it would be great to learn more!

1 SCA - Software Composition Analysis

1.1 What is SCA?

Software Composition Analysis (SCA) is a scanning method focused on identifying issues in a codebase’s components, typically open-source ones. It mostly aims to detect license violations and outdated libraries.

Unlike other types of scans, this time our scope directly targets the components used in the application's development. SCA solutions will mark any library with CVEs or flag it if it is at an outdated version, and then break the pipeline of the application's deployment. It means whenever these are detected, the application's pipeline will be broken and will not allow it to go live. Sounds wonderful, right? Actually, no.

This time, these updates will require more thorough tests, which means everyone in the team must be aligned and test their code against the new version. Minor version updates are usually easier because they typically do not introduce usage breaks (such as obsolete or deprecated functions), but major ones will be a problem. So, shifting left makes everyone more proactive (required! Not to being reactive is not an option) for a more seamless development cycle. Whenever any library is flagged, the security SPOC of the team (security champion perhaps!) should escalate this urgency to the manager (or to whoever has strong influence over development) to schedule the transition to the new version.

(Being in an agile development cycle sometimes helps.)

Somehow, the legal issues are left here to resolve. I cannot comprehend the idea that "cybersecurity people should also be responsible for following and finding license problems!". It is more like somewhere some people said, "If you can detect and track these libraries, then track this issue too!". I really get mad when governance issues are put into cybersecurity but we are here. *internal screeches*

With this capability, the SCA solutions are helping people to track their all licenses in centralized dashboard and keep track of all the libraries and licensing information in the ecosystem. AS much as I hate it, this functionality and its use are incredibly relieving.

Last subject here: Software Bill of Materials (SBOM). It has emerged as a key topic in supply chain security and its associated risks. Since many libraries are open source, everyone tends to skip the underlying technologies and stacks, focusing directly on the application's core functionalities — and it makes sense. This kind of inventory makes everyone's life easier, as keeping track of which components are used across organization wide becomes just one click away!

1.2 How?

Most of the time, it depends on how compilers detect dependencies. For example, if you want to write your SCA software for Java as a programming language and Maven for the management, "pom.xml" file will be enough to analyze. You just need a parser and a vulnerability database (sounded like it is so easy to do)

1.3 Basic mind-set of Review of SCA Findings

Same rules applies as in DAST. You and the inventory define the context. Most of the time, you are the one making the decisions, so it is up to you to determine whether something is relevant or not. For example; The SCA software might report vulnerability in components like jQuery, but when you look into the CVE details, it may turn out the vulnerable function is not even used -and never will- in your project -- so it is safe to ignore. Bottom line; you need to perform your own threat assesment and decide what actions, if any, are necessary.

1.4 Some Caveats

1.4.1 Alert Fatigue

You will be dealing with a lot of alerts! I mean a lot! If your application inventory is big enough, you will be exhausted to look at every CVE and check if they are valid in the context of application. These alerts will exhaust you to the point that you will want to upgrade every component.

1.5 The Benefits

1.5.1 More earlier a vulnerability is fixed in the SDLC, the cheaper it gets.

1.5.2 You will be able to create a library inventory, SBOM dashboard. (which library is used by which applications)

1.5.3 You will be able to check for any license infringement across all applications organization-wide.

2 The Action - Installation of OpenSCA

I will just demonstrate how a minimal SCA looks like. Not because I do not want to. Because free SCA solutions often have difficulty producing valuable outputs. For example, OpenSCA is not reporting vulnerabilities. At least, the SBOM list is fully available.

Since I will be using it (and probably you) on my own computer and my resources are very limited, I will be using OpenSCA in our pipeline in a way that is not very suitable for a real scenario.

OpenSCA has a docker image that is available to pull and install. Run this command once, then you are ready to integrate it into Jenkins while being in dvja directory;

# the opensca-config.json file is available at devsecops-series git repository! you can also commit this file into 
# local repository of dvja too!
docker run -ti --rm -v ${PWD}:/src opensca/opensca-cli -config /src/opensca-config.json

Check opensca-results.html, we will save this file as an artifact in our Jenkins pipeline.

The pipeline integration will be based on direct scanning and saving outputs for future review. We will be experiencing it in its most primitive form.

// put this stage after SonarQube
	stage('OpenSCA Analysis') {
	    steps {
		script {
		    sshagent(credentials: ['SSH_LOGIN_HOST']) {
		      sh """
		      echo "Starting OpenSCA scan...";
                      scp -o StrictHostKeyChecking=no opensca-config.json root@${KUBERNETES_HOST}:/tmp/opensca-config.json;
                      scp -o StrictHostKeyChecking=no pom.xml root@${KUBERNETES_HOST}:/tmp/pom.xml;
		      docker run -t --rm -v /tmp/:/src opensca/opensca-cli -config /src/opensca-config.json
              	      scp -o StrictHostKeyChecking=no root@${KUBERNETES_HOST}:/tmp/opensca-results.html opensca-results.html
		      echo "OpenSCA scan finished.";
		       """
		    }
	    }
		archiveArtifacts artifacts: 'opensca-results.html', fingerprint: true

	    }
	}

First, we put opensca-config.json, which is the custom OpenSCA config file for the project and project's pom.xml into remote (which is host, in this case) server to analyze the dependencies. Then, we run the opensca docker container. Finally, we pull the output file from remote machine to save it.

After the pipeline run, you can check the result from here.

3 The End - Conclusion

Even though we could not get the libraries with vulnerabilities or outdated ones, we could obtain an SBOM output. With any commercial SCA, you will have better results for the applications you have. The pay-to-win problem also exists here. The more you pay, the more you get.

That is all for now! Thanks for finding my blog interesting enough to read. Have a nice day, you absolute legends! 🎉

References and Links

First Part - https://devilinside.me/blogs/devsecops-series-introduction
Second Part - https://devilinside.me/blogs/devsecops-series-simple-pipeline 
Third Part - https://devilinside.me/blogs/devsecops-series-iii-sast
Fourth Part - https://devilinside.me/blogs/devsecops-series-iv-dast
Provided Configurations and Scripts - https://github.com/echel0nn/devsecops-series