Governed vulnerability remediation
Context
Security findings in software dependencies arrive steadily, and fixing them is necessary but repetitive: evaluate the finding, find the affected repository, update the dependency, and move the change through review. In the engineering organization I worked in, that work had grown large enough to take real capacity away from product and platform improvements.
We took the problem into an internal innovation competition, with about eight weeks to build a working entry alongside our normal responsibilities.
Problem
The goal wasn’t unsupervised remediation. It was to automate the predictable preparation work while a person still reviewed every change:
- prioritize findings that were suitable for an automated fix
- update dependencies to a known fixed version
- group changes sensibly
- open merge requests and notify the team
Constraints
- Time. Eight weeks, on top of regular work.
- Governance. The project began as an exploration of AI-assisted remediation, but there was no clear approval path for AI or agent-based systems.
- Access. The team that owned the ticketing platform liked the idea but wanted an additional review of the integration, which couldn’t finish inside the competition window. The source-control platform team had related work of its own underway and didn’t provide the access we requested.
My role
I came up with the project, formed a three-person team, and set the scope and technical direction. I designed and built the working prototype in Go, except for the mock ticketing service, which a teammate built. Our third teammate contributed research and helped shape the final presentation.
Day to day, leading meant deciding what was in scope, making the technical and product calls, assigning work, keeping us on pace for the deadline, and leading the final demonstration.
Key decisions
Remove AI from the delivered scope
When it became clear the approval path for AI couldn’t be resolved in eight weeks, I cut AI from the scope and built a deterministic workflow with explicit rules instead. That made the prototype narrower, but it also made it finishable and defensible.
Route by severity
High and critical findings needed attention now, so they got an immediate merge request. Medium and low findings waited for a batching window and were grouped together, which cut merge-request noise and kept the review load manageable. When an urgent merge request was opened, pending lower-severity dependency changes could be included when it made sense.
Keep a person in charge of every change
The system prepared a dependency change and opened a merge request. It never merged or deployed anything. Every change on both paths waited for a person to review and approve it.
Keep the remediation narrow
It only updated a dependency when the finding supplied a known fixed version. Anything more ambiguous stayed out of scope.
Mock what we couldn’t reach in time
Rather than miss the deadline waiting on integration reviews, we built a mock findings service and used a test repository. That let us demonstrate the complete workflow safely and on time.
Outcome
The entry won first place, judged by engineering and product leaders. The demonstration ran the whole path on mocked findings and a test repository: severity routing, bounded dependency changes, merge requests, team notification, and human approval.
It never ran against live vulnerability data, never reached production, and wasn’t developed further. The source-control platform team was already pursuing related work.
What I learned
- Simplifying was what made it real. Cutting scope wasn’t a retreat from the idea; it’s what let a small team finish something coherent and credible.
- Small teams under a deadline need clarity. Clear expectations and decisive direction mattered more than anything else I did as the lead.
- Where I’d take it next. I’d start from this MVP. Once access, governance, and reliable validation were in place, I’d explore where AI could extend remediation beyond explicit version bumps, while keeping human approval, bounded actions, and auditable decisions.
I’m exploring that direction now in two open-source projects that are still in development: a small Go runtime for bounded, approval-gated agents, and a dependency-upgrade assistant built on it.