Software Supply Chain Security for Crypto and Digital Assets: 90 Days

A crypto exchange or custodian secures its software supply chain by knowing every package, library and vendor that can touch a signing path, cutting off publish rights and access the moment people leave, and holding wallet, custody and support vendors to written security duties. The incidents of the last three years show why: attackers did not break the cryptography. They published a poisoned version of a library that wallets load, phished a developer at a wallet software vendor, or reused a token nobody had revoked. In New York, the Department of Financial Services turns much of this into law through its cybersecurity regulation, 23 NYCRR Part 500, which applies to BitLicense holders and chartered trust companies alike.

This guide is for the CISO, wallet and custody engineering, AppSec, compliance, vendor risk and platform teams. The first two thirds work with the tools you already have. This is not legal advice; read the rules with your counsel.

Key takeaways

• NYDFS Part 500 is the main US rule for most crypto firms licensed in New York. It applies to anyone operating under a license or charter under the Banking Law, Insurance Law or Financial Services Law, which covers BitLicense holders and limited purpose trust companies. The last phase of the 2023 amendment, a complete asset inventory under 500.13(a) and multi-factor authentication for all users under 500.12, took effect on 1 November 2025.
• Part 500 already covers the software you build and buy. Section 500.8 covers secure development and testing of bought applications, 500.11 requires a written third-party service provider policy, and 500.17 requires notice to DFS within 72 hours, including for incidents at a provider.
• The recent incidents were supply chain incidents. A former employee's package registry account (Ledger Connect Kit, December 2023), a wallet software vendor's employee (the DMM Bitcoin theft, May 2024), and a hijacked publish account on a widely used JavaScript library (@solana/web3.js, December 2024) each led to theft without any break in the underlying cryptography.
• Offboarding is a supply chain control. Since 1 May 2025 Part 500.7 requires prompt termination of access after departures. Registry tokens and CI secrets belong on that list.
• EU rules matter only if you serve the EU. MiCA's crypto-asset service provider rules applied from 30 December 2024, and DORA applies to authorised providers from 17 January 2025.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM, CSAF and VEX upload, the compliance and GRC suite, Trust Center, the CLI and local runner, and on-prem, air-gapped and Zero AI deployment.

The situation

The trigger here is rarely a calendar date. It is a 2 a.m. message saying a library your web wallet loads has published a version its maintainers do not recognise. Or a regulator's examination letter asking for your asset inventory and third-party policy. Or the 15 April certification under Part 500, which the highest-ranking executive and the CISO must both sign.

What makes crypto different from other financial services is how short the path is from a software compromise to an irreversible loss. A bank can often reverse a fraudulent wire. A signed blockchain transaction usually cannot be reversed. If a compromised dependency changes the address a user sees, or the transaction a signer approves, the money is gone in minutes. In the Ledger case, users signed draining transactions during a window of about five hours.

A bad week: on Monday a JavaScript package your front end uses is reported compromised. By Tuesday nobody can say which builds pulled the bad version. On Wednesday compliance asks whether the 72-hour clock has started, and engineering cannot say whether any customer signed a tampered transaction. Every one of those problems is cheaper to solve before the incident.

What software crypto and digital asset firms run

The attack surface is wider than the matching engine. A typical exchange or custodian runs most of the following, and each item has its own supply chain.

Two points matter most: much of the code that decides what a user signs is browser JavaScript, and the signing path crosses several vendors, any one of which an attacker can target.

The regulations and frameworks that apply

US rules lead here, because most of the readers this post is written for are licensed or registered in the US. Check the current text before relying on any date, and ask counsel which rules apply to your entity.

NYDFS 23 NYCRR Part 200, the BitLicense

New York issued its virtual currency regulation, 23 NYCRR Part 200, in June 2015 under the Financial Services Law. To conduct virtual currency business activity in the state, a firm either holds a BitLicense or a charter under the Banking Law, such as a limited purpose trust company, with approval for virtual currency business. DFS publishes licensee guidance on its virtual currency page, but the detailed, recently amended cybersecurity requirements sit in Part 500.

