This is part 2 of my blog series about Nexus Lifecycle. If you missed my first part you can find by clicking this link. Here I will talk about how to properly roll out Nexus Lifecycle in an Enterprise Environment based on a past experience.
The first thing you need to do is to make sure that you have a correct Nexus Repository in place that supports Nexus Lifecycle. Unfortunately, not every version of Nexus Repository supports Lifecycle so you would have to check on the website or contact Sonatype directly to ensure compatibility.
If your version of a repository is incompatible you could attempt to upgrade Nexus Repository at the same time as launching Nexus Lifecycle. However, I would not recommend it because there are more variables you have to account for. Instead of having one contingency plan you need two or more for every failure scenario that could happen after roll out into production. So just try to stick with one product at a time. If your Nexus Repository is not supported, upgrade it first and then launch Lifecycle.
Now imagine a company with over 200 applications in development, over 700 developers at task, where continuous integration (CI) adoption is only 30%, and where all of them are pointing to the same production Nexus Repository. Somehow, we had to fit Nexus Lifecycle into the picture and make sure it did not create a problem for anyone. The decision was to roll it out in phases because the maturity, agility, and automation of the organization simply was not there. People needed more time to wrap their heads around the new tool and process. Now, if you were to deploy Lifecycle into an enterprise where CI/CD is standard practice with 100% adoption rate, then it would be easier and faster. It was not the case here so the decision was made to break it down into 3 phases for applications that were going through CI/CD:
- Phase one was to block vulnerable components at the proxy level to fail local builds for developers. This ensured that no new vulnerable components were introduced into the production repository at the developer level.
- Phase two was to fail CI/CD builds in a test environment. It enforced developers to start cleaning up their existing code to make sure they removed vulnerable components and used libraries with non-critical policy violations.
- Phase three was to fail CI/CD builds in promote to production jobs. It ensured that no application with critical vulnerabilities would go into production.
The rest of the organization who was not using CI/CD pipelines had to go through the manual scan process. Proxy level would still block developers from pulling vulnerable components from proxy repositories on Nexus. However, it was up to governance and security teams to enforce scans of applications for vulnerabilities in later stages. Most organizations are already doing security checks manually. However, Nexus Lifecycle helps speed things up a little and provides a nice metrics dashboard and reporting that can also be saved in a PDF format.
