SBOM- Can it secure open source from vulnerabilities? (Part 2)

Following up the part 1 let’s take a look into how to configure a dynamic SBOM as a part of the CI/CD pipeline.

Implementation:

I make use of the Jenkins pipeline for the implementation. The reason for going with Jenkins is that it is a free open-source tool predominantly used in many companies and has greater flexibility in providing integration with many languages like NodeJS, Java, Python., etc.

1. Install Jenkins:

I made use of this handbook for installing Jenkins locally. https://www.jenkins.io/doc/book/installing/windows/

2. Create a sample Spring-boot project:

I created a sample SpringBoot project which includes a couple of packages with known vulnerabilities. I used https://start.spring.io/ to create a basic SpringBoot project with known vulnerabilities

3. Create JenkinsFile:

I created a Jenkinsfile which will hold the scripts for building the pipeline in Jenkins. Jenkins will identify that Jenkinsfile is a part of the project and will make use of the script inside it to build the pipeline.

4. Set up a GIT repository:

We would require a Git repository to hold the project and tell Jenkins to poll for changes from this repository and run the SBOM every time a new commit is made to the repository.

Make sure to create a webhook for the git project, which holds the SpringBoot application and the Jenkinsfile, so that Jenkins will run the pipeline every time there happens a commit to the repository.

To add a webhook, follow this page: https://www.cprime.com/resources/blog/how-to-integrate-jenkins-github/

5. Setup Jenkins:

Create a new Jenkins Pipeline from the dashboard. For the rest of the fields provide a default value. Since we are coding all the steps in the JenkinsFile, we would not require much configuration setup for Jenkins.

Since the SBOM creation is a part of the CI/CD pipeline, every time the developer(s) makes a commit the code will be scanned to see if there is a vulnerability. If so it would be noticed earlier than waiting till the product is out for deployment. This way of incrementally checking for vulnerabilities will reduce last-minute surprises during production and deployment.

6. Snippet of the Jenkinsfile:

I have created 2 stages: one for generating the BOM file and the other one for scanning the BOM file to check for vulnerabilities. If any vulnerabilities are found, an artifact would be created providing detailed insight into it.

7. Add necessary dependency:

I made use of a Gradle plugin for including CycloneDX as a part of the application. However, there is also CycloneDx generation that is provided as a part of npm which could also be used.

8. Local checking of SBOM creation:

We can locally check if the SBOM is getting created or not using the command:

gradlew cyclonedxBom

The generated BOM file are stored in the build/reports/ by default.

9. Checking in Jenkins:

Once the JenkinsFile is added to the project and all the changes are pushed to the Git repository that is created, the pipeline would run. If the pipeline does not pick up the changes manually trigger the build to run.

The output after a successful running of Jenkins would look similar to this.

This is a simple setup of generating dynamic SBOM and scanning for vulnerabilities. This could be extended to perform many other advanced tasks like integrity validation, signing the BOM file, and securely storing it.

All of this code can be found at: https://github.com/sakthiuma/SBOM_jenkins