How it works

From first signal to closed case

Every case goes through the same twelve steps. Code decides what I'm allowed to do and when a case is done. I do the investigating and explaining.

Everything I handle

Pull request reviewsI review every pull request for security problems and leave the fix on the PR.

Nightly code reviewsI go through the code that changed overnight and only report what I can prove.

Cloud alertsI investigate GuardDuty and Security Hub findings with CloudTrail as evidence.

Leaked keysI find every place a leaked key lives and rotate them in the right order.

Vendor breachesWhen a provider you use is breached, I show what was exposed within minutes.

Former employeesI find people who left but are still in your GitHub organization.

Risky settingsI check two-factor, branch protection, secret scanning and public databases.

Audit evidenceEvery case ends with a signed record your auditor can use.

STEPS 1–4Notice

01Signal arrivesFrom a webhook, a scheduled check or a laptop. I store the raw data and its SHA-256 hash before anything else.

02NormalizeI convert it to a standard event format (OCSF) and record where it came from.

03DetectRules run on the event stream. Models don’t read every event.

04GroupRelated events become one case.

STEPS 5–8Investigate

05Gather contextCode collects the owner, recent changes, past cases, what your team has confirmed and known blind spots.

06TriageDismiss it with evidence, investigate it or escalate it.

07InvestigateA lead investigator and specialist agents work with lookup tools and a fixed budget.

08VerifyCode checks that every claim cites real evidence. Then a model from another provider argues against the conclusion.

STEPS 9–12Resolve

09ReportOne Slack thread per case, written from the verified findings.

10DecideA person approves the plan, assigns it, or accepts the risk until a set date.

11ActThe executor runs the approved plan one step at a time.

12ConfirmI read back the live state, then close the case.

Workflow

From alert to verified fix

Here's one case from start to finish. You only step in when a decision needs a person.

STEP 01 OF 06

Signal comes in

An alert from GuardDuty, a push to a pull request or a vendor advisory. I save the raw data first, then merge duplicates so one problem becomes one case.

AverilSaves the evidence and merges duplicates.

YouNothing yet.

# eng-securityThreadHIGHOPEN

AverilAPP3:14 AM

Opened a case. Three signals point at the same thing, so I merged them.

GuardDuty 03:09 Unusual API calls from deploy-bot

GuardDuty 03:11 Same role, same source IPDUPLICATE

Security Hub 03:12 Secrets read outside a deploy window

3 signals in · 1 case out

Reply…

A team with a second opinion

I work as a small team of agents. They pass each other structured findings tied to evidence, never raw transcripts. Before anything reaches you, a verifier built on a different model provider checks the conclusion.

TriageDecides whether to dismiss, investigate or escalate.

Lead investigatorPlans the investigation and writes up the result.

Cloud and identityIAM, CloudTrail, Okta and Workspace.

Code and supply chainRepositories, dependencies, CI.

Endpoint and SaaSLaptops, coding agents, SaaS apps.

Threat intelAdvisories, known exploits, vendor incidents.

VerifierA model from another provider that challenges the conclusion.

ScribeWrites the Slack thread from the verified result.

Verified or owner-confirmed

I mark a case verified only when the live state matches what the plan said would happen. If only a person can confirm the fix, the case is marked owner-confirmed and counted separately. We report both numbers.

Time to verified resolutionVerified-resolution rateOwner-confirmed shareReopen rate, 30 days

CASE STATES

OPENTRIAGINGINVESTIGATINGAWAITING HUMANACTION PLANNEDVERIFYINGRESOLVED

DISMISSED WITH REASONRISK ACCEPTED UNTILESCALATEDREOPENED

Any closed case can reopen, with a version number and a reason. Nothing in the timeline is ever edited or deleted.