Supply Chain Framework: expand the framework

docs/pages/config/contributors.json

@@ -423,7 +423,7 @@
   },
   "scode2277": {
     "slug": "scode2277",
-    "name": "scode2277",
+    "name": "Sara Russo",
     "avatar": "https://avatars.githubusercontent.com/scode2277",
     "github": "https://github.com/scode2277",
     "twitter": "https://x.com/emit_sara",

docs/pages/supply-chain/incident-response-supply-chain.mdx

@@ -0,0 +1,163 @@
+---
+title: "Supply Chain Incident Response | SEAL"
+description: "Respond to supply chain compromises in Web3 projects. Detect compromised dependencies, assess blast radius, lock affected versions, and coordinate recovery across frontend and smart contracts."
+tags:
+  - Security Specialist
+  - SRE
+  - Engineer/Developer
+contributors:
+  - role: wrote
+    users: [scode2277]
+---
+
+import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components'
+
+<TagProvider>
+<TagFilter />
+
+# Supply Chain Incident Response
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+> 🔑 **Key Takeaway:** Supply chain incidents move faster than direct compromises. You do not control the affected
+> code, the fix depends on an external maintainer, and the same attack may be hitting hundreds of other projects
+> simultaneously. Speed and a practiced response plan are what determine your outcome.
+
+When a dependency is compromised, the clock starts before you are aware of it. The Ledger Connect Kit attack in
+2023 ran for several hours before widespread detection, long enough for significant user losses to occur. By the time
+most teams learned about it, the question was no longer whether they were affected but how many of their users had
+already interacted with the malicious version. Supply chain incidents have this character: they originate externally,
+propagate at ecosystem scale, and the window between compromise and discovery is often controlled by the attacker.
+
+For general incident response procedures, see the [Incident Management](/incident-management/overview) framework.
+This page focuses on the aspects unique to supply chain compromises.
+
+## How Supply Chain Incidents Differ
+
+| Aspect | Direct Compromise | Supply Chain Compromise |
+|--------|------------------|------------------------|
+| **Control** | You own the affected code | You depend on an external maintainer |
+| **Detection** | Internal monitoring catches it | Typically discovered externally: community, security researchers, registry alerts |
+| **Fix timeline** | You can patch immediately | You wait for the upstream fix or pin to a safe version |
+| **Blast radius** | Scoped to your systems | May affect every project in the ecosystem using that dependency |
+| **Attribution** | Attacker targeted you specifically | You are collateral in an ecosystem-wide attack |
+
+## Detection Signals
+
+Watch for these indicators that a supply chain compromise may have occurred:
+
+- **Community alerts.** Security advisories, posts from researchers, messages in developer Discord servers are often
+  the first signal.
+- **Unexpected dependency updates.** A package version appears in your lockfile that no one on the team updated.
+- **Behavioral anomalies.** Unexpected network requests from your application, unusual transaction prompts reported
+  by users, or build output that changes between runs without corresponding source changes.
+- **Integrity check failures.** SRI hash mismatches or checksum discrepancies between expected and actual artifacts.
+- **Registry advisories.** npm sends security advisories when a package is flagged, though this can lag behind public
+  disclosure.
+
+## Response Scenarios
+
+### Frontend Dependency Compromise
+
+This is the most common scenario: a compromised npm package serves malicious JavaScript to users through
+your frontend.
+
+- **Deploy a clean frontend immediately.** Revert to the last known good build or rebuild without the compromised
+  dependency.
+- **Invalidate CDN caches.** A cached compromised version will continue to reach users even after you redeploy from
+  clean source.
+- **Warn users.** Post on your official channels that users should not interact with the application until the clean version
+  is confirmed live.
+- **Check for wallet drainer activity.** If the compromise targeted wallet signing flows, check on-chain for
+  unauthorized transactions originating from your application's users during the exposure window.
+
+### Smart Contract Dependency Compromise
+
+If a Solidity library used in your contracts is found to be vulnerable or malicious:
+
+- **Determine if the affected code is deployed.** Check whether the compromised library version was included in any
+  deployed contracts. Library vulnerabilities that were not present in the version you used may not affect you.
+- **Consider pausing.** If your contracts have a pause mechanism and the vulnerability is actively exploitable, pause
+  them while you assess.
+- **Plan migration if needed.** Evaluate whether the vulnerability is actively exploitable
+  with your current configuration and plan a new deployment.
+
+### CI/CD Pipeline Compromise
+
+If the compromised dependency ran during your build process:
+
+- **Assume build secrets are compromised.** Rotate all secrets accessible to the CI environment (API keys, deployment
+  keys, npm tokens).
+- **Audit recent deployments.** Check if any build produced by the compromised CI was deployed to production.
+  Binaries or contracts produced during the compromise window should be considered untrusted.
+- **Review CI logs.** Look for unexpected network calls or file system access during the build.
+- **Rebuild with clean dependencies.** Use `--frozen-lockfile` with a verified lockfile.
+
+## Immediate Response Steps
+
+When a compromise is confirmed or credibly suspected:
+
+### Assess Exposure
+
+- **Check your lockfile.** Is the compromised version present in `pnpm-lock.yaml`, `yarn.lock`, or
+  `package-lock.json`?
+- **Check deployed artifacts.** Was the compromised version included in any build that reached production?
+- **Check CI history.** Did any CI run install the compromised version? If so, CI secrets may have been exposed.
+- **Identify the attack window.** When was the malicious version published, and when did you last install or build?
+
+### Contain the Damage
+
+- **Lock dependencies** to the last known good version. Delete `node_modules` and rebuild from a verified lockfile
+  using `--frozen-lockfile`.
+- **Do not deploy anything** built during the exposure window until the build is clean.
+- **Rotate exposed secrets.** If the compromised package ran during CI, assume that CI environment's secrets (API
+  keys, deployment keys, npm tokens) are exposed and rotate them immediately.
+- **Take down compromised deployments.** If a compromised frontend was served to users, take it offline or deploy a
+  clean version as fast as possible. A few minutes of unavailability is recoverable, continued exposure is not.
+
+### Communicate
+
+- **Notify your team.** Ensure everyone knows not to install or deploy until the situation is resolved.
+- **Notify affected users.** If wallet-interacting code was affected, warn users on your official channels promptly
+  and specifically: tell them what happened, what the risk is, and what action they should take.
+- **Coordinate with the maintainer.** Report the compromise to the package maintainer and to the registry (npm,
+  crates, PyPI).
+
+## Post-Incident Actions
+
+Once the immediate threat is contained:
+
+- **Document the timeline.** When the compromise occurred, when it was detected, how long it was in production, and
+  what the impact was. This serves the retrospective and any user communication that follows.
+- **Strengthen monitoring.** Add the detection signals you missed to your monitoring setup.
+- **Review dependency practices.** Were versions pinned? Were lockfiles committed and verified in
+  CI? Address any gaps the incident exposed.
+- **Update your response playbook.** Incorporate lessons learned so the next response is faster.
+
+## Quick-Reference Checklist
+
+When a supply chain compromise is reported:
+
+- [ ] Is the compromised version in your lockfile?
+- [ ] Was it included in any build that reached production?
+- [ ] Did it run during CI? If so, rotate all CI secrets.
+- [ ] Lock to the last known good version and rebuild from clean state.
+- [ ] Delete `node_modules` / build cache and use `--frozen-lockfile`.
+- [ ] If user-facing: deploy clean version, invalidate CDN caches, notify users.
+- [ ] If wallet-interacting: check for unauthorized on-chain activity during the exposure window.
+- [ ] Rotate any secrets the package could have accessed.
+- [ ] Report to the registry and coordinate with the package maintainer.
+- [ ] Document the incident timeline and run a retrospective.
+
+## Further Reading
+
+- [Incident Management](/incident-management/overview): General incident response procedures and team coordination
+- [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): Real-world incidents that illustrate the attack patterns described here
+- [Dependency Awareness](/supply-chain/dependency-awareness): Preventive practices like version pinning and lockfile integrity that reduce exposure
+- [DevSecOps](/devsecops/overview): Integrating dependency scanning and build security into CI/CD pipelines
+
+---
+
+</TagProvider>
+<ContributeFooter />

