Twistlock has provided the ability to seamlessly integrate security into your devops pipeline with the Twistlock Jenkins Plugin for quite some time. The plugin allows customers to define thresholds for compliance and vulnerabilities, and fail a build based on, for example, a high level vulnerability. With the advent of our latest release, the Twistlock Jenkins plugin provides even more flexibility with time-based vulnerability blocking.
In a modern agile and devops environment, teams utilize sprints to deliver key features and fix critical bugs — the key here is to deliver the best possible value in each sprint. Security vulnerabilities should be treated just like bugs, with higher vulnerabilities and their higher corresponding risk equating to “critical” bugs.
The ability to schedule groups of vulnerabilities within a single sprint and allow time for development to fix these bugs before failing releases is an important value add. The Twistlock Jenkins plugin enables scheduling of critical security vulnerability bug fixes and strong enforcement if those deadlines pass.
Automating security with the Jenkins plugin
The Twistlock Jenkins plugin enables automatic security checks into devops pipelines with the ability to fail builds based on security or compliance thresholds. But when a new CVE is discovered in an existing build, immediately failing the build can bring your pipeline to a standstill. By giving your development team a reasonable time frame to remediate these new vulnerabilities, the pipeline remains operable and you can ensure that the vulnerability issues are fixed within the desired time frame — otherwise the build fails.
The massive Equifax data breach caused by the exploit of a vulnerable struts component is a great example where having a time-bomb (so to speak) for strong enforcement would have prevented the breach without immediately halting their pipeline. As I have been advising enterprises for a number of years, you typically have about 2-4 weeks to fix a critical vulnerability before attacks based on that vulnerability are launched. In the case of the Equifax breach, the breach occurred exactly one month after the CVE was made public.
Technical deep dive
To get started with time-based vulnerability blocking, just follow the instructions in my previous blog on Continuous Delivery with the Twistlock Jenkins Plugin.
Once the Twistlock Jenkins plugin is installed, it’s extremely easy to add a grace period for failing a build based on the day that an update that fixes that vulnerability. You simply add a pipeline step for the Twistlock scan using the syntax generator, fill in thresholds for compliance and vulnerabilities, and finally, fill in the grace period in days.
For example, you might say, for a particular project, developers have 14 days after an update to a high or critical rated vulnerable component or OS is released to patch their image. I would think twice before considering using a grace period beyond 30 days as the risk increases each day the vulnerability is present.
The “days left to remediate” is readily available in the Twistlock Jenkins scan output, simply navigate to the project level, click on and then select the “Details” tab, you should see something like:
It’s easy to see that the development team has 3 days left to remediate CVE-2018-6003 by upgrading libtasn1 to version 4.12-r3.
All Jenkins image scan reports are available via the Twistlock Console with corresponding scan success or failure based on threshold and grace period. In the Twistlock Console report, you can also see vulnerabilities by layer which give unique insight as to what vulnerabilities are in each Docker layer in your image further assisting the development team with remediation.
By adding this critical new functionality, time-based vulnerability scanning, you can enable your development operations to run more efficiently and be sure that critical security fixes are completed in a reasonable time frame.
To learn more about steps your team can take to integrate security into devops, check out our latest infographic 7 Tips to Navigate Operationalizing DevSecOps.
Related Twistlock 2.4 Posts:
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
IAM Roundup: AWS vs. Azure vs. GCPRead the Blog
How to Securely Configure a Linux Host for ContainersRead the Blog
Don’t Forget the Audit Trail! The Role of Reporting in SecurityRead the Blog
Securing Cloud Native Applications on Pivotal Container Service (PKS)Read the Blog
What to Know: Gartner’s Security Considerations and Best Practices for Securing Serverless PaaSRead the Blog