NYDFS 23 NYCRR Part 500, as amended in November 2023

Part 500 defines a covered entity as any person operating under, or required to operate under, a license, registration, charter or similar authorisation under the Banking Law, the Insurance Law or the Financial Services Law. For a BitLicense holder or a New York trust company, that means Part 500 applies in full unless an exemption fits. The second amendment took effect on 1 November 2023 and phased in over two years. The sections that touch the software supply chain:

• 500.8 Application security. The cybersecurity program must include written procedures, guidelines and standards for secure development practices for in-house developed applications, and procedures for evaluating, assessing or testing the security of externally developed applications used by the firm. The CISO or a qualified designee must review them at least annually.
• 500.11 Third-party service provider security policy. Written policies must address identifying and assessing providers, minimum cybersecurity practices they must meet, due diligence, and periodic assessment. Guidelines must cover, where applicable, the provider's access controls and multi-factor authentication, its encryption, notice to the firm of a cybersecurity event that directly affects the firm's systems or nonpublic information, and representations and warranties about the provider's security.
• 500.5 Vulnerability management. Since 29 April 2024, at least annual penetration testing and a monitoring process to learn promptly of new vulnerabilities, remediated by risk. Since 1 May 2025, automated scans of information systems, plus manual review of systems scans do not cover, at a frequency set by the risk assessment and promptly after any material system change.
• 500.7 Access privileges. Since 1 May 2025, enhanced limits on privileged access, review of access privileges, and prompt termination of access following personnel departures.
• 500.14(a)(2). Since 1 May 2025, controls to protect against malicious code.
• 500.12 and 500.13(a). Since 1 November 2025, multi-factor authentication for any individual accessing any information system (with CISO-approved compensating controls allowed in writing), and written policies and procedures to produce and maintain a complete, accurate and documented asset inventory, tracking key information such as owner and location.
• 500.17 Notices. Notice to the superintendent as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the firm, its affiliates or a third-party service provider. An extortion payment must be reported within 24 hours of the payment. By 15 April each year the firm submits either a certification of material compliance or an acknowledgment of noncompliance for the prior calendar year, signed by the highest-ranking executive and the CISO.

The FTC Safeguards Rule

The FTC's Standards for Safeguarding Customer Information, 16 CFR Part 314, apply to non-bank financial institutions under the FTC's jurisdiction. In its press release of 27 October 2023, the FTC announced an amendment requiring covered institutions to notify the agency as soon as possible, and no later than 30 days after discovery, of a breach involving unencrypted information of at least 500 consumers. The amendment took effect 180 days after publication in the Federal Register. Whether a given crypto business is a "financial institution" under this rule is a question for counsel.

Federal requests during an active theft

The FBI's announcement on the Bybit theft published attacker-controlled Ethereum addresses and asked node operators, exchanges, bridges, analytics firms and DeFi services to block transactions with them. That is a request, not a regulation, but your runbook needs a way to act on such a list quickly.

Frameworks that shape good practice

• NIST SP 800-218, the Secure Software Development Framework (February 2022). The common vocabulary for secure development practices. Mapping your 500.8 procedures to it gives auditors something familiar to test against.
• CISA's 2026 Minimum Elements for a Software Bill of Materials. Released on 29 July 2026 with NSA, FBI and international partners, it builds on the 2021 NTIA minimum elements and adds requirements for component hash, license, SBOM tool name and SBOM generation context. Use it as the bar for SBOMs you ask vendors for.
• The CryptoCurrency Security Standard (CCSS). An industry standard for information systems that store, manage or interact with cryptocurrencies, including exchanges, custodians and wallet providers. Its publisher describes it as a complement to standards such as ISO/IEC 27001 rather than a replacement, and it certifies systems, not entities, at Levels 1 to 3.

EU context: MiCA and DORA

