On-Demand Product Demo: From Vulnerability Backlogs to Preventing Exploitable Risk

Rajeev Raghunarayan:
All right, thank you for joining everyone. I’m Rajeev Raghunarayan, and I lead go-to-market at Averlon.

Over the years, I’ve noticed one consistent pattern in security. We’ve improved detection. We’ve improved visibility. But what happens after detection is still a problem that most security leaders and practitioners continue to face. Deciding what to fix, coordinating with engineering, and actually reducing risk is where most teams struggle.

Today, that challenge is only getting harder.

As AI accelerates software delivery, more teams are shipping more changes, more dependencies are being introduced, and more issues are showing up in the pipeline. At the same time, there’s increasing pressure to fix things faster, but without slowing engineering teams down.

That’s the problem we’re going to focus on today.

Before we get into the platform, I want to ground this in why this problem exists and why it’s getting worse.

AI is fundamentally changing development velocity. Pull requests that used to take close to 9 to 10 days are now happening in a fraction of that time, often around 2 to 3 days. Developers are shipping faster, and most organizations today are already using AI in their workflows.

At the same time, a large portion of AI-generated code still contains flaws.

So what does that mean in practice?

It means more code is being written, more changes are being deployed, and more vulnerabilities are being introduced into the system. And the traditional model of scanning after deployment and pushing findings back to developers simply cannot keep up.

What ends up happening is that findings get turned into tickets, tickets get added to backlogs, and those backlogs keep growing. Developers only have so much capacity, and security becomes a bottleneck.

If we want to fix this, security needs to operate at the same speed as development and within the developer workflow. It needs to act as a velocity enabler rather than just a gatekeeper.

What if security could identify the small subset of changes that actually introduce risk, fix those directly in the developer workflow, and allow everything else to move fast?

That’s the problem Averlon is focused on solving.

Rajeev Raghunarayan:
What Averlon does differently is that we analyze risk in the context of your runtime environment.

We run risk analysis agents that understand what issues might actually be exposed if a piece of code reaches production. We look at what kind of exploits could be possible, and more importantly, what fixes are required to prevent that exposure.

Most changes are safe. In many environments, 90 to 95 percent of changes don’t introduce meaningful risk. But the remaining few changes are the ones that matter. Those are the ones that expose the organization.

If we can identify and fix those early, directly in the developer workflow, we can prevent issues from ever reaching production.

At the same time, we also help reduce existing backlog. We triage what’s already in your environment and generate remediation recommendations that developers can act on.

So there are really two parts to the platform. One is prevention, stopping new issues from entering the backlog. The other is remediation, reducing the backlog you already have.

Manish Datla:
Let’s walk through how vulnerability management traditionally works.

You have scanners detecting issues across your infrastructure and applications. These could be infrastructure scanners, application scanners, or cloud security tools.

Once issues are detected, they are prioritized. If the volume is high, teams often bring in additional security engineers or use triage tools to determine which issues actually matter.

After triage, you identify a subset of critical issues and then hand them off to developers. Typically, this is done through tickets.

Now, this process introduces several challenges.

First, these tickets pile up in the backlog. Teams try to prioritize them, but the backlog keeps growing. SLAs are missed, and the organization continues to carry risk.

Second, developers have to do a lot of work once they pick up a ticket. They need to understand where the issue originated, map it back to the relevant code or configuration, and then figure out how to fix it.

For example, if an issue is detected in a container image, the developer needs to trace it back to the Dockerfile. If it’s a misconfiguration, they need to identify which Terraform file or configuration caused it.

This takes time and adds friction.

Third, there is inherent latency in the process. By the time an issue is detected, prioritized, and assigned, it may have already been present in the environment for a significant period.

So even though detection has improved, the actual process of reducing risk remains slow and inefficient.

Averlon changes this model.

Instead of creating tickets and expecting developers to figure out fixes, we generate pull requests directly. These pull requests include the necessary fixes, and they are delivered directly into the developer workflow.

The developer’s role becomes reviewing and merging the PR, rather than investigating and figuring out what to do.

Manish Datla:
Averlon operates across four major areas.

The first is container vulnerabilities. We analyze container images and identify vulnerabilities across different layers, including base images and application dependencies. We generate separate pull requests for each, so developers can review them appropriately.

The second is cloud misconfigurations. We map findings back to infrastructure as code and generate fixes directly in those configurations.

The third is Kubernetes environments. We detect vulnerabilities and misconfigurations across pods, containers, and deployments, and generate the necessary fixes.

The fourth is prevention. We analyze changes before they are deployed and determine whether they introduce new risk.

Manish Datla:
Let’s look at a container example.

For a given container image, Averlon identifies vulnerabilities and determines where they originate. Some issues come from the base image, while others come from application layers.

We generate separate pull requests for these.

Base image changes are treated as higher-impact changes and are surfaced separately. Application-level changes, such as dependency upgrades, are handled independently.

This allows developers to review and apply changes more effectively.

In cases where upgrades introduce breaking changes, we account for that as well.

For example, if a package is deprecated, we don’t just upgrade it. We replace it with a supported package and update the code accordingly. This ensures that the fix is complete and doesn’t introduce new issues.

Manish Datla:
Now let’s look at prevention.

Consider a scenario where a developer modifies a security group and adds broader ingress and egress rules.

Traditionally, this change would be deployed, and then a cloud security tool would detect that it exposes certain assets. A ticket would be created, and the team would go back and fix it.

With Averlon, we detect this before deployment.

We analyze the change and determine which assets would be exposed. We also evaluate whether those assets have exploitable vulnerabilities.

For example, if an asset has a remote code execution vulnerability and is suddenly exposed to the internet, the risk increases significantly.

We provide this context upfront, allowing teams to stop the change before it introduces risk.

Manish Datla:
We also analyze identity and access changes.

If a developer expands permissions in an IAM policy, granting access to services like S3, DynamoDB, or RDS, we evaluate the impact of those changes.

We determine which roles gain access, whether those roles are associated with compute resources, and whether that creates a path for exploitation.

For example, if a role is assumed by a compute instance that has a vulnerability, an attacker could use that path to access sensitive data.

By providing this level of context, we help teams understand not just what changed, but why it matters and what the potential impact is.

Manish Datla:
Across all of this, the goal is consistent.

We move away from a model where issues are detected after the fact and managed through tickets and backlogs.

Instead, we generate fixes directly, deliver them into the developer workflow, and provide the context needed to make decisions quickly.

This reduces friction, improves remediation speed, and allows teams to focus on actually reducing risk.

Rajeev Raghunarayan:
To summarize, Averlon is focused on operationalizing the part of security that actually reduces risk.

It’s not just about finding more issues. It’s about making better decisions, coordinating effectively, and executing fixes quickly.

Prevention plays a critical role here. By identifying risky changes early, we can reduce the number of issues that ever make it into production.

At the same time, we continue to help reduce existing backlog by prioritizing and fixing what actually matters.

If this resonates with you, or if you’d like to see how this would apply in your environment, we’d be happy to continue the conversation.

Thank you for joining us today.