Known open source vulnerabilities present the biggest threat to our open source usage. This leaves our products open to exploitation if they are not remediated. These vulnerabilities have been found by security researchers and reported to a range of security resources like the National Vulnerability Database, various advisories, and issue trackers. Hackers know that they can look to these resources for free information on how to exploit vulnerable open source components that are used in many products, making it easy to find potential targets.
Failing to stay on top of your vulnerable open source components can come with significant price tags as we saw in the case of Equifax in 2017. The credit rating agency was breached when hackers exploited a vulnerable version of Apache Struts that was being used in a customer portal, making off with the personally identifiable information (PII) of some 147 million plus users. The vulnerability in the Struts component had been known for at least two months, but the company’s developers were unaware that they were using it in their product, and were thus too slow to patch it before the breach was discovered.
Unfortunately, tracking of all of our open source usage can be a challenge, to say the least, when we consider the scale of how much open source software we use in our products. In facing this challenge, knowing which components you are using and which ones are vulnerable are an important first step.
Knowing is half the battle
The first step to tackling the threat of vulnerable components is identifying which ones are present in your repos, products, etc. However, keeping tabs on all the open source components that you are using as they make their way through your CI/CD pipeline, in addition to the ones that have already been included in deployed products, is far from a simple process. Often times an open source component may show up without any vulnerabilities, but it may be hiding some nasty ones in its dependencies that might be exploitable. Add to this the need to constantly comb through all of the available security resources for new vulnerabilities and you are essentially faced with the definition of a Sisyphean task.
In hopes of making this mission a more viable lift, WhiteSource has teamed up with CircleCI to offer all CircleCI users a free tool to automatically scan their products for the latest and most common vulnerable open source components. Every month WhiteSource compiles a list of the top 50 open source vulnerabilities that can be checked against your inventory, along with a more comprehensive list of common vulnerabilities that could threaten your products if left unchecked.
The results from the scan will then notify you in real-time if your product is in need of remediations or hopefully free of any known vulnerabilities from the lists.
Getting started with the WhiteSource vulnerability checker orb
Integrating the WhiteSource orb is fast and easy. Simply copy the relevant lines from the
.yml file below to the config file of the project in your GitHub repo and click commit changes to start the scan.
version 2.1 orbs: vulnachecka: email@example.com workflows: test: jobs: - vulnachecka/scan
Here in our CircleCI environment, we can see that the scan is in progress. When the scan has been completed, we can see the project in our Artifact tab and see the results below by clicking on an easy to comprehend HTML page.
We can see here if we are totally in the clear or if vulnerabilities have been found from either the most common or Top 50 lists.
Developers owning security
Keeping pace with the breakneck speed of software development today demands that we find new and innovative ways to handle our product’s security more efficiently. Automated tools, like those offered by WhiteSource, help organizations to shift their security left, avoiding vulnerabilities in their products from the earliest stages of the SDLC to meet tight release schedules.
With no requirement to sign up for this free service, now is a great time for CircleCI users to utilize WhiteSource’s industry-leading open source security solution, taking control of your open source vulnerability management.
This post is a part of a series we produced covering DevSecOps. To read more posts from this series, click one of the links below.