For firms serving EU customers: the European Commission confirmed that MiCA applies fully from 30 December 2024 and DORA from 17 January 2025. Under MiCA Article 143(3), providers already operating under national law could continue until 1 July 2026 at the latest, or until granted or refused authorisation, and member states could shorten that window. ESMA's Q&A 2364 explains that DORA applies to crypto-asset service providers "as authorised under" MiCA, per DORA Article 2(1)(f), so a provider still in the transitional period was outside DORA until authorised. Once authorised, DORA's ICT third-party risk rules apply to your wallet, custody and cloud vendors.

How the rules fit together

Real public incidents from the last three years

The summaries below stick to what the named organisations and authorities published. They draw no conclusions about what any victim should have done.

Ledger Connect Kit, 14 December 2023

Ledger's own incident report says a former employee fell victim to a phishing attack that gave the attacker access to their npm account by using a session token, bypassing two-factor authentication. The attacker published malicious versions of the Ledger Connect Kit (1.1.5, 1.1.6 and 1.1.7) to npm. Many decentralised applications loaded the kit at runtime from a CDN through a loader component, so the malicious code reached them without the apps rebuilding. The code used a rogue WalletConnect project to redirect assets and tricked users into signing draining transactions. Ledger says it deployed a genuine fix within 40 minutes of becoming aware, and that about five hours passed from the npm compromise to complete resolution because of CDN caching. Ledger states that the former employee's access to its internal systems had been revoked but the npm access had not, and that npm did not then allow multi-party authorisation for automatic publishing.

DMM Bitcoin and a wallet software vendor, May 2024

In December 2024 the FBI, the Department of Defense Cyber Crime Center and Japan's National Police Agency attributed the theft of about 308 million US dollars (4,502.9 BTC) from DMM Bitcoin to North Korean actors tracked as TraderTraitor. According to the joint statement, in late March 2024 an actor posing as a recruiter contacted an employee of Ginco, a Japanese wallet software company, and sent a link to a malicious Python script on GitHub disguised as a pre-employment test. The employee had access to Ginco's wallet management system. After mid-May 2024 the actors used session cookie information to impersonate the employee, and in late May they likely manipulated a legitimate transaction request by a DMM employee.

@solana/web3.js publish account compromise, 3 December 2024

The advisory for CVE-2024-54134, published in the NVD on 4 December 2024, says a publish-access account for @solana/web3.js, a JavaScript library commonly used by Solana applications, was compromised. The attacker published two unauthorised versions, 1.95.6 and 1.95.7, modified to steal private key material and drain funds from applications that handle private keys directly, such as bots. The advisory limits impact to projects that updated between 3:20 p.m. and 8:25 p.m. UTC that day, says non-custodial wallets should generally not be affected, and tells developers to upgrade to 1.95.8 and rotate any suspect authority keys, including multisigs, program authorities and server keypairs. We covered it in detail in the Solana web3.js backdoor post.

Bybit, 21 February 2025

The FBI's public service announcement of 26 February 2025 (I-022625-PSA) states that North Korea was responsible for the theft of about 1.5 billion US dollars in virtual assets from the exchange Bybit on or about 21 February 2025, and attributes it to TraderTraitor. The FBI said the actors were converting some of the stolen assets and dispersing them across thousands of addresses on multiple chains, and asked the industry to block transactions with the listed addresses. The PSA does not describe the intrusion path. Later statements by investigators and the multisig wallet provider are summarised in our post on what the FBI and investigators said.

The Shai-Hulud worm in npm, September 2025

CISA's alert of 23 September 2025 describes a self-replicating worm that compromised more than 500 npm packages. After initial access it scanned for credentials, targeted GitHub personal access tokens and cloud API keys, exfiltrated them, and used the compromised developer's npm access to inject code into other packages and publish them. CISA recommended a dependency review of all npm-based software, checking lockfiles for affected packages, pinning to releases from before 16 September 2025, rotating all developer credentials, and phishing-resistant MFA on developer accounts.

In each case the primary sources describe an account or credential, belonging to a developer, a former employee or a vendor's employee, used to change code or transactions that a trusted system then ran.

The personas who own the problem

CISO

Needs: a defensible answer to "could this happen to us, and how fast would we know?" and evidence for the 15 April certification. When: after any industry incident, before the annual certification, and when an examiner asks for the asset inventory or third-party policy.

