Transcript
Specifically, we'll see how you can integrate Lacework 40 CNAP into the build process to improve visibility and gain valuable insights with actionable outcomes. Lacework Infrastructure as Code Security integrates with your existing Git repositories to scan your IAC files for compliance violations. We get started with a single click, and go to the IAC security page where we choose our Git provider, in this case, GitHub. I click my organization, select all repositories, and click install and authorize. The Lacework IAC bot is now integrated into my repositories and will complete automated scans. I can click here to see the results of the first integration. Let's choose a repository and look at the findings for that repository. On the left-hand side, we can see the policy name, the severity, and the line of code that was in violation. Click to see the summary and guidelines for remediation. In some cases, the IAC bot can suggest a fix for you. If we choose autofix available filter, we can see all of those here. If I were to click the fix now button, I could open a pull request, commonly referred to as a PR, inside my Git repository with the suggested change. Here's an example of an autofix PR raised by Lacework IAC security where we can see the details on the policy that was in violation and the suggested fixes. From here, we can choose to commit the change which remediates that compliance violation. We're back in the Lacework console and we're going to look at how we can prevent vulnerable container images from reaching production. In the Lacework console, we click settings and container registries. Clicking the add new shows all of the container registry types we can integrate with. To catch these violations during the build process, we can use the inline scanner. To configure the inline scanner, we click next. Now for each inline scanner I configure, I'll be given a unique token. At the top, we give it a friendly name and open up additional settings. We can see here limiting the number of scans per hour, the identifier tag, and the CI CD policy that's associated with the token. Here we are in my GitHub repository. I'm using GitHub actions for this example, and I've already integrated the inline scanner. So let's take a look at how I've done that. My main workflow is called deploy.yaml, and there are a bunch of jobs here that are dependent on one another. Essentially, they operate in order. I'll do a build of my image, then an inline scan, and if that's successful, I can do a deploy to dev, prod, or stage, depending on how that workflow goes. I've called this secondary-lacework-voln-check so I can separate out what we're working on here. I've passed a couple of parameters, where my image is, what the image name is, and the image tag. We're running the inline scanner as a Docker container, and we're passing it some options. We're asking it to mount a volume, and we're passing it some variables that define our access token and the account name, so we can integrate our inline scanner back up into the Lacework console. You'll remember we created a policy here to block on critical CVEs. As a final step, I run the inline scanner to evaluate my image. I specify that the scanner should fail on exit, save the results to the console, and ensure that I'm using the console policy, and tag this execution with the CI build and build ID so I can trace it from my GitHub action back into the Lacework console. Here's an example of my pipeline failing when the inline scanner finds a vulnerability. As we can see here, the Lacework inline scanner job has failed, and it's prevented me from deploying to staging, dev, or production. If we dig in, we can see the details of the Lacework scanner. And in fact, if we scroll to the top, we can see the two critical vulnerabilities were found that were also fixable, which meets our policy. And at the very bottom, we can see our policy is even referenced in the output. Now if I wanted to trace this back to the Lacework console, I can find the build ID we tagged, which is 263.662.9058. And in the Lacework console, we go to vulnerabilities, containers, and in our filters, we find build ID. We enter our matching build ID and hit enter. And as we can see, the results of our scan are captured here. At this point, we've seen the process from start to finish. Our pipeline failed, our pipeline did what our policy said, and the results were returned to the Lacework console. We have full traceability end to end, and we're preventing vulnerable images from getting into our production environment. And that's a brief overview of some ways Lacework can secure your build. With these features and our integration into the Kubernetes Admission Controller, which is your last line of defense before an image reaches your production cluster, you can make sure your code is secure before it's deployed, saving you time and money. The Lacework platform makes data more accessible to all teams, removing silos and providing a single source of truth so you can get the insights and context you need to act faster. Thank you for taking the time. Contact us to hear more about how Lacework can secure your cloud environment from build to runtime.
