In the agile age of software development, speed is the name of the game. This is why CI/CD tools like CircleCI have played such a pivotal role in changing how we work; sending our software along through the pipes at a breakneck pace.
We are always asking questions such as: How fast can we get a new version out to our customers? How can we add these new features and stay on schedule? How can we do these things with as little wasted time and effort as possible?
Open source software components play an important role by providing us with the building blocks of our products. These free software components allow us to skip over the more monotonous work of writing basic features on our own by offering us tried-and-true code. This allows us to focus on our business logics instead of having to build our own frameworks and infrastructures from scratch. However, even as we enjoy the benefits of open source components, they are not without their challenges, especially when it comes to security vulnerabilities.
Don’t let vulnerable components hold you back
The facts are that the number of security vulnerabilities impacting open source components are on the rise in recent years, spiking some 51% according to our latest research report. This leads to more alerts and, of course, time-sucking tear-and-replace ops.
As developers looking for a solution to solve an issue we are having in our code, our first instincts often do not include a deep dive into the ins and outs of an open source component before we take it from a repo on GitHub. We simply don’t have the time to start investigating whether or not every open source library we use has any known vulnerabilities or if there is a newer version available. Instead, we ask if it does the job that we need it to do. If yes, great! And we throw it into our code. No? Ok, on to the next component until we find one that works.
The problem here is that once a vulnerable component makes it into our code, it can sit there posing a risk to your software until it is either flagged for remediation later, in the best of circumstances, or exploited by hackers, in the worst case scenarios. In either case, it means taking the time to go back into the code and implement some kind of fix.
Dealing with remediations
A fix can be as basic as adding a patch. This, of course, is easier said than done.
While upwards of 97% of all open source vulnerabilities have a fix, not all of these remediations are as rudimentary as a patch. In these cases, we might need to look for a new version and hope that it is backward compatible. If all else fails, the only option may be to look for a different component that does most of what our vulnerable one does and hope that the reconfiguration won’t break everything else.
All of this sounds like a hassle, because it is. The good news is that most of these issues are easily avoidable by working smart from the start.
Secure your CI/CD pipeline from start to finish
The WhiteSource CircleCI orb integrates WhiteSource’s automated, continuous tracking to help developers catch vulnerable, open source components before they get added to their product. Whitesource can come in at the earliest stages of the software development lifecycle (SDLC) to identify open source components and flag the vulnerable ones that can cause trouble later down the line. By catching any vulnerable components before they are added to the CI, staging, or production servers, it provides us an opportunity to find a different, more secure version or component that can give us what we need.
Even though we would prefer to catch vulnerable components early on in the game, sometimes vulnerable components may already be present in a deployed product. In these circumstances, we need to remediate. The saving grace here for developers is that the suggested fix in the vulnerability description can point us in the right direction, saving us the time it takes to research and confirm the ideal solution to our problem ourselves.
Fast and simple implementation
To get started, WhiteSource account holders can click on the Circle CI “Settings” section and create a new context. From there, it is a matter of adding the WhiteSource API token on the integrate tab.
![CircleCI contexts]
Once this is completed, users can create a configuration file with their necessary parameter references, and start receiving WhiteSource reports about their open source usage and risks.
Sample usage:
version: 2.1
executors:
java:
description: The docker container to run java commands
docker:
- image: circleci/openjdk:8-jdk
jobs:
scan:
executor: java
parameters:
api_key:
description: Unique identifier of the organization. Can be retrieved from the admin page in your WhiteSource account.
type: string
default: ""
directory:
description: Comma separated list of directories and / or files to scan.
type: string
default: "."
config_file_path:
description: Configuration file name (including file path).
type: string
default: "./whitesource-fs-agent.config"
steps:
- checkout
- run:
command: |
if [[ -z "<< parameters.api_key >>" ]]; then
bash <(curl -s -L https://github.com/whitesource/fs-agent-distribution/raw/master/standAlone/wss_agent_orb.sh) -c << parameters.config_file_path >> -d << parameters.directory >>
else
bash <(curl -s -L https://github.com/whitesource/fs-agent-distribution/raw/master/standAlone/wss_agent_orb.sh) -apiKey << parameters.api_key >> -c << parameters.config_file_path >> -d << parameters.directory >>
fi
Wrapping up
We use open source components to save time and get where we are headed faster. We need to make sure that we are using the right technologies to manage how we are using these components, minimizing the amount of maintenance work needed to use them securely. By linking your CircleCI and WhiteSource accounts, we have made it much simpler to catch vulnerabilities while they are still easily manageable, giving you the insights into your software that you need to make smarter decisions in working with open source components.
Shiri Ivtsan is an Experienced Cloud Solutions Architect and Product Manager and holds a B.Sc. in Industrial Engineering and Management. Prior to joining WhiteSource, Shiri worked for various companies where she held several roles in R&D, as a Solutions Architect, R&D Team Leader, and Product Manager.