Head of wallet and custody engineering

Needs: a short, enforced list of what is allowed into the signing path, reproducible builds of signing services, and a way to ship a dependency fix without breaking a quorum ceremony. When: every release of the wallet or signing service, every vendor SDK upgrade, and the hour an advisory names a library they use.

Head of AppSec or product security

Needs: one inventory across web, mobile, node and contract code; findings ranked by real exposure; and a backlog that shrinks. When: continuously, plus during examination preparation.

Chief compliance officer and GRC

Needs: evidence by section: the 500.13 inventory, the 500.11 policy and vendor assessments, scan records under 500.5, and the incident log under 500.17. When: the annual certification, examinations, and any time a vendor reports an event.

Vendor risk and procurement

Needs: a tiered list of wallet, custody, KYC, analytics, cloud and support vendors; contract language for notice, MFA and encryption; and SBOMs and advisories from the vendors whose code runs in your environment. When: onboarding, renewal, and the day a vendor discloses an incident.

Platform, SRE and DevOps

Needs: CI that pins dependencies and fails builds on known-bad versions, short-lived credentials, and signing hosts that do not pull from the public internet. When: every pipeline change, every on-call page about a dependency, and every offboarding.

Startup CTO who also owns compliance

Needs: what is enough for the stage the firm is at, kept in one place. When: before a license application, a bank partnership or a first institutional client's security review. For a small team, the 30-day plan below is the floor.

Step by step: a 30/60/90-day plan that works with or without Safeguard

The plan assumes you already have source control, CI and a ticketing system. Each step names an owner.

Days 1 to 30: map the signing path and close the obvious doors

1. Draw the signing path (wallet engineering, CISO). For each chain you support, list every component between "user or operator requests a withdrawal" and "signed transaction broadcast": UI code, API services, policy engine, MPC or HSM SDK, signer firmware, node client. Mark which are open source, which are vendor code, and which load code at runtime from a CDN.
2. Generate SBOMs for everything you build (AppSec, platform). Start with the wallet front ends, signing services and node images. Use CycloneDX or SPDX and keep them per release, not just per repository.
3. Pin and lock (platform). Commit lockfiles, stop installing floating versions in CI, and remove runtime loading of third-party scripts from wallet pages where you can. Where you cannot, pin by version and integrity hash.
4. Audit publish and deploy rights (platform, HR). List everyone who can publish to your package registry scopes, push container images, change CI secrets, or approve signing policy changes. Remove anyone who has left. The Ledger report is the example to show leadership.
5. Enforce phishing-resistant MFA on developer accounts (CISO). Registry, source control and cloud consoles first. Part 500.12 already requires MFA for all users since 1 November 2025.
6. Write the first-hour runbook for a compromised dependency (CISO, AppSec). See the checklist below.

Days 31 to 60: vendors, gates and the incident drill

1. Tier vendors (vendor risk). Tier 1 is anything that can touch keys, signing, customer funds or identity data: custody and MPC vendors, wallet SDKs, HSM suppliers, KYC providers, outsourced support with account access.
2. Send the 500.11 addendum to Tier 1 (vendor risk, counsel). Use the template below. Ask for SBOMs and for advisories in CSAF or VEX form for the software they ship to you.
3. Add a CI gate (platform, AppSec). Fail builds on known critical vulnerabilities and on specific package versions named in an advisory, with a documented exception process that has an owner and an expiry date.
4. Separate build and signing environments (wallet engineering). Signing services should build from a mirrored, pinned set of dependencies and should not reach the public registry at build time.
5. Run a tabletop (CISO, compliance, engineering). Scenario: a popular wallet connector library publishes a malicious version at 3 p.m. on a Friday. Time how long it takes to answer "which of our builds include it, and did any customer sign through it?" Record whether the 72-hour clock would start, and who decides.

Days 61 to 90: evidence, monitoring and the certification pack

