Named actors, not “the adversary”
DPRK, criminal APTs, cryptonative attackers, and insiders each have different objectives and ways in. Knowing which ones are interested in you is how you build defenses that matter.
BlockThreat vCISO
Attackers see the whole system. Your security program should too.
We bring senior, hands-on security leadership tailored to how your organization actually operates. Current blockchain threat intelligence and incident data dating to 2011 show which actors and attack paths matter to your organization now. We model how failures can compound across the whole system, identify the few paths that could become existential, and turn them into prioritized controls, training, incident plans, and rehearsed response.
- $10B+
- In protocol assets across engagements
- 20+ years
- Securing financial infrastructure
- 7 years
- Of original blockchain incident research
- 4–6 weeks
- Kickoff to final debrief, typically
What actually threatens you
What would end your project is not on anyone’s list.
Two protocols with the same architecture do not share the same crown jewels, the same adversaries, or the same worst day. The work is finding what is genuinely existential for your organization, matching it against how threat actors are operating right now, and building controls in that order.
The surface keeps moving, too. Each of these was a first, and each was visible in the intelligence before it reached the next victim.
-
KelpDAO
A trust boundary nobody had drawn
Forged messages arrived through third-party infrastructure Kelp had every reason to rely on. Until it happened, almost nobody’s threat model had a line for the provider you silently inherit trust from.
-
Bybit
A precedent that was already public
$1.43 billion, taken by subverting what the signers saw before they approved. Radiant had lost $58 million to that same pattern months earlier, with a published post-mortem anyone could read. The intelligence existed. Acting on it was nobody’s job.
-
Drift
The threat model changed shape
Signers were worked in person, at conferences, over six months. No one in this industry had previously had to treat a handshake at a side event as an intrusion path. Now everyone does.
How priorities get set
Threat Intelligence decides what you fix first.
Instead of checking controls one by one, we rank findings against who attacks projects like yours and how they operate. The result is a short list ordered by what could be existential for you.
The tactics active this month
Malicious npm packages, fake recruiter pipelines, image-based exploits delivered over Slack, signing requests forged on the way to a hardware wallet. BlockThreat publishes weekly, so the intelligence your threat model is built from is days old, not quarters.
Post-mortems matched to your architecture
Every finding anchors to a real incident at a comparable project: the specific misconfiguration, the specific process gap, the specific assumption that failed. Run a lending market and you get Radiant, UwU, Euler, and Sonne dissected against your own contracts, not a generic line item about validating inputs.
How the engagement runs
Five modules, scoped to what you actually need.
Most teams run all five. Some already have a threat model and want the tabletop, or want training first and the rest later. Scope is agreed before anything is signed.
-
01
Threat intelligence & training
Less a module than the layer the other four run on. Current threat actor profiles, their live tactics, and the incidents at comparable projects are delivered as briefings your whole team attends and used as the input that ranks every finding the engagement produces. Built from your stack, not a generic awareness deck.
-
02
Threat modeling exercise
Technical interviews across smart contracts, infrastructure, key management, and personnel, plus a review of your documentation, dependencies, and past audits. The output maps every threat to your architecture, with severity, probability, and the mitigations that answer each one.
-
03
Security & IR program evaluation
An honest assessment of whether you could detect, triage, and contain a live incident today. Monitoring coverage, alerting, escalation paths, who holds the pause key, and how long it actually takes to use it.
-
04
Tabletop exercise
Closer to a Dungeons & Dragons session than an exam, and deliberately so. Four to five hours of guided scenario built against your own architecture, with timed injects that escalate: a malicious governance proposal, a social media meltdown, an attacker negotiating onchain, a compromised insider, a call from the FBI. You find the gaps here rather than at three in the morning.
-
05
Security development plan
Everything learned, turned into a prioritized 30/60/90 day roadmap with cost estimates, owners, and a shortlist of the specific vendors worth buying for each gap. The thing you present to your board, not a list of complaints.
What gets examined
Security beyond the contracts.
Scope is tailored to your architecture. We examine the onchain, operational, and human systems an attacker could use to create an existential loss.
Onchain systems
Core protocol, privileged controls, and asset movement.
Chain infrastructure
Consensus, validators, and production network operations, where applicable.
Keys & governance
How high-impact decisions are authorized and independently verified.
Critical dependencies
Trust inherited from integrations and external providers.
Offchain infrastructure
The systems that build, host, operate, and monitor the product.
People & operations
The access, endpoints, and processes attackers target around the technology.
What you keep
Four documents your team runs on afterwards.
Not a slide deck and a goodbye. These are working documents, written to be maintained by your team long after the engagement closes.
The map every future security decision is made against
A living map of every component, threat, and mitigation, prioritized using current incident data. It guides future audit scopes, hiring, policy, and incident response long after the engagement.
What to do, decided before you need it
Severity guidelines, triage process, incident roles, war room procedure, and a contact book. Shipped with an incident template and a playbook template so your team can keep writing playbooks for scenarios only you know about.
The gaps found while it was still an exercise
The scenario as run, what your team did, where the response stalled, and what to fix. Usually the single most uncomfortable and most useful artifact of the engagement.
A 30/60/90 roadmap with prices attached
Each mitigation tied back to the threat it answers, sorted by urgency and cost, with concrete monitoring heuristics and named vendors where buying beats building.
Protocols, chains, and infrastructure teams.
What to expect from an engagement.
We already run audits. Why do we need this?
Keep running them. The vectors section above is what happens when a whole industry gets good at auditing. An audit certifies the code in front of it at a moment in time. It does not cover the laptop that signs your multisig transactions, the Discord message that carried the spell address, the contractor you hired last month, or how long it takes your team to reach a signer at 3am on a Sunday. That is what this covers.
How is this different from an OPSEC audit or checklist?
An OPSEC audit typically tests a known set of controls at a point in time. This engagement models the whole system: how contracts, keys, governance, infrastructure, people, and dependencies interact, where one failure can compound another, and which risks matter most given current attacker behavior. The result is a prioritized security program, not a longer checklist.
Do you execute the fixes, or only advise?
Advisory. No deployment, no configuration changes, no signing duties, no access to your production systems or keys. You get the analysis, the plan, and the priorities; your team keeps control of everything that touches production. Where a mitigation is better bought than built, the plan names the vendors worth evaluating.
Is this an incident response service?
No. It builds the capability you would use during an incident: the plan, the playbooks, the monitoring heuristics, and the practice. It is not a retained responder who picks up the phone mid-hack, though the tabletop is deliberately designed to make that phone call go better.
How mature does our security program need to be?
It does not. Teams have started this with nothing but audited contracts and a group chat, and teams have started it with a full security function wanting a second opinion on their threat model. What matters is that someone on your side can own the follow-through, because the roadmap is only worth what gets done with it.
What do we need to provide?
Time and candour, mostly. Access to documentation, architecture, dependencies, and past audits, plus the right people made available for interviews on a reasonable schedule. The engagement runs on a tight calendar, and slow responses are the single most common reason a deliverable slips. The engagement letter says so explicitly.
Can we do just the training, or just the tabletop?
Yes. Security awareness and operational security training is regularly delivered on its own, as sessions covering the latest threat actor tactics for the whole company plus a technical session for engineers and infrastructure operators. A standalone tabletop works too, though it is more useful once a threat model exists to build the scenario from.
How is this priced?
Hourly, against a capped number of hours per module, agreed before anything starts. The total depends on scope, system complexity, and how many modules you want. Send the form below and you will get a written proposal with the hours, the modules, and the fixed maximum.
BlockThreat vCISO
Tell us what you are defending.
What you have built, what worries you, and when you need it done by. You will get an honest read on whether this is the right thing to spend money on, including if it is not.