Why 32 Threat Leads Did Not Become Hunt Packages
A production snapshot of ThreatWatch shows how corroboration, observables, ATT&CK context, and readiness thresholds keep developing leads out of the qualified hunt queue.
One or two substantive articles each month. I write about the decisions, failures, and evidence behind ThreatWatch and RedBlue, with enough source material for a reader to challenge the conclusion.
A production snapshot of ThreatWatch shows how corroboration, observables, ATT&CK context, and readiness thresholds keep developing leads out of the qualified hunt queue.
Why RedBlue keeps public asset research separate from direct testing, and what NIST and bug-bounty scope guidance say about authority.
An August RedBlue retrospective on registrable domains, retained subdomains, and why better enumeration must remain behind an exact scope boundary.
A July RedBlue retrospective on one deterministic scan brain, durable triage, and using model output as advice rather than authority.
A June engineering retrospective on scanner-dropout visibility, reachability-aware priority, and why zero findings need an execution record.
A May RedBlue retrospective on making scan mode visible, skipping loud checks, and keeping escalation an explicit operator decision.
An April retrospective on source growth, silent failures, test coverage, and the point where feed count stopped being a useful quality measure.
A March build retrospective on recursive asset discovery, deterministic reporting, and why optional intelligence should never become a platform dependency.
A session-focused reading of adversary-in-the-middle phishing, why the phrase MFA bypass is imprecise, and where phishing-resistant authentication helps.
My January review of many-shot jailbreaking changed how I think about retrieved context, repeated examples, and the security boundary around model-assisted tools.
Earlier build notes remain available for context. They are historical records, not current research claims.
Why incomplete source material should lower confidence, and where I draw the evidence boundary between ThreatWatch and RedBlue.
I stopped asking severity to do all the work and added exploitation evidence, exposure, and authoritative catalogues.
Automated vulnerability research is moving quickly. I am more interested in adaptable evidence pipelines than precise forecasts.
Why I put collection reliability ahead of more feeds, and exposure context ahead of raw vulnerability severity.
Connecting RedBlue to real evidence exposed the places where enrichment ends and analyst judgement must begin.
I published the first RedBlue dashboard and made the loop from external visibility to defensive action visible.
The first RedBlue data flow worked, and ThreatWatch made the case for measuring unique signal rather than source count.
I tightened duplicate grouping in ThreatWatch and drew a firmer evidence boundary for what RedBlue can consume.
A reachable feed can still be stale. I made freshness visible so old data no longer looked current.
The first RedBlue dashboard showed me where the modules connected and where the evidence contracts were still weak.