1. Map evidence to sections (GRC). One folder per Part 500 section: inventory exports for 500.13, procedures for 500.8, scan records for 500.5, access reviews for 500.7, vendor files for 500.11, the incident log for 500.17.
2. Monitor continuously (AppSec). Rescan SBOMs when new advisories land, not only when code changes. A dependency that was clean at release can become vulnerable without a single commit.
3. Fix with pull requests, inside change control (engineering). Move vulnerable dependencies to fixed versions through normal review, with signing service changes going through the same ceremony as any other release.
4. Close the offboarding gap (HR, platform). Add registry tokens, CI secrets, signing quorum membership and vendor portal accounts to the leaver checklist, with a named owner for each.
5. Prepare the certification pack (CISO, compliance). A short memo per section with the evidence, known gaps and remediation dates. Gaps go into an acknowledgment of noncompliance if they are material; that decision belongs to the firm and counsel.

Template: Part 500.11 addendum for Tier 1 technology vendors

Adapt with counsel. Each line maps to a 500.11 element.

Checklist: the first hour after a compromised package report

1. Record the package, bad versions and time window from the advisory.
2. Search lockfiles and SBOMs for those versions across all repositories and images, including transitive dependencies.
3. Check CDN-loaded scripts and runtime loaders separately; lockfiles will not show them.
4. If a signing path is affected, pause automated withdrawals for the affected chain and escalate to the CISO.
5. Block the bad versions in CI and in any internal registry mirror.
6. Rotate credentials the package could have reached, following the advisory (the Solana advisory listed authority keys, multisigs and server keypairs).
7. Start the incident log with timestamps; compliance decides whether the 72-hour notice applies.
8. Tell customer support what to say, and what not to say yet.

Decision table: when a vendor will not provide an SBOM

Is an open source maintainer a third-party service provider under Part 500?

Generally not in the contractual sense: a maintainer has no agreement with you and no access to your systems. That does not take open source out of scope. You chose to run the code, so it belongs in your 500.13 inventory, your 500.8 procedures and your 500.5 scanning. The practical answer is to treat open source as part of your own software, and to treat the registries and CDNs you pull it from as infrastructure you depend on.

What changes for a self-custody wallet maker versus a custodian?

A custodian's main risk is a compromised component on its own signing path. A wallet maker's main risk is a compromised release reaching users, as in the Ledger and Solana cases, because it is the supplier in someone else's supply chain. Both need inventory and gates; the wallet maker should weigh release integrity and publish-account hygiene more heavily.

How Safeguard does this

The plan above works without any product. Safeguard puts the inventory, vendor requests, gates, fixes and evidence in one place. Commands and YAML below are copied from docs.safeguard.sh as of 25 October 2026 and were not run for this post.

1. Inventory the code you build. SBOM generation and analysis (GA) and software composition analysis (GA) produce an SBOM per project across the full transitive dependency tree, in CycloneDX or SPDX. Connect repositories, container registries or a manifest from Integrations in the web app.

2. Scan signing code on your own machines. Wallet and signing repositories are often not allowed to connect to a cloud service. The Safeguard CLI (GA) includes a local runner (GA). The docs say the runner polls the platform over outbound HTTPS, nothing connects to it, it runs each scan job locally, and it uploads only the resulting SBOM and findings, never source code. Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login and approve the session in your browser. The docs note that the installer verifies the download against published checksums and fails closed on macOS and Linux if the checksums file is missing. To run the runner without the terminal UI:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

3. Gate what reaches the signing path. With policies and gates (GA), create a policy under Settings, Policies with conditions such as vulnerability severity, CVSS, EPSS, license, component age or abandoned packages. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). A legitimate exception goes through the exception workflow with a business justification and an expiration date, approvers are notified, and an audit trail is recorded. In GitHub Actions the docs show:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add --fail-on-gate all to fail on a policy gate instead of a severity threshold, and SAFEGUARD_VERSION in env to pin the CLI version, which suits a signing-service pipeline that should not change underneath you.

4. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV. Reachability analysis (GA) labels each finding reachable, conditionally reachable, unreachable or unknown, and treats unknown as potentially reachable.

