Automated Vulnerabilities Scans Without the Pain
This is still a good guide in terms of how to trigger lambdas based on CW event rule and take advantage of your existing GitLab infra to solve all sorts of things
As you improve your DevOps capabilities and maturity, sooner or later you’re going to want to add vulnerability scans. There are a number of tools you can use to scan code and containers for vulnerabilities, some more painful than others. Here is what we learned.
We use Scala, so an OWASP sbt plugin made sense. But. We also use Ruby, Go, Node, Bash and whatever else works for specific use case. So, using language specific tools was not going to scale for us, going that route meant that we need to update every project and its CI/CD.
The Goal
I read somewhere you could try to achieve what for me was an ideal scenario, and that for us kind of looked like this:

We use ECR as our registry and we know we can trigger an event when containers are pushed to it. We can connect a lambda to those events and use that information to start the vulnerability scan.
That made the effort work for every project and every language we use across the organization, cool right? Yes, but we still need to figure out what to put in our “Clair or something” box.
Clair…Or Something
When you start to read about this sort of thing, Clair always comes up. There are a couple of alternatives, but in our use case we had a several considerations:
Clair seemed like a lot of stuff, and even when there are a couple of github repos with CloudFormation Stacks or Terraform builds, still seemed like a lot of things to create and maintain.
Enter Anchore
Then I happened to come across Anchore, at first I though it was just as much or maybe more heavy than Clair was, but I did something I can’t stress enough to everyone I talk to. Dig into the repos. Repos are the best source of documentation you will ever find. Unit test and examples no one mentions in any documentation are sometimes in there!
Anchore has a repo called “ci-tools” that contains, well, CI tools, with examples for every major CI/CD tool, including:
- jenkins
- circle ci
- gitlab ci
- travis ci
- codebuild
I tested the GitLab CI example on one of my projects and it worked nicely. The inline scan they have creates all the necessary containers and scans the one you specify on the spot with no need for clusters or tons of infrastructure.
Finally, I knew what the entire picture would look like for us now!
Our Solution
A while back I wrote about how we use spot instances on our GitLab CI to save money and what that gives us is basically an on-demand pool of cheap compute.
In our scenario it became clear after testing Anchore inline scan in a project pipeline that the lambda function could trigger pipelines that would receive as parameters the container to scan.

Our gitlab-ci pipeline looks just like the one in Anchore ci tools except:
- We login to ECR where our containers are
- We parse the reports on a different stage that publish a summarized report to an SNS topic that we end up posting to our Slack.
To put all the pieces together you need to:
Enjoy!




