Screwing up vulnerability management at scale, and building a startup to fix it | SubImage

Book a Demo

Book a Demo

Platform<br>Attack Path Analysis<br>Internet exposure → crown jewels

Agentic Vulnerability Remediation<br>Repo-aware agents prioritize real risk and generate exact fixes

CSPM<br>Cloud security posture frameworks

AI Asset Inventory<br>Powered by graph ontology

Company<br>Mission<br>Read our story

Careers<br>Build the future of security

Resources<br>Documentation

Blog

Changelog

Trust Center

Pricing<br>Pricing

← Back to all posts<br>Screwing up vulnerability management at scale, and building a startup to fix it<br>Jul 13, 2026

vuln-management<br>issues

by Alex Chantavy

Introducing SubImage Issues: the vulnerability remediation loop I always needed but could never build

Last week we shipped Issues, a feature that turns vulnerabilities, misconfigurations, and attack paths into prioritized work that updates (and closes!) itself. This post is the story of how we built exactly what we wish we had at previous jobs.

We got more tickets for you (jk)

Most CSPMs and security tools focus on finding problems. They scan your cloud, produce long lists of findings, attach severity scores, and leave the rest to you.

We do that too (across cloud, on-prem, identity, code, SaaS, and everything else we can pull into the graph), but finding problems is increasingly the easy part.

The hard part is deciding which ones to work on first, understanding what actually needs to change, getting that work to the right person, and knowing whether the fix really shipped. Issues is us handling that entire loop.

Inspired by our time screwing up vuln management at scale

At previous jobs on security teams, we helped bootstrap huge vulnerability management programs: I wrote about doing this at Lyft a few years back. I initially fell into the trap of treating tickets as the end of the story. My system produced hundreds of thousands of findings and blasted them at engineering teams with a “Jira ticket cannon”. Teams were overwhelmed by the volume and often confused about what they were actually being asked to change.

Meanwhile, it was really tedious to handle the messy lifecycle logic ourselves: who owns this, was it fixed within SLA, did the rebuild pick up the patched package, did anyone merge the PR, can we close the ticket, will it come back on the next scan, has someone accepted the risk, do we have a defensible reason for calling this urgent?

Or, say an auditor demands justification for why we've missed the SLA on fixing a critical vuln that affects 32-bit systems... and we do not own any 32-bit systems.

We underestimated the effort required to handle this and it burned out our team. Worse still, if left unchecked it could have burned the relationship between security and the rest of the company. Throwing tickets over the fence is a great way to get ignored as the boy who cried wolf. I eventually figured out what worked to get us out of that hole (and shared it as a talk at BSides SF 2023).

When we started SubImage, we knew we wanted to build something that followed those principles.

I used to abuse Jira as a database

We designed Issues to work differently. Instead of treating every scanner finding as its own problem, SubImage groups dozens of CVEs into single action items: e.g. update a base image from one SHA to another.

After all, nobody wants 150 tickets describing 150 symptoms of the same root cause. In my old job, due to time pressure I did exactly this and ended up treating Jira as a database. It can work, but is far from ergonomic.

Not all CVEs treated equally

With Issues, we incorporate attack path context to prioritize work. When I was on a security team, this was the obvious next thing to build, but by then we had reached the limit of what an internal security program could justify investing in. I have since heard similar things from much larger enterprises.

The priority of an Issue comes from environment context rather than severity scores like CVSS alone. We factor in whether the workload is reachable from the internet, its exploitation probability, whether a fix exists, and what the blast radius looks like if the vulnerable thing gets popped.

A CVE on an isolated internal service should be treated differently from the same CVE sitting on an internet-facing attack path with access to customer data. Attackers use this lens to decide what to attack first, and it's useful for an overwhelmed security team to decide what to defend first.

I wrote about this before, but in vuln management, there seem to be two schools of thought:

Patch everything super fast so that prioritization barely matters. Like this:

Use environmental context to focus on vulnerabilities that expose sensitive data or sit on meaningful attack paths.

I see the merit in both, but as vulnerability discovery accelerates, there is too much data to treat every finding as equally urgent. Yes, I am advocating for the midwit position in my own meme.

The U.S....