Automating Remediation for Application and Infrastructure Security Issues with Averlon

Overview

Today, one of the biggest challenges in scaling a vulnerability management program is that the volume of security issues keeps increasing while patching velocity has not kept pace.

Averlon provides a set of GitHub Actions that bring agentic remediation directly into CI/CD pipelines. These actions cover container images, infrastructure as code (Terraform and Pulumi), and Kubernetes Helm charts, and they generate ready-to-merge fixes for both application and infrastructure issues.

In this post, we look at how an enterprise SaaS marketing technology company uses these actions to automate remediation end to end. Their workflow uses Averlon to generate the fix as a pull request, then raises a ticket that is automatically assigned to the right developer with the PR already attached.

When it started with Averlon, the company had about 110,000 critical and high-severity issues open across its applications and infrastructure, which translated into 3,400 tickets created and assigned to developers. With Averlon, those became 260 pull requests across its application code and infrastructure findings. Security teams no longer have to chase developers to close tickets, and developers no longer spend their time working out where an issue comes from, what the fix is, or why an upgrade broke their code.

The Challenge: Remediation Before Averlon

Before Averlon, the company followed a process that will be familiar to most security and engineering teams. Scanners produced a set of issues, tickets were created for those issues, and the tickets were assigned to developers to resolve. In practice, this process broke down in four places.

The source of most issues was unknown. When a vulnerability came from a container base image, there was no clear way to tell it apart from an issue in application code. As a result, tickets that belonged to the infrastructure or platform team were routinely assigned to individual application developers.

Developers had to work out the fix on their own. A ticket identified the vulnerable package or misconfigured resource, but it did not tell the developer where in their code the change needed to be made or which version or setting would resolve it.

Upgrades introduced breaking changes. When a dependency upgrade broke existing functionality, developers had to stop, investigate the breakage, and fix it themselves. This pushed security work further down the backlog.

Many issues were found only after reaching production. Because detection happened after deployment, risky changes were already exposed by the time a ticket was created.

The Result

The company then implemented Averlon's automated remediation. Averlon maps each issue to the package and source it originates from, such as a container base image or an application dependency, and groups the fixes by that source. For each group, it creates a ready-to-merge pull request and a ticket for that PR, assigned to the developer who owns the code. The results:

• 260 fixes produced: Compared with the 3,400 tickets the team previously triaged and assigned by hand.
• No developer involvement in generating fixes: Every fix arrives as a ready-to-merge pull request.
• About 15 minutes of developer review per fix: Compared with 4 hours to research and write the same fix manually.
• Mean time to remediate down from 45 days to 6 days: Fixes now ship in the sprint they are found.

How They Implemented It: Averlon's Remediation Actions

The company now runs Averlon's remediation actions for each part of its stack. Each action analyzes the relevant changes, generates a remediation as a pull request, and creates a ticket that is automatically assigned to the responsible developer with the PR attached.

The four actions are:

• Fixing Docker image and container vulnerabilities: Analyzes Docker images and container dependencies, identifies vulnerabilities, and generates fixes for both the base image and application packages.
• Fixing IaC issues: Correlates Terraform and Pulumi plan changes with existing misconfigurations identified by Averlon, and generates the corresponding code fix.
• Fixing Kubernetes misconfigurations: Detects misconfigurations in Kubernetes Helm charts and generates remediations.
• Preventing risk from reaching production: Predicts the security impact of infrastructure changes before they are deployed and acts as a guardrail for IaC deployments.

Fixes mapped to the right code and the right owner

Averlon maps both infrastructure and application issues back to the code that introduced them. A vulnerability inherited from a base image is traced to the Dockerfile and routed to the team that owns it, while a vulnerable application dependency is traced to the relevant package manifest. Developers no longer need to work out what the fix is or where it belongs.

For example, in one Averlon-generated pull request, a container scan identified 38 vulnerabilities across several npm packages and an outdated Node.js base image. The PR upgraded the direct dependencies, replaced an abandoned package with its maintained alternative, and moved the base image from node:12-alpine to node:18-alpine, reducing vulnerabilities from 38 to 17 and resolving all critical and high-severity issues in direct dependencies.

Breaking changes handled automatically

When an upgrade introduces a breaking change, Averlon updates the affected code as part of the same PR. In the example above, the dependency upgrade required changes to template handling and a move from a synchronous to an asynchronous API. Averlon included both code changes in the PR so that existing templates and APIs continued to work, and the developer received a fix that was ready to review and merge.

Guardrails before production

The Infrastructure Risk PreCog Agent evaluates proposed infrastructure changes before they are merged. In one case, a Terraform change would have made two EC2 instances reachable from the internet. Averlon flagged that both instances carried critical remote code execution vulnerabilities in Git and Binutils, explained how internet exposure would make them exploitable, and rated the change as critical. With this information on the pull request, the team can block or fix the change before it ever reaches production.

Get Started

Averlon's remediation actions are available on the GitHub Marketplace. To get started, choose an action, review its documentation, and add it to your workflow.

• Averlon's remediation actions: GitHub Marketplace
• Learn more: Averlon platform
• See it live: Request a demo