5. Fix with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on. For a signing service, keep it that way and let the pull request enter your normal release ceremony.

6. Run vendor intake in TPRM. In TPRM (GA), choose a vendor, then Request SBOM, select products and a template, set a deadline and send. The docs describe status tracking from Sent through Viewed, In Progress and Submitted to Validated or Rejected, reminders seven days before the deadline, at the deadline and an escalation seven days after, and validation on receipt with an automatic vulnerability scan. If a submission falls short, Request Revision sends the vendor the corrections needed.

7. Load vendor advisories. With CSAF and VEX upload (GA), go to Integrations, filter by Upload and choose Upload CSAF/VEX. The docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. A custody vendor's "not affected" statement then sits next to the findings for that product version.

8. Map evidence to Part 500. The compliance and GRC suite (GA) includes an NY DFS 23 NYCRR 500 framework. Its docs page lists seven scan requirements decided against each product's SBOM, covering asset inventory and tracking detail (500.13), risk assessment (500.9), the third-party policy (500.11), encryption and integrity (500.15), incident response readiness (500.16) and documented policies (500.03), plus catalog controls including 500.08 application security and 500.17 notice to the superintendent, and policy templates such as a third-party service provider security policy. An internal Crypto Algorithm Audit framework checks for weak algorithms such as MD5 and SHA-1 in component hashes and identifies cryptographic libraries in the supply chain. These map scan results to controls; the certification judgement stays with you.

9. Answer institutional clients' security reviews. Trust Center (GA) gives you a public page under Compliance, Trust Center showing frameworks, live control status, policies and sub-processors, and documents you share. Publishing is an explicit action, and a framework that needs an independent auditor cannot be shown as compliant on a self-assessment.

10. Choose where it runs. On-prem and air-gapped deployment (GA) run the platform inside your perimeter; the docs describe signed snapshot bundles delivered by one-way diode, removable media or a scheduled DMZ sync, with no component inside the perimeter calling outbound. Zero AI mode (GA) runs with no LLM in the loop, for firms whose policy forbids sending code to AI services.

Safeguard becomes one of your vendors once you adopt it, so assess it under your own 500.11 policy. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not make you compliant with Part 500, the BitLicense or the FTC rule. It produces inventories, findings, gates and mapped evidence. DFS examiners and your own signatories judge compliance.
• It does not protect keys or sign transactions. HSMs, MPC, quorum policy and the review of what a signer approves stay with your custody stack and your people.
• It does not monitor the blockchain or block addresses. Acting on an FBI address list, screening transactions and tracing funds belong to your analytics and AML tooling.
• It does not decide whether an event is a reportable incident. The 72-hour and 24-hour notices under 500.17 are the firm's decision with counsel.
• It does not fix vendor or hosted code. Autonomous remediation opens pull requests in repositories you own. A flaw in a custody vendor's platform needs that vendor's fix.
• It does not manage your people's accounts. Offboarding registry tokens, CI secrets and signing quorum membership is an identity and HR process.
• It does not audit smart contract logic. Business logic flaws in on-chain code need specialised review; supply chain tooling covers the packages and toolchains around it.

Common mistakes

• Treating the signing service as the only crown jewel. In the Ledger and Solana cases the compromised code ran in front ends and client libraries, upstream of any HSM.
• Offboarding only the systems behind SSO. Ledger's report says its internal access was revoked but the registry access was not.
• Loading wallet libraries at runtime from a CDN without pinning. It removes the build step where a gate could have stopped a bad version.
• Vendor tiers based on spend, not access. A small wallet software vendor can sit closer to your keys than your largest cloud contract.
• Waiting for a CVE. Compromised releases may first surface in vendor posts and advisories. Start your runbook from a package name and a version window.
• Collecting SBOMs and never reading them. An SBOM that is not rescanned when a new advisory lands is a document, not a control.
• Letting exceptions live forever. Every exception on the signing path needs an owner and an expiry date.

FAQ

Does NYDFS Part 500 apply to BitLicense holders?

