How To Generate and Audit SBOM In a CI/CD Pipeline

Initiating SBOM Creation & SCA Scans Within Pipelines

In our previous blog post, we have covered what SBOM is, its advantages, how to create it, and how to detect a vulnerability with SBOM. You may find the SBOM 101 blog at this link.

To reach the Github repository of this blog please click on this link.

You have learned the basics of SBOM and already created one, great! However, if you are not using it in your DevOps pipelines, then it’s not that useful since it will only be updated manually.

For scalability and convenience, we need to generate (and audit) SBOMs automatically in our pipelines. One of the easiest ways to do this is by using “maven plugins” as part of our build processes.

Since the build environment already exists in the DevOps pipeline, just passing a few arguments will do the magic!

How To Install CycloneDX Maven Plugin

For this blog post, we will use the CycloneDX Maven Plugin.CycloneDX has a native maven plugin that can easily be installed and used in the compile time of a Java maven application.

What is CycloneDX? CycloneDX is a Software Bill of Materials(SBOM) standard by OWASP and it’s designed for use in application security contexts. The CycloneDX project provides a bunch of tools for anyone to use in the desired environment.

To use this plugin, we only need to add the following configuration to the pom.xml file.

<!-- snip -->
<plugins>
  <plugin>
     <groupId>org.cyclonedx</groupId>
     <artifactId>cyclonedx-maven-plugin</artifactId>
     <version>2.6.2</version>
     <executions>
        <execution>
           <phase>package</phase>
           <goals>
              <goal>makeAggregateBom</goal>
           </goals>
        </execution>
     </executions>
     <configuration>
         <outputFormat>Json</outputFormat>
     </configuration>
  </plugin>
</plugins>
<!-- snip -->

If your pom.xml is not broken, running the “mvn verify” command should generate a bom.json file in your “target” directory.

An example output should be something like this:

target
|--- bom.json
|--- bom.xml
|--- classes
|    |--- hello
|         |--- HelloWorld.class
|-------- generated-sources
|         |--- annotations
|--- gs-maven-0.1.0.jar
|--- maven-archiver
|    |--- pom.properties 
|--- maven-status
     |--- maven-compiler-plugin
          |--- compile
               |--- default-compile
                    |--- createdFiles.lst
                    |--- inputFiles.lst

“bom.xml” and “bom.json” are the SBOM files.

As a next step, we will add the “auditing” stage for the generated SBOM files.

For the audit, we will use the Dependency-check which is another great open source project from the OWASP community.

How To Install Dependency-Check on Maven

Dependency-Check is a Software Composition Analysis (SCA) tool that’s still being developed under the OWASP Project. It’s protected by Apache 2.0 license and completely free to use.

What is an SCA tool? The main purpose of an SCA tool is to generate the dependency list and check for the known vulnerabilities via different sources like NVD, OSS Index or Github’s Security Advisory, etc. Some tools may also provide more details about their open source license.

For the Maven platform, the Dependency-Check has a native plugin; Dependency-Check-Maven which is very easy to install and run.

You just need to add the following lines to your project’s pom.xml file and cha-ching, it will work like a charm!

<!-- snip -->
<plugins>
  <plugin>
     <dependency>
        <groupId>org.owasp</groupId>
        <artifactId>dependency-check-maven</artifactId>
        <version>7.1.0</version>
        <configuration>
          <format>JSON</format>
          <cveStartYear>2010</cveStartYear>
        </configuration>
        <type>maven-plugin</type>
        <executions>
           <execution>
              <goals>
                 <goal>check</goal>
              </goals>
           </execution>
        </executions>
     </dependency>
  </plugin>
</plugins>
<!-- snip -->

Easy, right? Now, to run this block we only need to use the “mvn verify” command once again.

This will generate the following output:

target
|--- dependency-check.json
|--- classes
|    |--- hello
|         |--- HelloWorld.class
|-------- generated-sources
|         |--- annotations
|--- gs-maven-0.1.0.jar
|--- maven-archiver
|    |--- pom.properties 
|--- maven-status
     |--- maven-compiler-plugin
          |--- compile
               |--- default-compile
                    |--- createdFiles.lst
                    |--- inputFiles.lst

Now we have dependency vulnerability scan results. This is a pretty important step to check for vulnerabilities like log4j or spring4shell in your pipeline.

It is also possible to combine those two configurations and run them in one command.

You don’t necessarily need to use SBOM generation and SCA tests in tandem. However, it’s best practice to store SBOMs and audit them frequently – like in each pipeline cycle.

Maintaining an SBOM also has regulatory benefits if you are working with the federal government. According to the Executive Order dated May 5, 2021, Federal Government agencies should be provided a Software Bill of Materials (SBOM) for each product.

How can Kondukto help you with this?

Kondukto is a modern developer-friendly application security orchestration and DevSecOps platform that can help you to implement supply chain security using various commercial and open source tools.

You can use Kondukto regardless of your AppSec or DevSecOps maturity. Below you’ll find how to construct a supply-chain security pipeline using the tools we mentioned in this blog post.

Even though Dependency-Check has a separate native Jenkins plugin, we will be using the Maven plugin in this example. Using an SBOM generation tool or an SCA solution during compile-time provides better results as well as better performance.

We have already finished the installation of the plugin and set up our Kondukto environment, what then? It’s simple, let’s see the example Jenkins pipeline and how to implement Dependency-Check and Kondukto in it!

pipeline {
  agent {
     docker {
        image 'maven:3-alpine'
        args '-v /root/.m2:/root/.m2'
     }
  }
  stages {
     stage("SCM Checkout") {
        steps {
           // clone the repository
           git 'https://github.com/CSPF-Founder/JavaVulnerableLab.git'
        }
     }
     stage("Build and Initiate SCA & SBOM Scans") {
        steps {
           // Build the application and run Dependency-Check-Maven & CodeDX SBOM plugins
           sh "mvn -B -DskipTests clean verify"
           // Import the findings to Kondukto
           sh "/usr/local/bin/kdt --config=/etc/kondukto.yaml sbom import -p JavaVulnerableLab -f target/bom.json -b main"
        }
     }
     stage("Publish") {
        steps {
           // publish the app to the prod
           sh "echo 'Publish'"
        }
     }
  } // end of stages
}

And that’s it! The SBOM generated by the SCA product will be shown under the project’s SBOM list on Kondukto!

This automation is particularly a lifesaver when a new vulnerability is disclosed in a dependency.

Instead of having to go through a myriad of applications to check if the vulnerable dependency is used, Kondukto instantly allows you to list the applications using the vulnerable dependency.