How is a vulnerability assessment different from a smart-contract audit for a DeFi protocol?

An audit reads contract code for logic flaws. A vulnerability assessment is a breadth-first, recurring review of the internet-facing and third-party surface around the contracts: hosts, domains, exposed services, the scripts and packages the front end loads, and known-vulnerable software in the off-chain stack. The audit answers whether the code is correct; the assessment answers what is exposed and out of date right now.

Would a vulnerability assessment have caught the Ledger Connect Kit compromise?

Not as it happened. The malicious versions were live for roughly five hours, and a periodic assessment will not land inside a window that short. What an assessment does is establish which third-party scripts and packages your front end depends on, whether they are pinned and integrity-checked, and who at your organization holds publishing rights to the ones you control. Those controls are what limit the blast radius of a compromised dependency.

How often should a DeFi protocol run one?

There is no regulatory calendar for most protocols, so cadence follows how fast your surface changes. Re-run it after every front-end release that adds an external origin or dependency, after infrastructure changes, and on a recurring schedule the team can sustain. AnySec offers a quarterly or monthly recurring option on the Vulnerability Assessment service.

Do you scan smart contracts or on-chain state?

No. Contract code review is a separate specialist engagement and is not part of a vulnerability assessment. The assessment covers off-chain assets you own and can authorize: domains, hosts, APIs, front-end dependencies, keeper and relayer services and cloud configuration.

Can you assess our RPC provider or wallet vendor?

Only assets you own or can authorize. A third party's infrastructure needs that party's own permission and is out of scope by default. We can assess how your own systems depend on them, such as what your front end loads from their origins and whether that content is integrity-checked.

Vulnerability Assessment for a DeFi Protocol: Inventory What Your Front End Loads

The short answer

For a DeFi protocol, a vulnerability assessment should be a recurring, breadth-first inventory of the off-chain surface: domains and hosts, exposed services, the front end and every third-party script or package it loads, and the keeper, relayer and API infrastructure behind it. Findings are manually validated and ranked. It does not review contract code, and it does not prove an attacker can chain findings into a theft. That is the job of an audit and a penetration test.

Who this is for

This is written for a protocol security lead or engineering lead who has an audit, may have a bounty, and wants a repeatable answer to "what do we expose and what is out of date?" It is not for you if you need contract review, or if you operate a custodial exchange, where the recurring assessment cadence for a crypto exchange applies.

Why the front end's dependencies are the interesting part

On 14 December 2023, attackers published three malicious versions of the Ledger Connect Kit, a JavaScript library decentralized apps use to connect to Ledger hardware wallets. According to Ledger's incident report, a former employee's npm account was phished, bypassing two-factor authentication through a session token, and the attacker uploaded versions 1.1.5, 1.1.6 and 1.1.7 carrying wallet-drainer code. Ledger states the root cause was incomplete offboarding: the departed employee's access to an external tool had not been revoked. TechCrunch reported that the malicious code was live for about five hours, with the draining window under two hours, and that over $600,000 was stolen. Ledger reports a fix within 40 minutes of being alerted.

No affected protocol had a contract bug. Their front ends loaded a library from an upstream they did not control, and when that upstream changed, their users' approvals were redirected. The point for a protocol is not that Ledger failed; it is that every external script your interface loads is part of your attack surface, and most teams cannot list them.

What the assessment covers

Surface	What is checked	Output
Domains and DNS	Every hostname you own, stale records, registrar and DNS-provider account controls	Inventory plus exposure findings
Front end dependencies	Third-party scripts, packages and external origins loaded by the dApp; whether versions are pinned and content is integrity-checked	Dependency and origin list with risk ranking
Internet-facing hosts and APIs	Open ports, outdated software, known-vulnerable versions, misconfigurations, validated by hand	CVSS-rated findings, false positives removed
Keeper, relayer and indexer services	Exposed admin interfaces, default credentials, unpatched components	Findings tied to the service that holds operational keys
Cloud configuration	Public storage, over-permissioned roles, exposed consoles	Configuration findings
Publishing rights	Who can push to your package registry, CDN and deploy pipeline, and whether offboarding removes it	Access review notes

The last row is the Ledger lesson in practice. A scanner will not find a stale npm permission, so it is a manual review item, and it is the item Ledger's own report identifies as the root cause.

What an assessment will not do

It will not catch a five-hour dependency compromise. A recurring assessment measures state at a point in time. Catching a live swap needs monitoring, which is the Managed SOC for a DeFi protocol problem, and integrity controls on the front end.
It does not read contract logic. Contracts stay with the auditor.
It does not prove exploitability. A validated finding is a real exposure; whether it chains into a privileged transaction is a pentest question.
It stays inside authorization. Third-party infrastructure is out of scope unless its owner consents.

Deliverables

Under the Vulnerability Assessment service you receive a prioritized vulnerability list with CVSS and business-impact ratings, recommended remediation actions and an audit-ready findings summary, with a quarterly or monthly recurring option. For a protocol, ask that the dependency and external-origin list be delivered as its own table, so the next release can be diffed against it.

How to decide

If you have an audit but no answer to "which third-party scripts does our interface load, and who can change them?", start with an assessment. Move to a pentest once the exposed surface is clean enough that chaining findings is the remaining question. Send us your domains, front-end repository layout and infrastructure list and we will reply with a fixed quote and Rules of Engagement.

Sources and review

The Ledger Connect Kit facts are third-party reported, from Ledger's incident report and TechCrunch; the dollar figure is TechCrunch's, as Ledger disclosed none. Scope and deliverables follow AnySec's published Vulnerability Assessment service terms; no AnySec performance figure is cited. Author: AnySec Engineering. Published 2026-09-30; last reviewed 2026-09-30.