Part 500 applies to any person operating under, or required to operate under, a license, registration, charter or similar authorisation under the Banking Law, the Insurance Law or the Financial Services Law. The BitLicense is issued under the Financial Services Law, so licensees are covered entities unless an exemption applies. Confirm your status with counsel.

What did the 1 November 2025 Part 500 deadline add?

Multi-factor authentication for any individual accessing any of the firm's information systems under 500.12, with written CISO approval for equivalent compensating controls, and written policies and procedures for a complete, accurate and documented asset inventory under 500.13(a).

How fast must a crypto firm in New York report a cyber incident?

As promptly as possible and no later than 72 hours after determining that a cybersecurity incident occurred at the firm, an affiliate or a third-party service provider, under 500.17(a). An extortion payment must be reported within 24 hours of payment.

Does Part 500 require an SBOM?

The text does not use the term. It requires an asset inventory, secure development procedures and procedures to test externally developed applications. An SBOM is a practical way to show what software components each system contains, and CISA's 2026 minimum elements give a current bar for what one should hold.

How did attackers get into the Ledger Connect Kit?

According to Ledger, by phishing a former employee whose npm access had not been revoked, using a session token to bypass two-factor authentication, then publishing malicious versions 1.1.5 to 1.1.7 that applications loaded at runtime from a CDN.

Which versions of @solana/web3.js were malicious?

Versions 1.95.6 and 1.95.7, published on 3 December 2024 between 3:20 p.m. and 8:25 p.m. UTC according to the CVE-2024-54134 advisory. The fix is 1.95.8, and the advisory says to rotate any suspect authority keys.

Do MiCA and DORA apply to US crypto firms?

Only where a firm provides crypto-asset services in the EU. DORA applies to providers authorised under MiCA from 17 January 2025; ESMA says transitional providers were outside DORA until authorised.

Can supply chain scanning run without sending wallet code to the cloud?

Yes, if the tool supports local execution. Safeguard's local runner scans on your machine and uploads only the SBOM and findings, and on-prem and air-gapped deployment keep the whole platform inside your perimeter.

When a wallet or signing dependency turns out to be vulnerable, the slowest part of the response is usually the wait for a fixed release and then the wait for that release to reach every build. The section below covers how Safeguard shortens both waits for the open source you build and ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a custodian, this is the route for wallet and signing repositories that cannot be connected to a cloud service, because only the SBOM and findings leave the machine.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies when a wallet front end needs a dependency moved to a fixed version inside a release window.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Crypto exchange supply chain defence in 2026
• Crypto exchange supply chain hardening
• Software supply chain risk in cryptocurrency exchange and DeFi platforms
• Web3 smart contract supply chain security
• Token approvals and wallet hygiene for crypto teams

Sources

• NYDFS, 23 NYCRR Part 500 as amended
• NYDFS, implementation timeline for covered entities
• NYDFS, cybersecurity resource center
• NYDFS, virtual currency businesses
• FTC press release, Safeguards Rule breach notification amendment, 27 October 2023
• FBI PSA I-022625-PSA, Bybit theft
• FBI, DC3 and NPA statement on the DMM Bitcoin theft
• Ledger, security incident report on Connect Kit
• NVD, CVE-2024-54134
• CISA alert on the npm ecosystem compromise, 23 September 2025
• NIST SP 800-218, Secure Software Development Framework
• CISA bulletin, 2026 Minimum Elements for an SBOM
• CryptoCurrency Security Standard
• European Commission, MiCA and DORA implementation, 19 December 2024
• ESMA, Markets in Crypto-Assets Regulation
• ESMA Q&A 2364, DORA and VASPs in the MiCA transitional period
• Safeguard docs, NY DFS 23 NYCRR 500 framework
• Safeguard docs, Crypto Algorithm Audit framework
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, Local Runner
• Safeguard docs, CLI installation
• Safeguard docs, GitHub Actions
• Safeguard docs, CSAF/VEX upload
• Safeguard docs, Reachability analysis
• Safeguard docs, Trust Center setup
• Safeguard docs, Air-gapped deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.