CI/CD Pipeline Security & Shifting Left Part 2

 A follow-up to my previous post I wanted to go back and remove the vulnerable code from  and update the included libraries to fix any dependencies that were vulnerable. 

First, let's have a look at what has changed simply with the passage of time...

Dependency-Track has not had a new SBOM for quite some time as the pipeline hasn't been run.  However, it has continued to track vulnerabilities in the included components.

Dependency-Track Apr 23
The summary view shows the included versions with the number of vulnerabilities by severity.

Not only has Dependency-Track continued to do it's job quietly in the background but it has also been updating Defect Dojo as new vulnerabilities have been notified through it's vulnerability database feeds. 

Defect Dojo Apr 23
All of this happens based on the last SBOM ingested by Dependency-Track. Even if the pipeline has not been run in years and no new SBOM produced, it will continue to surface new vulnerabilities in the software components included as they are announced.

I corrected all of the vulnerable code and the pipeline ran all the tests.
Jenkins Blue Ocean Pipeline
All the tests now pass since the vulnerable code was mitigated with improved versions. 
Postman Tests Pass in Jenkins pipeline

As in the previous post I run Snyk integrated into the PyCharm IDE and I can view the results in the Snyk portal for my project. 
Snyk Planetary-api Apr 23
I have already updated the version of Python in my Dockerfile:

Note: There is still one issue with this Dockerfile. Next, I updated all the dependencies in the requirements.txt file using the python convention "~=" to specify the highest compatible version instead of a fixed version as I had before using "==". 

When the update is committed and pushed to GitHub the pipeline runs and a new SBOM is pushed to Dependency-Track.
Dependency-Track fixed dependencies Apr23

As can be seen, all dependencies remediated. 

Semgrep finds the final issue in the Dockerfile where the last user of the container is "root".

Semgrep Dockerfile USER root Apr23
Clicking on the link takes us to a detail view showing the offending line.
Dockerfile user root

Obviously this is something that could be fixed with a little work and moving the port number out of the ephemeral range. 

I just wanted to show how each security tool plays it's part in remediating those issues.


Popular posts from this blog

Squid Proxy with SOF-ELK Part 1

Netflow analysis with SiLK - Part 1 Installation

Password Cracking with CUDA 2 ways