Shift Security Practices Left: New Nexus Plugin for Jenkins Pipelines
Many organizations are quickly maturing their CI/CD practices in the hopes of winning the innovation battle. But where do security and governance practices fit in? As organizations embrace DevOps, quality and security cannot become an afterthought. The good news is that many DevOps practitioners agree as evidenced by our recent DevSecOps survey. The data shows that mature DevOps organizations are automating security practices earlier in the development process compared to less mature DevOps organizations.
According to the survey, almost half of highly mature DevOps organizations are automating security during Development and 60% are analyzing security during QA/Test. This is important because as developers increase the speed at which they consume open source components, there is a higher probability of introducing some level of risk. The amount of risk could vary from something more benign like using an older component version that does not meet quality standards to something more serious like introducing a component with a critical vulnerability, exposing customer information.
Analyzing risk levels during the build is one way to automate security practices earlier in the development pipeline and “shift security practices left”. With the latest Nexus Platform plugin for Jenkins 2.x, organizations now have access to continuous component intelligence within their CI/CD pipelines.
The Application Composition Report available within Jenkins identifies components containing security vulnerabilities, license risk, and quality issues, and ranks them according to their threat level. With this information, release engineers have visibility into the amount of risk within an application and can determine the best actions to take. For example, a policy waiver may be warranted if a developer is using the only secure version of a component which happens to violate an architectural age policy, while failing a build may be warranted if an application being released to production contains a critical security violation.
So, how exactly does the integration work? Well, complex build processes written for Jenkins munge open source and proprietary libraries into one or many different deliverables which can be viewed as different “applications” from a Nexus perspective, and should therefore be scanned independently to evaluate different policies. Depending on the outcome of a policy evaluation, the pipeline logic can either continue, halt, or start an entirely new workflow in parallel to other build tasks to remediate the issue. The new Jenkins pipeline plugin programmatically invokes policy evaluations and returns the results in a machine readable format, automating the remediation response based on the evaluation results. With the new integration to Jenkins, Nexus policy evaluations work in concert with pipeline build behaviors to ensure only the best components are being used in production apps.
For GitHub users, this same Application Composotion report can be accessed via a GitHib Pull request to ensure that developers are using only the highest quality components - shifting securty practices even further left. To see how it works watch this video:
For organizations seeking to innovate faster, think about how you can shift your automated security practices left. Empower developers to use only the best components from the very beginning and catch security, license, and quality issues early in the development lifecycle. With the new integration to Jenkins pipelines, Nexus users have a DevOps native solution to meet their need for speed.
To learn more about our Jenkins integration and 30 others we introduced this week, please visit the Nexus Exchange. We also invite you to join Sonatype’s webinar on May 17th discussing new integrations available in the Nexus Exchange.
