In Part 1 we looked at the mechanics of using a webhook from Red Hat Quay to trigger a Lifecycle evaluation of a container. In part 2, we'll explore why that matters from a SDLC perspective and how two webhooks can do a lot towards DevSecOps.
The first thing that comes to mind for me is that the registry might be the best place to start capturing container scans. The registry makes for a nice choke point to begin the roll-out of adding security scans to your CI/CD pipeline. Updating every CI job can be a challenge but a single webhook in a registry can immediately start capturing all of the containers flowing into it. Thanks to the Nexus Lifecycle automatic application creation feature we don't have to even do anything in Lifecycle except ensure that it is turned on. I like to associate the app creation feature with an organization I call onBoarding. I can even turn on Grandfathering if I want to automatically accept any current risk since this will be our first scan, even though the application has been around for a while.
Later, when I'm ready to turn the scan on for the builds, I can move this app into the organization it belongs to, and categorize it, to apply any additional policies that are needed. I feel this strikes a nice balance to be able to turn on security scans for everything, without interrupting the current pipeline. Over time, we can work with delivery teams to update their builds and configure their IDE's to push the feedback further left.
The second reason I really like using a webhook in a registry is because I'm seeing a new pattern emerge when it comes to containers.
I'm seeing this toll gating process becoming common as Operations folks look to ensure no one can deploy an image from DockerHub straight to Prod while ensuring quality and security checks are passing. It also means you could be using a docker registry in Nexus Repository to support you build environments and later push the images to pass the toll gate to a Quay instance that feeds you production clusters. Or, it could be a registry provided by your cloud provider, it doesn't really matter. Truth is, this simple pattern creates a lot of flexibility and options for controlling the flow of containers to production.
The first webhook captures the inputs and can trigger both OS layer and Application layer component scans. In addition to traditional testing you'll also want to know how this container stacks up against the Docker CIS Workbench and other compliance items. For that, I turn to Twistlock which provides runtime protection so the very act of deploying a container for testing gets tested by Twistlock.
Once all of your testing looks good, the image can be promoted to the Release registry where it will be automatically deployed and another webhook can update Nexus Lifecycle to move the bill of materials to a phase where it will be continuously monitored for any new vulnerabilities while it's running in production. That's a lot of work for just two webhooks in the registries and a delivery aware tool like Twistlock.
When I pull back and look I see a nice path for quick wins in a rollout with very little friction or overhead by starting on delivery side of the SDLC. Our Firewall solution can also immediately close the front door to new defective components entering the supply chain while grandfathering lets us accept current risk, but then immediately stop net new vulnerabilities as they appear. All while new projects are automatically being added when they come online. Beats the heck out of updating all of the build jobs.
