Skip to content

OWASP SCS SDK Security Testing Handbook

Cover of SDK Security Testing
← All handbooks

Handbook 08 · 72 PDF pages

Evaluate SDK threat models, secure defaults, cryptography, transaction handling, dependencies, and release integrity.

Open PDF Download PDF

OWASP Smart Contract Security Project

Part of the OWASP SCS Handbook Series. Built to the series conventions.

Purpose and Scope

This handbook covers testing and security assessment methodology for software development kits (SDKs) used across Web3 and smart contract ecosystems: wallet SDKs, contract-interaction SDKs, front-end SDKs, and mobile SDKs. It aligns with the software supply chain standards that govern how these components are built, packaged, and distributed: Supply-chain Levels for Software Artifacts (SLSA) v1.2 Build and Source tracks, Software Bill of Materials (SBOM) formats CycloneDX and SPDX, and Sigstore for signed provenance. It draws on OWASP's own supply chain guidance, including Top 10 category A03 Software Supply Chain Failures, and on the dependency-tampering patterns documented across the wider OWASP ecosystem. Threat modeling, test design, and verification steps are aligned with the Smart Contract Security Verification Standard (SCSVS) and the Smart Contract Security Testing Guide (SCSTG).

An SDK sits directly between a developer's application code and the wallet, contract, or network it talks to, so a single compromised release can silently redirect signing requests or exfiltrate keys across every downstream application that imports it. The Ledger Connect Kit compromise of December 2023 made this concrete: a phishing attack against a former employee let attackers push a malicious update through the SDK's own CDN-hosted bundle, and dozens of dApps that trusted the package without pinning or verifying it served the malicious code to their users. This handbook treats SDK selection, testing, and ongoing monitoring as a discipline distinct from application-level contract auditing, because the vulnerability class runs someone else's code, built by someone else's pipeline, inside your application's trust boundary.

Target Audience

Developers, security engineers, and QA practitioners responsible for selecting, integrating, or building SDKs used in dApps and smart contract tooling.

How to Use This Handbook

Read Part I first to establish the threat model: the trust boundaries an SDK crosses, the actors who can compromise it, and how SLSA frames supply chain risk. Part II is the testing reference, organized by concern (supply chain and dependency testing, API and interface security) and then by SDK type (wallet, contract-interaction, front-end and mobile), each closing with a test-case checklist you can run directly against a candidate SDK. Part III moves from testing to process: wiring these checks into CI/CD, evaluating a third-party SDK before adoption, preparing an SDK for external review, and handling a disclosed vulnerability responsibly. The appendices hold a glossary, a consolidated SDK security testing checklist, and the full bibliography. A team vetting a new wallet SDK before integration can go straight to Chapter 6 and Appendix B.

Relationship to SCSVS, SCSTG, and SCWE

This handbook applies the SCS standards to a component the standards themselves treat as a black box: code your team did not write but ships inside a trust boundary your team owns. SCSVS defines the verification requirements an application must satisfy; the SDK test cases and checklists here are how you confirm a third-party dependency does not undermine those requirements before you ship it. SCSTG describes testing methodology for smart contract systems generally; Part II extends that methodology outward to the SDK layer, covering static and dynamic analysis, composition and dependency analysis, and behavioral testing of code outside the audited contract surface. The Smart Contract Weakness Enumeration (SCWE) catalogs weaknesses in contract code; this handbook fills the adjacent gap at the SDK and dependency boundary, where the weakness lives in a package.json entry rather than a Solidity file. The CDN and Front-End Supply Chain Security Handbook (01) shares this handbook's SLSA, SBOM, and Sigstore foundations from the delivery-infrastructure side, and the Incident Response Handbook (06) owns the response process that Chapter 12's responsible disclosure guidance feeds into.

Contents

Part I: Foundations

Part II: Testing Methodology

Part III: Implementation and Operations

Part IV: Appendices