What’s the best approach to secure vulnerabilities inside a Jenkins pipeline? Surprisingly, scale isn’t a consideration. Good security practices work whether you are talking about a personal project or an enterprise solution.
Sonatype’s Justin Young (@whyjustin) took up the topic recently at Jenkins World. First, he outlined today’s ongoing technological revolution: the explosive growth in open source software components. (Our latest Software Supply Chain report reveals the dramatic rise in components across all ecosystems.)A Demonstration
The global cascade of available components includes the infamous Struts 2 -- the vulnerable component used in the Equifax breach. Amazingly, it’s still in use out in the wild. In fact, malicious actors are weaponizing compromised components like Struts 2 and selling how-to instructions to others.
Justin demonstrated -- offline! -- how a compromised Struts 2 component could be manipulated. He instructed it to do a simple task (open a calculator) but the implications were clear. “Consider the risky mistake of Struts packed into Tomcat and running at root,” Justin warned. He noted that a vulnerable component, coupled with malevolent instructions, could access anything on your personal computer or connected network.
Preventative Steps and Free Tools
Justin urged his fellow developers to implement security efforts from the start. “Pay attention to GitHub security alerts,” he advised. Many vendors offer free tools to identify faulty components and offer remediation suggestions. He recommended Sonatype’s free tool, DepShield. Installing it is “a single click on GitHub,” Justin said.
For a Jenkins CI pipeline he recommended another free tool from Sonatype, Nancy. This command line tools analyzes Go projects for security vulnerabilities. Developers can run a customer Jenkins CI pipeline script and run the CLI data back immediately.
More free security tools for developers working in other ecosystems are available at the Sonatype OSS Index.
Here are the areas Justin recommends evaluating when addressing the security of a Jenkins pipeline:
Enforcement - Don’t break my build! Where does enforcement happen in the SDLC? Most developers would prefer to be told about a potential vulnerability than be put under restriction
Context - Do your enforcement policies have the right context? Imagine a zero day in production. Do you want your Jenkins breaking with every iterative fix? Or would you prefer to know there is a problem, fix it, push it to master? Context is very important when implementing security safeguards.
Precision - False positives suck! Tools that generate too many false positives inspire engineers to turn off notifications due to interruptions. This will effectively shut down preventative security measures.
Tooling - Select a toolstack that easily integrates with security tools. (Why make it overly complicated?)
Champion - Find someone on your team who cares as much, or more, about security and is willing to advocate for security measures throughout your organization.