docs/pages/supply-chain/index.mdx

@@ -13,4 +13,7 @@ title: "Supply Chain"
 
 - [Supply Chain Security](/supply-chain/overview)
 - [Dependency Awareness](/supply-chain/dependency-awareness)
-- [Supply Chain Levels Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts)
+- [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats)
+- [Supply Chain Levels for Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts)
+- [Vendor Risk Management](/supply-chain/vendor-risk-management)
+- [Supply Chain Incident Response](/supply-chain/incident-response-supply-chain)

docs/pages/supply-chain/overview.mdx

@@ -1,10 +1,13 @@
 ---
 title: "Supply Chain Security | Security Alliance"
-description: "Supply Chain Security Framework: Secure all components, dependencies, and processes in software development and deployment. Protect web application stacks and smart contract external libraries."
+description: "Supply Chain Security Framework: Secure dependencies, frontend delivery, infrastructure providers, and build artifacts in Web3 projects. Prevent supply chain attacks before they reach users."
 tags:
   - Engineer/Developer
   - Security Specialist
   - Devops
+contributors:
+  - role: wrote
+    users: [scode2277]
 ---
 
 import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components'
@@ -17,9 +20,56 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-Supply chain security involves managing and securing all the components, dependencies, and processes involved in the
-development, deployment, and maintenance of software. In the context of blockchain and web3 projects, supply chain
-security could for example be parts of the web application stack, or external libraries used by the smart contract.
+> 🔑 **Key Takeaway:** Your software is only as secure as its weakest dependency. Supply chain security means knowing
+> what you depend on, verifying its integrity, and having a plan for when something in your chain is compromised.
+
+Supply chain security covers everything between your source code and your users. In traditional software, that mostly
+means npm packages and third-party libraries. In Web3, the chain is longer and the consequences are more severe:
+frontend code interacts directly with wallets, smart contracts hold real value, and infrastructure providers make
+decisions your contracts rely on. Attackers who understand this do not need to compromise your code directly. They
+target the libraries you import, the CDNs that serve your frontend, the RPC endpoints your app trusts, and the
+contractors your team onboards.
+
+These are not theoretical risks. Attacks targeting npm packages, wallet connector libraries, and compiler toolchains
+have resulted in hundreds of millions of dollars in losses across the Web3 ecosystem.
+
+## What Makes Up a Web3 Supply Chain?
+
+A Web3 project's supply chain includes every external component between your source code and your users:
+
+- **Code dependencies:** npm packages, Solidity libraries, Rust crates, and their transitive dependencies
+- **Frontend delivery:** CDNs, hosting providers, wallet connector libraries, and the scripts served to users' browsers
+- **Build tooling:** Compilers (solc), development frameworks (Hardhat, Foundry), CI/CD pipelines
+- **Infrastructure providers:** RPC nodes, indexers, oracle networks, bridge relayers
+- **Hardware:** Signing devices, hardware wallets, HSMs
+- **Human supply chain:** Contractors, freelancers, open-source contributors
+
+A compromise at any point in this chain can affect your users.
+
+## What This Framework Covers
+
+This framework provides practical guidance for securing each layer of your supply chain:
+
+1. [Dependency Awareness](/supply-chain/dependency-awareness): Manage external packages securely, including version pinning,
+   lockfile integrity, vulnerability scanning, and protection against typosquatting.
+2. [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): The specific threat vectors that affect Web3
+   projects, from frontend library hijacking to infrastructure compromise and hardware tampering.
+3. [Supply Chain Levels for Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts): Classify your
+   components by risk level and apply proportional controls.
+4. [Vendor Risk Management](/supply-chain/vendor-risk-management): Evaluate and monitor third-party providers including RPC
+   services, oracle networks, security auditors, and contractors.
+5. [Supply Chain Incident Response](/supply-chain/incident-response-supply-chain): What to do when a dependency or
+   provider is compromised, including Web3-specific response scenarios.
+
+## Related Frameworks
+
+Supply chain security intersects with several other areas covered in this project:
+
+- [DevSecOps](/devsecops/overview): Integrating dependency scanning and build security into CI/CD pipelines
+- [DPRK IT Workers](/dprk-it-workers/overview): Mitigating insider threats from the human supply chain
+- [Wallet Security](/wallet-security/overview): Hardware wallet supply chain integrity and key management
+- [External Security Reviews](/external-security-reviews/overview): Selecting and working with security auditors
+- [Incident Management](/incident-management/overview): General incident response procedures
 
 ---