Supply Chain Levels for Software Artifacts
🔑 Key Takeaway: Not every dependency carries the same risk. Apply your strictest controls to components that touch user funds or signing operations, and scale down from there. Applying the same scrutiny to everything means applying it effectively to nothing.
Applying uniform security controls across an entire dependency tree is not practical and does not reflect how risk actually distributes. A smart contract library that handles value transfers carries fundamentally different risk than a test framework or a documentation generator. Classification frameworks exist to make this explicit: identify which components carry the most risk, then concentrate your strongest controls there and apply proportionally lighter measures to lower-risk artifacts.
Risk Classification Framework
Level 1: Critical Artifacts
Components that directly handle value, signing operations, or core protocol logic. Smart contract libraries (OpenZeppelin Contracts), wallet interaction libraries (ethers.js, viem, web3.js), signing and cryptographic modules, and anything that constructs or validates transactions.
Compromise of these components can directly drain funds or allow unauthorized transactions. These warrant the highest scrutiny.
For specific practices, see Dependency Awareness, Security Testing Framework, and External Security Reviews Framework.
Level 2: High-Risk Artifacts
Components that are important to application function but do not directly handle funds. Authentication and authorization modules, API gateway and middleware components, database connectors, and oracle integration code fall in this category.
Their compromise could enable data exposure, service disruption, or indirect fund loss, but would typically require additional exploitation steps. These benefit from regular vulnerability scanning and automated security testing in CI.
For dependency management practices, see Dependency Awareness.
For CI/CD pipeline security, see DevSecOps.
Level 3: Moderate-Risk Artifacts
High-usage components with limited blast radius. UI frameworks (React, Vue), general utility libraries (lodash, date-fns), data processing modules, and analytics libraries sit in this tier.
User-facing frontend dependencies that influence wallet connection, transaction construction, signing flows, or security-critical UI should be treated as high-risk or critical, even if they are "just frontend libraries".
Compromise could cause service degradation or facilitate phishing, but not direct fund loss. Standard update practices and periodic vulnerability scanning are sufficient.
Level 4: Low-Risk Artifacts
Components that do not run in production or have no access to sensitive data. Test frameworks (Jest, Mocha), linting and formatting tools, documentation generators, and local development utilities belong here.
Basic security hygiene (trusted sources, occasional updates) is sufficient here.
Further Reading
- Dependency Awareness: Practical guidance on managing dependencies
- Web3 Supply Chain Threats: Real-world attacks across the supply chain