Defuse

• 

• 

• 

• 

• 

• 

Inspiration

The Keyv npm worm in August 2026 really got me thinking. That thing was jumping between organizations every 2 to 7 minutes, using victims’ own release pipelines with valid provenance. Then I read about how revoking a stolen token can actually fire the attacker’s revocation handler, and if you cut registry and source access at the same time, it trips a dead man’s switch that wipes the host.

Basically, every incident response playbook out there says "rotate all your secrets," but doing that naively is literally the detonator. That blew my mind. My first thought was to revoke everything immediately. But some worms have triggers that can make that response cause more damage. That became the idea behind Defuse: help people contain an attack in the right order.

There has to be a safe order to do this stuff, and nobody had automated figuring that out.

What it does

Defuse maps how a compromised package could spread through GitLab CI. It connects affected jobs to runners, hosts, accessible credentials, and packages those credentials could publish.

It then builds an ordered containment plan. That includes isolating hosts, preserving evidence, rotating credentials, removing malicious hooks, and rebuilding safely.

The console lets you explore the exposure map, understand why each action comes next, and review the action history. There is also a replay that compares an immediate revoke-everything response with Defuse’s planned response.

The local demo works today. Fully automated live containment is still something I’m building toward.

How we built it

I built the engine in Python, with FastAPI serving the API and a Svelte frontend for the console.

The core is an exposure graph and a deterministic planner. I encoded six safety constraints that control the order of containment actions. The plan can then be turned into a GitLab child pipeline, with dependencies between actions.

I kept AI focused on interpreting advisories, drafting changes, and explaining results. The planner and executor stay in code, and AI output has to pass schema validation before anything uses it.

Defuse collects credential names and access metadata without reading secret values. I also built a guarded sandbox simulator so I could test the response safely.

Challenges we ran into

The hardest part was handling what happens when an action fails or needs a person to finish it. If isolation fails, credential rotation cannot just continue. I had to make those dependencies hold during execution as well as planning.

Verification was another challenge. A missing signal should never count as proof that an incident is resolved. I made the system keep work incomplete when the evidence is missing.

I also had to make a fairly complicated process understandable in the console, especially when explaining why one action has to wait for another.

Accomplishments that we're proud of

I’m proud of the replay because it makes the main idea easy to see. In the modeled scenario, the naive response triggers damage while the ordered plan preserves the sentinel.

I’m also proud of checking the planner against 500 generated exposure graphs, with a separate checker for the safety constraints.

Getting the map, plan explanations, live updates, and action records working together made Defuse feel like something a person could actually use during an incident.

What we learned

I learned that knowing what to do is only half the problem. The order matters just as much.

I also learned to separate a successful demo from a verified result. Passing local tests is useful, but it does not prove that a live incident has been contained.

What's next for Defuse

Next, I want to finish the live GitLab and Google Cloud integration, connect the Duo flows end to end, and complete secure credential replacement.

Then I want to run fresh sandbox incidents and collect real evidence and timings. The goal is to take Defuse from a working local demonstration to a system that can carry out and verify the full containment process.

Built With

• fastapi
• gitlab-ci/cd
• google-cloud
• postgresql
• pydantic
• python
• sqlalchemy
• svelte
• terraform