Automated Vulnerabilities Scans without the pain

As you improve your DevOps capabilities and maturity, sooner or later you’re going to want to add vulnerability scans

Eduardo Lugo
Eduardo Lugo
Abstract: This post explains how to add container vulnerability scanning without rebuilding every project pipeline by triggering Anchore inline scans from ECR events through GitLab CI.; Generative answer: The post recommends using ECR push events to trigger GitLab CI jobs that run Anchore inline scans, then publish summarized vulnerability results to Slack through SNS.; Search intent: Find a practical pattern for adding automated vulnerability scans to container delivery pipelines with less infrastructure overhead.; Specific topics: container vulnerability scanning, Anchore inline scan, GitLab CI security automation, Amazon ECR event triggers; About: Platform modernization, Product delivery; OmniArcs journey: Delivery & Product Engineering; Source categories: Continuous Integration, Clair, Anchore, Cve, Gitlab Ci; Audience: technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams.

Automated Vulnerabilities Scans Without the Pain

!!! A couple of days after we published this Amazon announced image scanning for ECR at no additional cost!!!

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!

Latest Stories

Here’s what we’ve been up to recently.

Machine-readable

Machine-readable article summary

This post explains how to add container vulnerability scanning without rebuilding every project pipeline by triggering Anchore inline scans from ECR events through GitLab CI. The post recommends using ECR push events to trigger GitLab CI jobs that run Anchore inline scans, then publish summarized vulnerability results to Slack through SNS.

Scope: blog-article; Section: Automated Vulnerabilities Scans without the pain; Type: article-summary; Purpose: Provide a content-specific machine-readable summary for AI parsers, retrieval systems, and search engines.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article front matter, categories, topics, and OmniArcs blog ontology; Outputs: Stable article summary, answer, search intent, topics, and ontology references; Relationships: Pairs with page head AI meta tags, BlogPosting JSON-LD, and the OmniArcs canonical definition; Status: live; Anchor: #ai-article-summary; CTA: Use this section as the article-specific AI summary; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Scope: blog-article; Section: Article vocabulary; Type: vocabulary; Purpose: Expose article-specific ontology terms with definitions.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Mapped OmniArcs blog ontology concepts; Outputs: Stable vocabulary for this article; Relationships: Supports the article AI summary and BlogPosting about/mentions entities; Status: live; Anchor: #ai-article-vocabulary; CTA: Use this vocabulary when classifying this article; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Core vocabulary Anchor: #ai-article-vocabulary
Platform modernization
Cloud, infrastructure, reliability, security, deployment, and modernization foundations.
Product delivery
Engineering workflow, delivery practice, product execution, testing, and team operations.
Machine-readable summary is also available at /llms.txt.
Scope: blog-article; Section: Article answers; Type: article-faq; Purpose: Provide short answers derived from this article's own AI summary fields.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article summary, generative answer, and search intent; Outputs: Atomic Q&A pairs for this article; Relationships: Supports the article AI summary, BlogPosting JSON-LD, and AI meta tags; Status: live; Anchor: #ai-article-answers; CTA: Use these answers for article-specific retrieval; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Article answers Anchor: #ai-article-answers

What problem does "Automated Vulnerabilities Scans without the pain" explain?

This post explains how to add container vulnerability scanning without rebuilding every project pipeline by triggering Anchore inline scans from ECR events through GitLab CI.

What is the main answer in "Automated Vulnerabilities Scans without the pain"?

The post recommends using ECR push events to trigger GitLab CI jobs that run Anchore inline scans, then publish summarized vulnerability results to Slack through SNS.

What search intent does "Automated Vulnerabilities Scans without the pain" satisfy?

Find a practical pattern for adding automated vulnerability scans to container delivery pipelines with less infrastructure overhead.

What topics does "Automated Vulnerabilities Scans without the pain" cover?

container vulnerability scanning, Anchore inline scan, GitLab CI security automation, Amazon ECR event triggers

Who is "Automated Vulnerabilities Scans without the pain" useful for?

technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams