From 047a75035082e295f5433812621e3442696aa6af Mon Sep 17 00:00:00 2001 From: Sara Russo Date: Mon, 18 May 2026 15:41:24 +0200 Subject: [PATCH 1/3] Add Checklist component to make our checklists clickable --- components/checklist/Checklist.css | 68 +++++++++ components/checklist/Checklist.tsx | 84 +++++++++++ ...stItem.css => GovernanceChecklistItem.css} | 0 ...stItem.tsx => GovernanceChecklistItem.tsx} | 17 +-- components/index.ts | 3 +- .../data-security-upgrade-checklist.mdx | 8 +- .../governance-proposal-security.mdx | 130 +++++++++--------- .../execution-sandboxing-practical-guide.mdx | 4 +- .../network-and-resource-isolation.mdx | 4 +- .../guides/account-management/discord.mdx | 40 +++++- .../guides/account-management/github.mdx | 30 +++- .../guides/account-management/godaddy.mdx | 6 +- .../guides/account-management/linear.mdx | 8 +- .../guides/account-management/mercury.mdx | 6 +- .../guides/account-management/notion.mdx | 10 +- .../guides/account-management/render.mdx | 6 +- .../guides/account-management/sentry.mdx | 14 +- .../guides/account-management/signal.mdx | 6 +- .../pages/guides/account-management/slack.mdx | 8 +- .../guides/account-management/telegram.mdx | 41 +++--- .../guides/account-management/trello.mdx | 6 +- .../guides/account-management/twitter.mdx | 8 +- .../guides/account-management/vercel.mdx | 8 +- .../hardware-security-keys.mdx | 4 +- .../password-manager-endpoint-hardening.mdx | 10 +- ...sh-client-and-key-management-hardening.mdx | 6 +- .../endpoint-security/zoom-hardening.mdx | 6 +- .../forensic-readiness.mdx | 4 +- .../communications.mdx | 4 +- .../incident-response-template/contacts.mdx | 6 +- .../incident-response-policy.mdx | 4 +- .../incident-response-template/overview.mdx | 4 +- .../roles-and-staffing.mdx | 6 +- .../runbooks/build-pipeline-compromise.mdx | 26 ++-- .../runbooks/cdn-hosting-compromise.mdx | 26 ++-- .../runbooks/ddos-attack.mdx | 16 ++- .../runbooks/dependency-attack.mdx | 10 +- .../runbooks/dns-hijack.mdx | 8 +- .../runbooks/frontend-compromise.mdx | 22 ++- .../runbooks/key-compromise.mdx | 22 ++- .../runbooks/overview.mdx | 4 +- .../runbooks/smart-contract-exploit.mdx | 14 +- .../runbooks/third-party-outage.mdx | 18 ++- .../templates/incident-log-template.mdx | 10 +- .../templates/post-mortem-template.mdx | 4 +- .../templates/runbook-template.mdx | 10 +- .../seal-911-war-room-guidelines.mdx | 16 ++- .../implementation-checklist.mdx | 46 ++++++- .../runbooks/emergency-pause.mdx | 16 ++- .../runbooks/signer-rotation.mdx | 8 +- .../runbooks/threshold-change.mdx | 14 +- .../runbooks/token-transfer.mdx | 12 +- .../setup-and-configuration.mdx | 4 +- docs/pages/opsec/google/overview.mdx | 18 ++- docs/pages/opsec/secure-operating-systems.mdx | 10 +- docs/pages/safe-harbor/self-checklist.mdx | 4 +- .../incident-response-supply-chain.mdx | 4 +- .../smart-contract-interaction-security.mdx | 4 +- 58 files changed, 740 insertions(+), 175 deletions(-) create mode 100644 components/checklist/Checklist.css create mode 100644 components/checklist/Checklist.tsx rename components/governance-sdlc/{ChecklistItem.css => GovernanceChecklistItem.css} (100%) rename components/governance-sdlc/{ChecklistItem.tsx => GovernanceChecklistItem.tsx} (75%) diff --git a/components/checklist/Checklist.css b/components/checklist/Checklist.css new file mode 100644 index 00000000..c0048f5d --- /dev/null +++ b/components/checklist/Checklist.css @@ -0,0 +1,68 @@ +.checklist { + margin-top: -0.25rem; +} + +.checklist ul { + list-style: none !important; + padding-left: 0; + margin: 0.25em 0; +} + +.checklist ul ul { + list-style: none !important; + padding-left: 1.25rem; + margin: 0; +} + +.checklist li { + position: relative; + padding-left: 26px; + margin: 4px 0; + line-height: 1.5; + color: var(--color-text); +} + +/* Non-checkbox items: show a bullet and reduce left indent */ +.checklist li:not(:has(> input[type="checkbox"])) { + padding-left: 1rem; +} + +.checklist li:not(:has(> input[type="checkbox"]))::before { + content: "•"; + position: absolute; + left: 0; + top: 0; +} + +/* Non-checkbox nested items: tighter spacing */ +.checklist ul ul li:not(:has(input[type="checkbox"])) { + margin: 1px 0; +} + +.checklist li input[type="checkbox"] { + position: absolute; + left: 0; + top: 4px; + width: 16px; + height: 16px; + margin: 0; + cursor: pointer; + accent-color: var(--color-primary, #4339db); +} + +/* Strikethrough applied only to the label span, never cascades into nested lists. */ +.checklist .checklist-label.is-checked { + text-decoration: line-through; + color: var(--color-text-muted); +} + +/* Tighten paragraph wrappers that loose lists add around item text. */ +.checklist li p { + margin: 0; +} + +/* When a checklist follows a list item label, indent to match list depth. */ +ul + .checklist, +ol + .checklist { + padding-left: 1.25rem; +} diff --git a/components/checklist/Checklist.tsx b/components/checklist/Checklist.tsx new file mode 100644 index 00000000..7de59a0c --- /dev/null +++ b/components/checklist/Checklist.tsx @@ -0,0 +1,84 @@ +import { useEffect, useRef, type ReactNode } from "react"; +import "./Checklist.css"; + +interface ChecklistProps { + /** Namespace for localStorage keys — must be unique per checklist section on the page. */ + id: string; + children: ReactNode; +} + +function slugify(text: string): string { + return text + .toLowerCase() + .replace(/[^a-z0-9]+/g, "-") + .replace(/^-+|-+$/g, "") + .slice(0, 60); +} + +export function Checklist({ id, children }: ChecklistProps) { + const ref = useRef(null); + + useEffect(() => { + const container = ref.current; + if (!container || typeof window === "undefined") return; + + const items = container.querySelectorAll("li"); + const cleanups: (() => void)[] = []; + + items.forEach((li) => { + // Only pair with a checkbox that is a direct child — prevents parent + // navigation items (e.g. "Account >") from sharing a descendant's checkbox. + const checkbox = Array.from(li.children).find( + (child): child is HTMLInputElement => + child instanceof HTMLInputElement && child.type === "checkbox" + ); + if (!checkbox) return; + + // Wrap the label text (everything except the checkbox and nested lists) + // in a span so strikethrough only paints over the label, not nested items. + let labelSpan = li.querySelector(":scope > .checklist-label"); + if (!labelSpan) { + labelSpan = document.createElement("span"); + labelSpan.className = "checklist-label"; + const toMove: Node[] = []; + li.childNodes.forEach((node) => { + if (node !== checkbox && !(node instanceof HTMLUListElement)) { + toMove.push(node); + } + }); + toMove.forEach((node) => labelSpan!.appendChild(node)); + checkbox.insertAdjacentElement("afterend", labelSpan); + } + + const key = `checklist:${id}:${slugify(labelSpan.textContent ?? "")}`; + + checkbox.disabled = false; + + try { + if (localStorage.getItem(key) === "true") { + checkbox.checked = true; + labelSpan.classList.add("is-checked"); + } + } catch {} + + const handler = () => { + const checked = checkbox.checked; + try { + localStorage.setItem(key, checked ? "true" : "false"); + } catch {} + labelSpan!.classList.toggle("is-checked", checked); + }; + + checkbox.addEventListener("change", handler); + cleanups.push(() => checkbox.removeEventListener("change", handler)); + }); + + return () => cleanups.forEach((fn) => fn()); + }, [id]); + + return ( +
+ {children} +
+ ); +} diff --git a/components/governance-sdlc/ChecklistItem.css b/components/governance-sdlc/GovernanceChecklistItem.css similarity index 100% rename from components/governance-sdlc/ChecklistItem.css rename to components/governance-sdlc/GovernanceChecklistItem.css diff --git a/components/governance-sdlc/ChecklistItem.tsx b/components/governance-sdlc/GovernanceChecklistItem.tsx similarity index 75% rename from components/governance-sdlc/ChecklistItem.tsx rename to components/governance-sdlc/GovernanceChecklistItem.tsx index dfa219fe..d1759a80 100644 --- a/components/governance-sdlc/ChecklistItem.tsx +++ b/components/governance-sdlc/GovernanceChecklistItem.tsx @@ -1,20 +1,9 @@ import { useEffect, useMemo, useState, type ReactNode } from "react"; -import "./ChecklistItem.css"; - -/** - * ChecklistItem — renders a governance SDLC checklist item as a single - * interactive checkbox next to a bold title, with a plain-paragraph - * description below (no nested list marker). - * - * State is persisted to localStorage so a signer / reviewer can work - * through the list across sessions. The storage key is - * `governance-sdlc-checklist:`, where `id` defaults to a slugified - * version of the title. - */ +import "./GovernanceChecklistItem.css"; const STORAGE_PREFIX = "governance-sdlc-checklist:"; -interface ChecklistItemProps { +interface GovernanceChecklistItemProps { title: string; id?: string; children: ReactNode; @@ -27,7 +16,7 @@ function slugify(input: string): string { .replace(/^-+|-+$/g, ""); } -export function ChecklistItem({ title, id, children }: ChecklistItemProps) { +export function GovernanceChecklistItem({ title, id, children }: GovernanceChecklistItemProps) { const slug = useMemo(() => id ?? slugify(title), [id, title]); const storageKey = `${STORAGE_PREFIX}${slug}`; const descId = `${slug}-desc`; diff --git a/components/index.ts b/components/index.ts index e3e1f478..32aa3b7d 100644 --- a/components/index.ts +++ b/components/index.ts @@ -26,4 +26,5 @@ export { BadgeLegend } from './contributors/BadgeLegend' export { DevOnly } from './dev-only/DevOnly' export { AttackSurfaceDashboard } from './attack-surface/AttackSurfaceDashboard' export { GovernanceSDLCPipeline } from './governance-sdlc/GovernanceSDLCPipeline' -export { ChecklistItem } from './governance-sdlc/ChecklistItem' +export { GovernanceChecklistItem } from './governance-sdlc/GovernanceChecklistItem' +export { Checklist } from './checklist/Checklist' diff --git a/docs/pages/devsecops/data-security-upgrade-checklist.mdx b/docs/pages/devsecops/data-security-upgrade-checklist.mdx index 15bdfd2d..0e3e52a5 100644 --- a/docs/pages/devsecops/data-security-upgrade-checklist.mdx +++ b/docs/pages/devsecops/data-security-upgrade-checklist.mdx @@ -12,7 +12,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -27,6 +27,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr Protecting critical data through automated, encrypted backups and tested recovery procedures is essential for business continuity in Web3 operations. + - [ ] **Automated backups for critical databases, configurations, and off-chain state** - Configure automated backup schedules for all mission-critical systems, including databases (PostgreSQL, MongoDB, etc.), application configurations, environment variables, and off-chain state data (indexer databases, cache @@ -72,12 +73,14 @@ continuity in Web3 operations. Splunk, DataDog, or ELK stack. Set up alerts for backup failures, unauthorized access attempts, or unusual deletion activities. For compliance, retain backup logs for at least 1 year and ensure they are tamper-resistant using immutable or write-once logging/storage controls where appropriate. + ## 2. Secure Storage & Encryption Proper classification and encryption of sensitive data protects user privacy, prevents credential theft, and ensures regulatory compliance. + - [ ] **Sensitive data classification (PII, credentials, secrets, API keys)** - Conduct a data inventory and classify all data by sensitivity: Public (marketing materials), Internal (business data), Confidential (user PII, financial records), and Restricted (credentials, private keys, secrets). In Web3 @@ -119,12 +122,14 @@ regulatory compliance. configuration files. Scan repositories with tools like git-secrets, TruffleHog, or GitHub's secret scanning to detect accidentally committed credentials. For Web3 projects, use hardware wallets or MPC systems for deployment keys rather than filesystem-stored private keys. Implement pre-commit hooks to prevent secret commits. + ## 3. Third-Party Integrations Web3 projects rely heavily on external services—from RPC providers to cloud infrastructure. Properly vetting and securing these integrations prevents supply chain attacks and data breaches. + - [ ] **Maintain comprehensive inventory of all services and integrations** - Document every third-party service your project uses: infrastructure (AWS, Google Cloud, Vercel), blockchain services (Infura, Alchemy, QuickNode), analytics (Mixpanel, Amplitude), monitoring (DataDog, Sentry), @@ -167,6 +172,7 @@ securing these integrations prevents supply chain attacks and data breaches. contract termination), subprocessor restrictions (vendor must disclose and get approval for subcontractors), audit rights (you can audit vendor's security practices), and liability for breaches. For GDPR/CCPA compliance, require Data Processing Agreements (DPAs). Review contracts annually and before renewals. + --- diff --git a/docs/pages/devsecops/governance-proposal-security.mdx b/docs/pages/devsecops/governance-proposal-security.mdx index 15364789..4e6ca4c8 100644 --- a/docs/pages/devsecops/governance-proposal-security.mdx +++ b/docs/pages/devsecops/governance-proposal-security.mdx @@ -12,7 +12,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, GovernanceSDLCPipeline, ChecklistItem } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, GovernanceSDLCPipeline, GovernanceChecklistItem } from '../../../components' @@ -87,7 +87,7 @@ risk that no later audit can fully remove. ### Checklist - + Document your upgrade mechanism thoroughly: proxy pattern type (UUPS, Transparent Proxy, Diamond/EIP-2535, Beacon Proxy), upgrade authorization model (multisig, timelock, governance), admin key custody, and emergency pause @@ -96,9 +96,9 @@ Upgradeable Proxy Standard), document the `upgradeTo()` function and authorizati Proxies, document ProxyAdmin ownership. For Diamond patterns, document facet management. Use tools like Slither's `upgradeability` printer to analyze patterns. - + - + Define who can propose, review, approve, and execute upgrades. Typical roles: Developer (writes upgrade code), Auditor (security review), Multisig Signers (approval), DevOps (deployment execution), Community (governance vote @@ -106,9 +106,9 @@ if applicable). Document each role's responsibilities, required skills, and cont protocols, specify governance proposal requirements, voting thresholds, and timelock durations. Include on-call rotations for emergency upgrades. This prevents confusion during time-critical situations. - + - + Establish a structured process for all upgrades: 1) Proposal submission with technical specification and rationale, 2) Security review by internal team, 3) External audit if material changes, 4) Testnet deployment and @@ -117,9 +117,9 @@ Post-deployment verification, 8) Public disclosure. Use issue tracking (GitHub, proposals. Require approval from the security team, the technical lead, and the product owner before proceeding. Document decision rationale for audit trails. - + - + Implement circuit breakers that allow rapid response to exploits: `pause()` functions (using OpenZeppelin's Pausable pattern) to halt operations, and clear rollback procedures. Document trigger conditions for emergency @@ -128,7 +128,7 @@ pause (e.g., suspicious transactions, exploit detection, oracle manipulation). D reversion, emergency upgrade to safe version). Test pause mechanisms on testnet and mainnet clones. Include contact trees for rapid multisig coordination during incidents. - + Rollback to a previous implementation is not always safe or possible, especially after storage migrations, one-way state changes, or downstream integrations have already reacted. In many cases, the safer path is to pause, contain @@ -178,7 +178,7 @@ nothing more. ### Checklist - + Secure upgrade functions with multi-layer authorization. Use OpenZeppelin's `AccessControl` or `Ownable` patterns with multisig ownership (Safe, Gnosis). Require minimum 3-of-5 or 4-of-7 multisig thresholds for production @@ -187,9 +187,9 @@ upgrades. For UUPS, protect `upgradeTo()` with `onlyOwner` or `onlyRole(UPGRADER Owned Account) admin keys for production contracts. Consider on-chain governance with Compound Governor or OpenZeppelin Governor for decentralized protocols. - + - + Storage collisions are a common source of upgrade bugs. When upgrading, you must maintain storage layout compatibility: never change the order of existing state variables, never change types of existing variables, never @@ -198,9 +198,9 @@ insert new variables in the middle (only append at the end), and gap slots prope layout compatibility. Manually review storage with Slither's `upgradeability` checks. Test storage integrity by reading state before and after upgrade on testnet. - + - + Upgradeable contracts use `initialize()` functions instead of constructors. Protect these with OpenZeppelin's `initializer` modifier to prevent re-initialization attacks that could reset admin controls or drain funds. For @@ -208,9 +208,9 @@ UUPS contracts, ensure implementation contracts are initialized in the construct pattern) to prevent direct implementation usage. Verify that proxy initialization cannot be front-run during deployment. Check that new upgrade logic doesn't introduce new initializers that could be exploited. - + - + Deploy all upgrades to public testnets matching your production chain (Ethereum → Sepolia/Holesky, Polygon → Amoy, Arbitrum → Arbitrum Sepolia, Optimism → Optimism Sepolia). Use testnet configurations identical to mainnet @@ -219,9 +219,9 @@ including multisig signing, timelock queuing, and execution. This catches deploy issues, and interaction bugs before mainnet deployment. Document testnet deployment addresses and transaction hashes. - + - + Before and after upgrade, verify that critical state is preserved correctly. Write scripts to snapshot state before upgrade (token balances, user permissions, protocol parameters, accumulated rewards, LP positions) and @@ -230,9 +230,9 @@ locally. Check that storage variables maintain their values, mappings are intact reset. For DeFi protocols, verify total value locked (TVL) is unchanged, user balances match, and reward calculations continue correctly. - + - + Run full test suite against upgraded contracts: unit tests for new functionality, integration tests for contract interactions, end-to-end tests for user workflows, and backwards compatibility tests. Verify that all existing @@ -241,9 +241,9 @@ withdrawals, swaps, liquidations, governance votes, reward claiming. Use coverag solidity-coverage) to ensure >90% code coverage. Include tests for upgradability-specific risks (storage collisions, initializer vulnerabilities, proxy delegation). - + - + Compare gas costs before and after upgrade for common operations. Increases of >10-20% warrant investigation and may indicate inefficient code or unintended state bloat. Use Hardhat's gas reporter or Foundry's `forge snapshot` @@ -251,9 +251,9 @@ to track gas metrics over time. For high-throughput protocols, benchmark transac Optimize critical paths (token transfers, swaps, mints) to minimize user costs. Consider Layer 2 implications if gas costs become prohibitive. - + - + Test disaster scenarios on testnet: what if the upgrade transaction fails mid-execution? What if the new implementation has a critical bug? Practice rolling back to the previous implementation version. For @@ -261,7 +261,7 @@ timelock-based systems, practice expedited upgrades through emergency multisig. verify it halts operations correctly. Simulate oracle failures, reentrancy attacks, and access control bypasses in the new code. Document lessons learned and update procedures accordingly. - + ### Invariant suites against the proposal @@ -347,7 +347,7 @@ actually reach mainnet. ### Checklist - + For material upgrades (new features, changes to value transfer logic, access control modifications), obtain independent security audits from reputable firms (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certora, @@ -356,9 +356,9 @@ and test suites. Provide a clear upgrade specification and threat model. Budget complexity. Address all findings (Critical/High immediately, Medium/Low with documented risk acceptance). Publish audit reports publicly for transparency. - + - + Deployment scripts are often overlooked but are critical attack vectors. Review all Hardhat/Foundry scripts, multisig transaction builders, and initialization code. Verify addresses (no hardcoded addresses that could be @@ -367,9 +367,9 @@ configurations match production. Test scripts on the local network and testnet b version control and require code review. For complex migrations (data transfers, token migrations), write formal specifications and verify script correctness with testing frameworks like Foundry or Hardhat. - + - + The security firm's scope statement should list, by file and address: proxy contracts, implementation contracts, deploy scripts, proposal-generation scripts, the exact calldata that will be posted onchain, and any governance @@ -377,18 +377,18 @@ module involved (Governor, Timelock). Upgrades that audit only the `.sol` diff w composes the calldata unreviewed are a recurring source of incidents. Require the audit report to state the proposal payload hash it reviewed. - + - + For every finding that is resolved by "risk accepted" rather than "fixed", publish a short rationale before execution — ideally in the same repo commit that freezes the proposal calldata. Signers and voters should be able to see the list of accepted risks next to the upgrade. This makes it impossible for a reviewer to wave through a finding without anyone else noticing. - + - + Integration tests MUST exercise the exact deployment script that will run on mainnet — not a hand-written setup that looks equivalent. If `script/Deploy.s.sol` (or your equivalent) produces a different system state @@ -399,7 +399,7 @@ Have the integration tests execute the deployment script itself, then run invari against the resulting state. The more complex the system, the more surface area exists for the script and the test to drift apart, so the more strictly this needs to be enforced. - + See also [External Security Reviews](/external-security-reviews/overview) and [Audit Preparation Guide](/external-security-reviews/smart-contracts/preparation). @@ -492,7 +492,7 @@ See also ### Execution hygiene - + Execute mainnet upgrades through battle-tested multisig setups. Use production-grade thresholds chosen for your asset value, signer reliability, geographic distribution, and emergency-response needs. Higher thresholds can @@ -503,9 +503,9 @@ wallets (Ledger, Trezor) for signer keys, never hot wallets. Practice simulation mainnet. Document the signing process, verify transaction details with tools like Tenderly or Safe Transaction Builder, and coordinate timing for time-sensitive upgrades. - + - + Implement on-chain timelocks (24-72 hours typical) between upgrade approval and execution. This provides transparency, allows community review of upgrade code and transaction parameters, enables emergency response if @@ -515,9 +515,9 @@ for decentralization. For routine upgrades, publish upgrade intentions publicly links to code changes and audit reports. For emergency or security-sensitive fixes, disclosure timing should be carefully coordinated so that the mitigation is live before unnecessary details are broadcast. - + - + Announce upgrades in advance through all communication channels: website banner, Twitter, Discord, Telegram, governance forum. Provide 48-72 hours' notice for major upgrades, 1 week for breaking changes. Schedule upgrades @@ -528,9 +528,9 @@ any), such as frontend refreshes, re-signing approvals, or migration steps, and upgrade, publish the summary with transaction hashes, deployed contract addresses, audit reports, and changelog. This builds trust and allows ecosystem participants (frontends, aggregators, analytics) to prepare. - + - + Before signing, every signer follows the same short checklist: (1) fetch the onchain proposal and decode its calldata with an independent tool (Tenderly, Safe Transaction Builder, a local `cast decode`); (2) compare the @@ -540,11 +540,11 @@ A signer who cannot complete this checklist should not sign. See [Multisig Runbooks](/multisig-for-protocols/runbooks/overview) and [Security Council Best Practices](/governance/council-best-practices). - + ### Post-execution monitoring - + During upgrade execution, maintain active monitoring with multiple team members online. Watch for: transaction confirmation and success, event emission and proper indexing, protocol health metrics (TVL, active users, @@ -554,9 +554,9 @@ for protocol metrics, and OpenZeppelin Defender for automated monitoring. Have i Keep multisig signers on standby for emergency pause if needed. After successful upgrade, monitor intensively for 24-48 hours. - + - + The invariant suite from Stage 2 is not just for pre-flight testing. Run the same invariants against live state on a schedule (every block for high-value protocols, every few minutes otherwise). Alert on any breach — total @@ -564,14 +564,14 @@ supply drift, collateral-ratio degradation, unexpected role changes, oracle valu exploit enabled by an upgrade will often violate exactly the invariants that were supposed to hold, so continuous checking converts a multi-day incident into a minutes-long one. See [Monitoring Overview](/monitoring/overview). - + - + Maintain an on-call schedule, and practice tabletop exercises to prepare for governance proposal security incidents. - + --- @@ -579,52 +579,52 @@ incidents. ### Common Proxy Patterns - + Implementation contract contains upgrade logic, more gas-efficient but riskier (bug in upgrade logic can brick the contract). Use OpenZeppelin's UUPS implementation. - + - + Separates upgrade logic into ProxyAdmin contract, safer but higher gas costs. Admin calls go to ProxyAdmin, user calls go to implementation. - + - + Supports multiple implementation contracts (facets), allows unlimited contract size, complex but powerful for large protocols. - + - + Multiple proxies share one implementation reference (beacon), efficient for deploying many identical upgradeable contracts. - + ### Real-World Proposal Failures - + Signature verification bypass in upgraded guardian logic allowed attacker to mint 120,000 wETH ($325M). Insufficient testing of upgrade logic and access controls. - + - + Upgrade introduced bug where zero hash was treated as valid proof, allowing anyone to withdraw funds ($190M loss). Lack of proposal audits, reviews, integration and invariant testing locally and in CI were all root causes of this unsafe proposal landing. - + - + [Proposal 117](https://compound.finance/governance/proposals/117) upgraded the cETH market's price-feed integration, but the new implementation was incompatible with the Chainlink oracle interface the market @@ -634,9 +634,9 @@ against the upgraded contracts — the proposal passed review, but no test fork oracle integration. Remediation required a follow-up governance proposal through the timelock, extending market disruption across several days. - + - + The yUSDT vault was deployed in 2020 with the wrong fulcrum address — it pointed at `iUSDC` instead of `iUSDT`. The misconfiguration sat in production for roughly 1,000 days before an attacker exploited it in April 2023 to @@ -645,7 +645,7 @@ that was never caught by integration tests or a deployment-script review — exa Stage 3 of this page's checklists are designed to prevent. [Victim contract on Etherscan](https://etherscan.io/address/0x83f798e925BcD4017Eb265844FDDAbb448f1707D). - + These incidents highlight why rigorous testing, specifically applied to governance proposals and their associated deployment scripts, is essential for safe upgrades. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx index 7c715ac8..98aaf0cb 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -14,7 +14,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -214,6 +214,7 @@ Have a playbook for: ## Operational checklist + - [ ] Untrusted PRs isolated from privileged runners - [ ] Ephemeral runners enabled - [ ] CI token defaults set to read-only @@ -223,6 +224,7 @@ Have a playbook for: - [ ] Resource quotas and timeouts configured - [ ] Artifact signing/provenance verified at release - [ ] Incident response runbook tested + ## References diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx index a8d71871..58ed5b53 100644 --- a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -14,7 +14,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -77,6 +77,7 @@ These controls are both security and reliability controls. ## CI/CD implementation checklist + - [ ] Untrusted jobs run in isolated runner pool - [ ] Default-deny egress applied to untrusted zone - [ ] Destination allowlists documented per pipeline stage @@ -84,6 +85,7 @@ These controls are both security and reliability controls. - [ ] CPU/memory/pids limits configured - [ ] Job and step timeouts enforced - [ ] Max artifact/log size capped + ## Example control matrix diff --git a/docs/pages/guides/account-management/discord.mdx b/docs/pages/guides/account-management/discord.mdx index ed204ebd..ad1aeb78 100644 --- a/docs/pages/guides/account-management/discord.mdx +++ b/docs/pages/guides/account-management/discord.mdx @@ -12,7 +12,7 @@ contributors: users: [nftdreww] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -46,6 +46,7 @@ on their own accounts. ### Account Security Checklist + - [ ] User Settings > My Account: Ensure **2FA** is enabled (authenticator app and/or security key), Remove a phone number if you have one added to your account, and after 2FA is setup select **View Backup Codes**, and note down your backup codes offline @@ -56,6 +57,7 @@ on their own accounts. - [ ] User Settings > Authorized Apps: Review and **Deauthorize** any unnecessary apps - [ ] User Setting > Devices: Review and remove unnecessary devices, or **Log Out All Known Devices** - [ ] User Settings > Connections: Review and remove any unnecessary connections + --- @@ -81,34 +83,44 @@ These settings and practices apply to server administrators with elevated privil #### Safety Setup - Safety Setup > Moderation: + - [ ] Require 2FA for moderation > **Enabled** - This ensures all moderators have an extra layer of security + - Safety Setup > Verification Level: + - [ ] Choose from: None, Low, Medium, High, Highest - [ ] Set to at least **Medium** (registered on Discord for 5+ minutes) — Recommended: "Moderate" for public servers - Higher levels protect against spammers and raids + - Safety Setup > Raid Protection and CAPTCHA: + - [ ] Activate all relevant settings to require CAPTCHA for new user actions - [ ] Activity Alerts > **Enabled** - [ ] CAPTCHA suspicious accounts before they are able to join > **Enabled** - [ ] CAPTCHA all accounts before they are able to join during a suspected raid > **Enabled** - This protection uses machine learning to detect and block bot-driven join-raids. When activated, it sends alerts to a specified channel and requires CAPTCHA verification for new users for one hour after detection. + - Safety Setup > DM and Spam Protection: + - [ ] Hide DMs from suspicious users > **Enabled** - [ ] Filter DMs from unknown users > **Enabled** - [ ] Warn members before they visit outbound links > **Enabled** - [ ] Hide all messages from and delete suspected spammers > **Enabled** + #### AutoMod - Server Settings > Safety Setup > AutoMod: + - [ ] Set up rules for: **Spam**, **Harmful Links**, **Mention Spam**, **Inappropriate Words** - [ ] Configure custom keyword filters and exempted roles - [ ] Customize the response to spam (block message, send alert, timeout member) - [ ] Add to the existing automod rule to block keywords in a user's name: Support, Bot, Admin, Tech, Helpdesk, etc. - [ ] Create a private channel that mods, team, and admins have visibility to and set each AutoMod rule to send logs to that channel for review + #### Server Overview @@ -118,6 +130,7 @@ These settings and practices apply to server administrators with elevated privil #### Roles - Server Settings > Roles: + - [ ] Review admin role members — high-privilege roles with **Administrator** permission should have **2-3 members max** - [ ] Review bot role permissions and confirm members list contains only the bot user @@ -126,6 +139,7 @@ These settings and practices apply to server administrators with elevated privil Server**, **Administrator** - [ ] Remove any lingering or overly broad permissions, and any roles with excess or unintended members - [ ] Check channel-level permission overrides on private channels + > **Note on Role Permissions:** For each role, carefully review the 32 available permissions. Key permissions to > restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels. Never give Admin or Kick @@ -146,9 +160,12 @@ These settings and practices apply to server administrators with elevated privil #### Integrations - Server Settings > Integrations: + - [ ] Review each bot's permissions and remove unnecessary permissions - [ ] Remove any unnecessary integrations & reevaluate necessity of integrations with excessive permissions + - Server Settings > Integrations > Manage Bot/App > **Roles & Members** / **Channels**: + - [ ] Remove permissions for bots that ask for Admin or other permissions that aren't needed — use least privilege with permissions at the role level and channel level - [ ] Uninstall any bots that aren't actively used or needed @@ -156,9 +173,12 @@ These settings and practices apply to server administrators with elevated privil [**Verified**](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified) - [ ] Restrict command permissions of integrations where possible (Manage > Roles & Members / Channels / Command Overrides) + - Server Settings > Integrations > Webhooks: + - [ ] Review and remove any unnecessary webhooks - [ ] Reevaluate necessity of webhooks with excessive permissions + > **Note on Integration Security:** Integrations and webhooks add 3rd party risk and permission misconfiguration risk. > Ensure that permissions are correct, and either remove external integrations or understand the risk they present. @@ -166,22 +186,30 @@ These settings and practices apply to server administrators with elevated privil #### Invites - Server Settings > Invites: + - [ ] Review and delete unnecessary or old invites regularly + #### Privacy Settings - Server Settings > Privacy Settings: + - [ ] Disable **Direct Messages** — this prevents users from DMing other members in this server + #### Community Features - Server Settings > Community: + - [ ] Enable the Community Feature - Unlocks tools like membership screening, server insights, welcome screen, and discovery settings. Helps maintain a structured, secure environment by surfacing official rules and critical info to newcomers. + - Server Settings > Server Insights: + - [ ] Enable Server Insights for detailed analytics - Use this data to inform moderation strategies and server improvements + > **Note on Safety Features:** > @@ -228,12 +256,16 @@ Use **Server Settings > Roles > [Role] > View Server as Role** to see what membe (Right-click channel > Edit Channel > Permissions): + - [ ] Set custom permissions for roles or members in specific channels + #### Channel Settings > Overview + - [ ] Slow Mode: Set appropriate cooldown (e.g., 5-30 seconds) for busy channels - [ ] Age-Restricted Channel: Enable for channels with mature content + --- @@ -348,29 +380,35 @@ setup and maintenance must ONLY access the Cold Admin account from a cold device Create a brand new Gmail account specifically for this Discord account. Do not use a VPN during this process, and it's best to use an incognito browser. After creating the Gmail account: + - [ ] Set up 2FA immediately (authenticator app recommended, or Security Key for maximum security) - [ ] Ensure "Skip password when possible" is **off** - [ ] Do not add a phone number to the account - [ ] Note down the 10 backup codes **offline on paper** (DO NOT store online) - [ ] Write down the email, password, and backup codes on paper and store securely + ##### Step 2: Create the Discord account Head to [https://discord.com](https://discord.com) and create a new account using the Gmail account you just created. + - [ ] Write down the email, username, password, and date of birth **offline** - [ ] Use a username that is not related to your project - [ ] Give the profile a profile picture in **My Account > Edit User Profile** - [ ] Go to **Content & Social** and disable DMs from server members and set spam filter to maximum - [ ] Set the account status to **Invisible** so no one can see if it's online (click profile in bottom left > change status) + ##### Step 3: Join the server and transfer ownership + - [ ] Send the Cold Admin account a friend request from your personal Discord account - [ ] Have the Cold Admin join the Discord server and complete verification like a normal account - [ ] Assign the Cold Admin the highest admin role - [ ] Have the Cold Admin send a few messages in a private team chat - [ ] Wait approximately 24 hours, send a few more messages, then transfer ownership + **To transfer ownership:** Go to **Server Settings > Members** > Search for the Cold Admin account > Click the three dots > Select **Transfer Ownership** > Input 2FA > Confirm diff --git a/docs/pages/guides/account-management/github.mdx b/docs/pages/guides/account-management/github.mdx index 58988cf7..c2d6fdc1 100644 --- a/docs/pages/guides/account-management/github.mdx +++ b/docs/pages/guides/account-management/github.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -26,8 +26,6 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. ---- - ## For Individuals These settings apply to your personal GitHub account. All team members and admins should configure these on their own @@ -36,6 +34,7 @@ accounts. ### Individual Account Settings - Account Settings: + - [ ] Public profile > Contributions & activity > Make profile private and hide activity > **On** - [ ] Password and authentication > Two-factor authentication > Enable and configure any method other than **SMS/Text message** @@ -48,6 +47,7 @@ accounts. - [ ] GitHub Apps > Review and remove any unnecessary - [ ] OAuth Apps > Review and remove any unnecessary - [ ] Personal access tokens > Review and remove any unnecessary + --- @@ -73,21 +73,26 @@ These settings and practices apply to GitHub organization administrators with el #### General Settings + - [ ] General > Danger Zone > Repository visibility > **Private** - [ ] Collaborators and teams > Review access and remove any unnecessary - [ ] Ensure there are no more than 3 admins + #### Branch Protection + - [ ] Branches > Branch protection rules > For each branch that triggers automated deployments, set the following protections: - Protect matching branches > Require a pull request before merging - Require approvals > **2+** recommended - Rules applied to everyone including administrators > Allow force pushes > **Off** + #### Repository Rules - Rules > Rulesets > New ruleset > New branch ruleset: + - [ ] **Name**: EnforceSignedCommits - **Targets**: All branches - **Rules**: @@ -96,10 +101,12 @@ protections: - **Targets**: All branches - **Rules**: - Block force pushes > **On** + #### Actions Security - Actions > + - [ ] Actions permissions > Set minimum permissions needed - **Disable actions** - if not needed - **Allow organization actions and reusable workflows** - if only internal actions are used @@ -109,9 +116,11 @@ protections: - [ ] Workflow permissions > **Read repository contents and packages permissions** - [ ] Allow GitHub Actions to create and approve pull requests > **Off** - [ ] Access > **Not accessible** + #### Security Features + - [ ] Webhooks > Review webhooks and delete any unnecessary or overly permissive - [ ] Pages > Branch > **None** (to disable) - Code security > @@ -121,19 +130,23 @@ protections: - [ ] Grouped security updates > **Disabled** - [ ] Dependabot version updates > **Disabled** - [ ] Access to alerts > No additional users (only admins) + #### Access Control + - [ ] Deploy keys > Remove all [[1]](#1-deploy-keys-warning) - [ ] Secrets and variables > Review secrets and variables and remove any unnecessary - [ ] GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary - [ ] Review permissions are appropriate and that repository access is scoped only to relevant repositories + ### Organization Settings #### Member Privileges - Member privileges > + - [ ] Base permissions > Any other than **Admin** - [ ] Repository creation > Public > **Off** - [ ] Repository forking > Allow forking of private repositories > **Off** @@ -144,10 +157,12 @@ protections: - [ ] Allow members to delete or transfer repositories for this organization > **Off** - [ ] Allow repository administrators to delete issues for this organization > **Off** - [ ] Member team permissions > Allow members to create teams > **Off** + #### Organization Rules - Repository > Rulesets > New ruleset > New branch ruleset: [[2]](#2-enterprise-features) + - [ ] **Name**: EnforceSignedCommits - **Targets > Target repositories**: All branches - **Rules > Branch rules**: @@ -156,9 +171,11 @@ protections: - **Targets > Target repositories**: All branches - **Rules > Branch rules**: - Block force pushes > **On** + #### Project and Actions Settings + - [ ] Planning > Projects > Allow members to change project visibilities for this organization > **Off** - Actions > General > - Policies > **All repositories** @@ -169,9 +186,11 @@ protections: - [ ] Fork pull request workflows in private repositories > Run workflows from fork pull requests > **On** - [ ] Workflow permissions > **Read repository contents and packages permissions** - [ ] Allow GitHub Actions to create and approve pull requests > **Off** + #### Security and Access + - [ ] Webhooks > Review and remove any unnecessary - [ ] For each webhook, ensure SSL verification is enabled - [ ] Packages > Package creation > Public > **Disabled** @@ -179,10 +198,12 @@ protections: - [ ] Require two-factor authentication for everyone in the organization. > **On** - [ ] Only allow secure two-factor methods > **On** - [ ] Deploy keys > **Disabled** + #### Code Security Configuration - Code security > Configurations > New configuration: + - Dependency graph and Dependabot > - [ ] Dependency graph > **Enabled** - [ ] Dependabot alerts > **Enabled** @@ -196,9 +217,11 @@ protections: - [ ] Use as default for newly created repositories > **All repositories** - [ ] Enforce configurations > **Enforce** - [ ] **Save configuration** and **Apply to > All repositories** + #### Access Management + - [ ] Secrets and variables > Review secrets and variables and remove any unnecessary - [ ] GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary - [ ] Review permissions are appropriate and that repository access is scoped only to relevant repositories @@ -208,6 +231,7 @@ protections: - [ ] **Require administrator approval** - [ ] **Restrict access via personal access tokens (classic)** - [ ] **Enroll** [[3]](#3-audit-logs) + --- diff --git a/docs/pages/guides/account-management/godaddy.mdx b/docs/pages/guides/account-management/godaddy.mdx index ba1a7df4..419cff60 100644 --- a/docs/pages/guides/account-management/godaddy.mdx +++ b/docs/pages/guides/account-management/godaddy.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,10 +35,12 @@ These settings apply to your personal GoDaddy account. All team members and admi ### Individual Account Settings - Account Settings > + - Login & Pin > - [ ] 2-Step Verification > **On** (non-SMS) - [ ] Active sign-ins > **Review and remove any unused or unrecognized** - [ ] Delegate Access > **Review and remove any unused or unrecognized** + --- @@ -61,7 +63,9 @@ These settings and practices apply to GoDaddy account administrators who manage ### Domain Security + - [ ] Domain Settings > DNS > DNSSEC > **On** + ### Best Practices diff --git a/docs/pages/guides/account-management/linear.mdx b/docs/pages/guides/account-management/linear.mdx index b99415ea..74c08818 100644 --- a/docs/pages/guides/account-management/linear.mdx +++ b/docs/pages/guides/account-management/linear.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,9 +35,11 @@ These settings apply to your personal Linear account. All team members and admin ### Individual Account Settings - Settings > + - [ ] Sessions, Personal API keys, & Authorized Applications > **Review and remove any unnecessary or unrecognized** - [ ] Passkeys > Add a passkey (recommended) - [ ] Connected Accounts > **Review and remove any unnecessary or unrecognized** + --- @@ -60,15 +62,19 @@ These settings and practices apply to Linear workspace administrators with eleva ### Admin Settings + - [ ] Administration > - [ ] Members > **Review and remove any unnecessary or unrecognized** + - **Security >** + - [ ] Invite links > **Off** - [ ] Approved email domains > **Review and remove any unnecessary or unrecognized** - [ ] Workspace restrictions > **Restrict all** - [ ] Integrations & applications > **Control third-party applications** - [ ] API > OAuth Applications, Webhooks, & Member API keys > **Review and remove any unnecessary or unrecognized** - [ ] Applications > **Review and remove any unnecessary or unrecognized** + --- diff --git a/docs/pages/guides/account-management/mercury.mdx b/docs/pages/guides/account-management/mercury.mdx index 6d251832..271e0690 100644 --- a/docs/pages/guides/account-management/mercury.mdx +++ b/docs/pages/guides/account-management/mercury.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -36,10 +36,12 @@ These settings apply to your personal Mercury account. All team members and admi - Personal > - Security > + - [ ] Two-factor authentication > **On** - [ ] Active sessions > **Review and remove any unused or unrecognized** - [ ] Linked profiles > **Review and remove any unnecessary or unrecognized** - [ ] Remembered devices > **Review and remove any unused or unrecognized** + --- @@ -62,10 +64,12 @@ These settings and practices apply to Mercury account administrators with elevat ### Company Settings - Company > + - [ ] Controls > ACH authorization > **On** - [ ] Approvals > Dual admin approval > **On** - [ ] Integrations > **Review and remove any unused or unrecognized** - [ ] API Tokens > **Review and remove any unused or unrecognized** + --- diff --git a/docs/pages/guides/account-management/notion.mdx b/docs/pages/guides/account-management/notion.mdx index ad17f8c9..8afcb961 100644 --- a/docs/pages/guides/account-management/notion.mdx +++ b/docs/pages/guides/account-management/notion.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,6 +35,7 @@ These settings apply to your personal Notion account. All team members and admin ### Account Security Checklist - Account Settings: + - [ ] My account > Password > If enabled (not using SSO), Enable **2-step verification** - Use **Code from authenticator** - DO NOT use **Text me a code** @@ -43,6 +44,7 @@ These settings apply to your personal Notion account. All team members and admin - [ ] My settings > Privacy > Cookie Settings > Only **Strictly necessary** - [ ] My settings > Privacy > Profile discoverability > **Disabled** - [ ] My connections > Review and disconnect any unnecessary + --- @@ -66,12 +68,15 @@ These settings and practices apply to Notion workspace administrators with eleva #### Member and Site Management + - [ ] People > Review members and guests - [ ] Sites > Review and unpublish any unnecessary pages + #### Security & Data Settings - Security & data > [[1]](#1-enterprise-features) + - [ ] Disable publishing sites and forms > **On** - [ ] Disable duplicating pages to other workspaces > **On** - [ ] Disable export > **On** @@ -81,13 +86,16 @@ These settings and practices apply to Notion workspace administrators with eleva - [ ] Allow members to request adding other members > **Off** - [ ] Allow any user to request to be added as a member of the workspace > **Off** - [ ] Allow page guests to request to be added as members to the workspace > **Off** + #### Connections Management - Connections > + - [ ] Restrict members from adding connections > **Restricted** - [ ] Allow webhooks in automations > **Disabled** - [ ] Review the connections and disconnection any unnecessary + --- diff --git a/docs/pages/guides/account-management/render.mdx b/docs/pages/guides/account-management/render.mdx index f068ac60..8397f006 100644 --- a/docs/pages/guides/account-management/render.mdx +++ b/docs/pages/guides/account-management/render.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,10 +35,12 @@ These settings apply to your personal Render account. All team members and admin ### Account Security Checklist - Account Settings > + - [ ] Account Security > Two-Factor Authentication > **Enabled** - [ ] CLI Tokens > **Review and remove any unnecessary or unrecognized** - [ ] API Keys > **Review and remove any unnecessary or unrecognized** - [ ] SSH Public Keys > **Review and remove any unnecessary or unrecognized** + --- @@ -61,9 +63,11 @@ These settings and practices apply to Render workspace administrators with eleva ### Workspace Settings - Workspace Settings > + - [ ] Team Members > **Review and remove any unnecessary or unrecognized** - [ ] Audit Logs > It is highly recommended that you sign up for an **Organization or Enterprise** plan in order to enable this + --- diff --git a/docs/pages/guides/account-management/sentry.mdx b/docs/pages/guides/account-management/sentry.mdx index f16de57c..31ec202b 100644 --- a/docs/pages/guides/account-management/sentry.mdx +++ b/docs/pages/guides/account-management/sentry.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -26,8 +26,6 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. ---- - ## For Individuals These settings apply to your personal Sentry account. All team members and admins should configure these on their own accounts. @@ -35,6 +33,7 @@ These settings apply to your personal Sentry account. All team members and admin ### Individual Account Settings - User Settings > + - **Account >** - Security > - [ ] Sessions > **Sign out of all devices** @@ -44,8 +43,7 @@ These settings apply to your personal Sentry account. All team members and admin - **API >** - [ ] Applications > **Review and remove any unnecessary or unrecognized** - [ ] User Auth Tokens > **Review and remove any unnecessary or unrecognized** - ---- + ## For Team Members @@ -58,8 +56,6 @@ Team members should: - Regularly review and remove any unnecessary API tokens or authorized applications - Report any suspicious activity or unrecognized access to administrators ---- - ## For Admins These settings and practices apply to Sentry organization administrators with elevated privileges. @@ -67,6 +63,7 @@ These settings and practices apply to Sentry organization administrators with el ### Organization Settings - Organization > + - [ ] Members > **Review and remove any unnecessary or unrecognized** - **Security & Privacy >** - [ ] Require Two-Factor Authentication > **On** @@ -74,12 +71,15 @@ These settings and practices apply to Sentry organization administrators with el - **Data Scrubbing >** - [ ] Prevent Storing of IP Addresses > **Off** - [ ] Integrations > **Review and remove any unnecessary or unrecognized** + ### Developer Settings - Developer Settings > + - [ ] Organization Tokens > **Review and remove any unnecessary or unrecognized** - [ ] Custom Integrations > **Review and remove any unnecessary or unrecognized** + --- diff --git a/docs/pages/guides/account-management/signal.mdx b/docs/pages/guides/account-management/signal.mdx index 1e2a3be9..6923890f 100644 --- a/docs/pages/guides/account-management/signal.mdx +++ b/docs/pages/guides/account-management/signal.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -43,6 +43,7 @@ These settings apply to your personal Signal account. You must be on the phone a ### Account Security Checklist - Account Settings: + - [ ] Settings > Account > Registration Lock > **Enable** - [ ] Settings > Linked Devices > Review the list - [ ] Settings > Calls > Always relay calls (*if privacy is desired*) @@ -56,17 +57,20 @@ These settings apply to your personal Signal account. You must be on the phone a - [ ] Settings > Privacy > Payments Lock > **Enabled** - [ ] Settings > Privacy > Advanced > Always Relay Calls > **Enabled** (privacy) - *This leaks your IP address to contacts via calls when disabled* + --- ### Best Practices & Additional Tips + - [ ] **Review Linked Devices Regularly** - Periodically check your linked devices and remove any that you no longer use or don't recognize. - [ ] **Use a Strong Device PIN** - Signal's security relies on your device's security. Ensure you have a strong PIN or biometric lock on your phone. - [ ] **Be Cautious with Safety Numbers** - Verify safety numbers with contacts when they change to ensure you're communicating with the intended person. + --- diff --git a/docs/pages/guides/account-management/slack.mdx b/docs/pages/guides/account-management/slack.mdx index a4201319..b3e8c99b 100644 --- a/docs/pages/guides/account-management/slack.mdx +++ b/docs/pages/guides/account-management/slack.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -49,24 +49,30 @@ These settings and practices apply to Slack workspace administrators with elevat ### Workspace Settings - Workspace Settings (\.slack.com/admin/settings) + - **Settings >** - [ ] Joining This Workspace > **Review auto-approve domains** or **disable** - **Permissions >** - [ ] Invitations > **Require Admin Approval** + ### Member Management - Manage members (\.slack.com/admin) + - [ ] Review member list and Account type for each member + ### Security Settings - Security Settings (\.slack.com/admin/security) + - **Sign in Settings >** - [ ] Two-factor authentication for email sign‑in > **On** - [ ] Allowed 2FA methods > **Authenticator apps only** - **Device Settings >** - [ ] Jailbroken or rooted devices > **Not allowed** + --- diff --git a/docs/pages/guides/account-management/telegram.mdx b/docs/pages/guides/account-management/telegram.mdx index 9e2aab51..b2bb4cd3 100644 --- a/docs/pages/guides/account-management/telegram.mdx +++ b/docs/pages/guides/account-management/telegram.mdx @@ -10,7 +10,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -43,6 +43,7 @@ their own accounts. ### Account Security Checklist - Account Settings: + - Privacy & Security > - Security > - [ ] Two-Step Verification > **On** @@ -97,9 +98,7 @@ their own accounts. - [ ] Calls > Who can call me > **Nobody**/**My Contacts** - [ ] Calls > Exceptions > Remove all - [ ] Calls > Peer-to-peer > Use peer-to-peer with > **Nobody**/**My Contacts** - - > **Note**: Peer-to-peer calls leak your IP address to callers. Set to **Nobody** to preserve anonymity - + - _Note: Peer-to-peer calls leak your IP address to callers. Set to **Nobody** to preserve anonymity_ - [ ] Calls > Peer-to-peer > Exceptions > Always allow > Remove all - [ ] Groups & Channels > Who can add me to groups and channels > **Nobody**/**My contacts** - This helps prevent being added to random groups that may impersonate legitimate groups and lead to scams. @@ -115,14 +114,13 @@ their own accounts. attacker who gains access to your account could find such information quite valuable. - Advanced > - [ ] Automatic media download > Disable all types in all cases - - > **Note**: Automatic media download leaves you exposed to advanced malware attacks - + - _Note: Automatic media download leaves you exposed to advanced malware attacks_ - Version and updates > - Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features. - [ ] Check for Updates: Visit your device's app store regularly - [ ] Update automatically > **Enabled** - [ ] Install beta versions > **Disabled** + > **Authentication Guidelines**: When establishing a secret chat, > [compare the encryption keys](https://core.telegram.org/techfaq#q-how-are-secret-chats-authenticated) @@ -139,26 +137,24 @@ to use a secure platform like [Signal](https://signal.org/) for confidential com Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages. + - [ ] **Enable Full Device Encryption**: - Ensure your device has full disk encryption enabled - For iOS: This is enabled by default with a passcode - For Android: Go to **Settings > Security > Encryption** and follow instructions - - [ ] **Set Strong Device Passcodes**: - Use alphanumeric passwords rather than simple PINs - Enable biometric authentication as a secondary measure - - [ ] **Keep Your Device Updated**: - Install OS updates promptly to patch security vulnerabilities - Update Telegram to the latest version regularly - - [ ] **Install Security Software**: - Use reputable anti-malware software on your device - Consider privacy-focused apps that detect network anomalies - - [ ] **Secure Your Backups**: - Ensure any device backups containing Telegram data are encrypted - Be cautious about cloud backups that might store Telegram messages + --- @@ -197,13 +193,16 @@ encryption**. **Go to:** Settings > Privacy and Security > Data Settings + - [ ] **Sync Contacts:** Disable (depending on use of Telegram) to prevent syncing your contacts. - [ ] **Suggest Frequent Contacts:** Disable (depending on use of Telegram) to avoid unsolicited contact suggestions. + --- ### Best Practices for Safe Use + - [ ] **Use Secret Chats:** When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions. - [ ] **Verify Group Invites and Authenticity:** Always triple-check group invitations and confirm the legitimacy of @@ -229,6 +228,7 @@ instead of just deleting chats. app. - [ ] **Stay Vigilant Against Scam Ads:** Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements. + --- @@ -298,13 +298,16 @@ These settings and practices apply to Telegram group/channel administrators with #### Channel Settings - Open channel > click channel name > **Channel settings** + - [ ] Sign messages > **Enable** (if non-repudiation is desired) - [ ] Administrators > Review the list and remove any unnecessary + #### Group Settings - Open group > click group name > click three dots > **Manage group** + - [ ] Channel type > **Private** (if public discoverability is not necessary) - [ ] Channel type > Content protection > **Enabled** (if confidentiality is needed) - [ ] Sign messages > **Enabled** @@ -326,6 +329,7 @@ These settings and practices apply to Telegram group/channel administrators with - Remove unnecessary permissions, especially **Add new admins** - **Aggressive Anti-Spam** > **Enabled** - [ ] **Members** > Review and remove unnecessary (If a confidential channel) + --- @@ -333,42 +337,41 @@ These settings and practices apply to Telegram group/channel administrators with If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security. + - [ ] **Limit Admin Privileges**: - Go to your group/channel, tap the group name, select **Administrators** - Only grant necessary permissions to each admin - Avoid giving "Add Users" permission to untrusted admins - - [ ] **Implement Admin Verification**: - Establish a verification process before promoting members to admin - Use separate channels (like voice calls) to confirm admin identities - Document when admin changes occur and why - - [ ] **Configure Group Settings**: - Restrict member actions such as sending media or links - Enable "Slow Mode" for large groups to prevent spam - Use discussion groups for channels to control information flow - - [ ] **Audit Admin Activities**: - Regularly review admin actions in the group - Remove inactive or suspicious admins - Consider using admin action logs if available - - [ ] **Handle Admin Transitions Securely**: - Have protocols for transferring ownership if needed - Revoke admin rights immediately when team members leave - - [ ] **Limit Group Permissions:** Restrict who can add members to groups to prevent unauthorized cloning and protect against raids. + --- ### Additional Recommendations + - [ ] Add a disclaimer in the description and/or as a pinned message to your channel that states that you will not DM users, and that support will only be offered via the public channel and dedicated support channels [[2]](#2-security-disclaimers) - [ ] Add a suffix to admin usernames, for example: "MyName | will never DM you" - [ ] Each admin must follow the guidance for securing their individual accounts + --- @@ -376,30 +379,28 @@ users, and that support will only be offered via the public channel and dedicate If you're managing a community on Telegram, educating your members about security is vital for collective protection. + - [ ] **Regular Security Announcements**: - Schedule periodic reminders about security best practices - Pin important security announcements in your group/channel - Create dedicated security FAQ channels or posts - - [ ] **Clear Verification Procedures**: - Establish and communicate how official communications will occur - Create verification steps for new members to follow - Document how to verify the authenticity of admins and official messages - - [ ] **Threat Awareness Training**: - Share examples of common scams targeting your community - Post screenshots of phishing attempts (with sensitive info redacted) - Explain the "Man-in-the-Group Attack" and how to avoid it - - [ ] **Incident Reporting Protocol**: - Create clear guidelines for reporting suspicious activity - Designate security-focused admins to handle reports - Acknowledge reports publicly (without specifics) to encourage vigilance - - [ ] **Security Resources**: - Develop simple, accessible security guides for members - Share platform-specific security updates when Telegram releases them - Create a security checklist for new community members + --- diff --git a/docs/pages/guides/account-management/trello.mdx b/docs/pages/guides/account-management/trello.mdx index 741163a9..c6cef795 100644 --- a/docs/pages/guides/account-management/trello.mdx +++ b/docs/pages/guides/account-management/trello.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -37,14 +37,17 @@ These settings apply to your personal Trello account. ### Account Security Checklist - Account Settings: + - [ ] Applications > Review and remove any unnecessary - [ ] Sessions > Manage your recent devices > Review and remove any unnecessary - [ ] Sessions > Two-step verification > **On** + --- ### Best Practices & Additional Tips + - [ ] **Use a Strong, Unique Password** - Ensure your Trello password is unique and not reused from other services. - [ ] **Review Board Permissions** @@ -53,6 +56,7 @@ These settings apply to your personal Trello account. - Only enable Power-Ups from trusted sources, as they may have access to your board data. - [ ] **Check Email Notifications** - Ensure notifications are enabled so you're alerted to any unexpected board activity or access changes. + --- diff --git a/docs/pages/guides/account-management/twitter.mdx b/docs/pages/guides/account-management/twitter.mdx index ce2acbd0..d2c9af23 100644 --- a/docs/pages/guides/account-management/twitter.mdx +++ b/docs/pages/guides/account-management/twitter.mdx @@ -10,7 +10,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -43,6 +43,7 @@ these on their own accounts. ### Account Security Checklist - Account Settings: + - Settings > Security and account access > - **Security >** - [Two-factor authentication](https://x.com/settings/account/login_verification) > @@ -94,11 +95,13 @@ these on their own accounts. - [ ] Your account > [Change your password](https://x.com/settings/password) > Use a unique, long, complex password - Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so. + --- ### Best Practices & Additional Tips + - [ ] **Disable Email and Phone Discoverability** - **Go to:** [Discoverability and Contacts](https://x.com/settings/contacts) - It is recommended to turn both email and phone discoverability off. @@ -116,6 +119,7 @@ these on their own accounts. - [ ] **Verify Email Authenticity:** - If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com" + --- @@ -153,9 +157,11 @@ The organization account should follow the same security settings as individuals If using Typefully for team collaboration: + - [ ] Ensure that team members in Typefully [have only the Write permission](https://support.typefully.com/en/articles/8717333-collaboration-in-typefully#h_0d94ada9a9), with a minimum amount of Publishers and Admins. + --- diff --git a/docs/pages/guides/account-management/vercel.mdx b/docs/pages/guides/account-management/vercel.mdx index 5dbd2d5f..34c66cc4 100644 --- a/docs/pages/guides/account-management/vercel.mdx +++ b/docs/pages/guides/account-management/vercel.mdx @@ -8,7 +8,7 @@ contributors: users: [auditware] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -36,9 +36,11 @@ These settings apply to your personal Vercel account. All team members and admin For individual Vercel accounts, ensure you have: + - [ ] Two-factor authentication enabled on your account - [ ] Review and remove any unnecessary personal access tokens - [ ] Review connected Git accounts and remove any unnecessary connections + --- @@ -63,6 +65,7 @@ These settings and practices apply to Vercel team administrators with elevated p ### Team Settings - Team Settings > + - Members > - [ ] Team Members > **Review and remove any unnecessary or unrecognized** - [ ] Pending Invitations > **Review and remove any unnecessary or unrecognized** @@ -80,13 +83,16 @@ These settings and practices apply to Vercel team administrators with elevated p - [ ] Projects > **Ensure all are protected** - [ ] Access > **Review and remove any unnecessary or unrecognized** - [ ] Environment Variables > **Review and ensure all secrets are marked as Sensitive** + ### Project Settings - Project Settings > Security > + - [ ] Build Logs and Source Protection > **Enabled** - [ ] Git Fork Protection > **Enabled** - [ ] Secure Backend Access With OIDC Federation > **Team** + --- diff --git a/docs/pages/guides/endpoint-security/hardware-security-keys.mdx b/docs/pages/guides/endpoint-security/hardware-security-keys.mdx index 0cad9161..686e61b4 100644 --- a/docs/pages/guides/endpoint-security/hardware-security-keys.mdx +++ b/docs/pages/guides/endpoint-security/hardware-security-keys.mdx @@ -8,7 +8,7 @@ contributors: users: [dickson, louis, pablo] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,6 +35,7 @@ hardware key. ### Setup Checklist + - [ ] Buy at least **two** security keys from a reputable vendor such as Yubico - [ ] Prefer keys that match your device mix: - USB-C for modern laptops and phones @@ -54,6 +55,7 @@ hardware key. - [ ] Disable **SMS** as a recovery or second-factor method wherever the service allows it - [ ] Save provider-issued backup or recovery codes offline - [ ] Test both the primary and backup key after enrollment + ### YubiKey Setup Notes diff --git a/docs/pages/guides/endpoint-security/password-manager-endpoint-hardening.mdx b/docs/pages/guides/endpoint-security/password-manager-endpoint-hardening.mdx index d560ee95..9d0c5d09 100644 --- a/docs/pages/guides/endpoint-security/password-manager-endpoint-hardening.mdx +++ b/docs/pages/guides/endpoint-security/password-manager-endpoint-hardening.mdx @@ -10,7 +10,7 @@ contributors: users: [dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -33,14 +33,17 @@ extra hardening. ### Minimum Device Baseline + - [ ] Use only supported, regularly updated operating systems and browsers - [ ] Enable full-disk encryption on every device that can access the vault - [ ] Require a real screen lock with a 5-minute-or-less idle timeout and password on wake - [ ] Enable device location, remote lock, and remote wipe features before you need them - [ ] Keep the password manager set to lock on sleep, device lock, and browser or app exit + ### Safer Browser and Vault Usage + - [ ] Use a dedicated browser profile for work or other high-value accounts - [ ] Keep that profile minimal: ideally only the password manager extension, and otherwise a short allowlist of extensions you actively need and trust @@ -48,22 +51,27 @@ extra hardening. - [ ] Verify the domain before filling credentials for high-impact accounts such as registrars, GitHub, cloud, finance, or admin panels - [ ] Avoid logging into the work vault from throwaway browsers, borrowed devices, or lightly managed systems + ### Clipboard and Copy/Paste Hygiene + - [ ] Prefer direct fill into the browser or app instead of copying secrets to the clipboard - [ ] Disable clipboard history and cross-device clipboard sync on endpoints used for sensitive workflows - [ ] If you must copy a secret, paste it immediately and clear the clipboard or rely on the password manager's auto-clear setting if supported + ### Protecting the Password Manager Account + - [ ] Use phishing-resistant MFA such as FIDO2/WebAuthn security keys where supported - [ ] For highest-risk operators, prefer hardware security keys over broadly syncable authenticators when possible - [ ] Keep at least two recovery-capable authenticators enrolled - [ ] Do not rely on SMS as the primary recovery or second-factor method - [ ] Store recovery codes or emergency-kit material offline and separately from the device - [ ] Avoid circular dependency: do not make the only copy of recovery material depend on access to the same vault + ## Web3-Specific Operational Rules diff --git a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx index 75808e18..e7122007 100644 --- a/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx +++ b/docs/pages/guides/endpoint-security/ssh-client-and-key-management-hardening.mdx @@ -11,7 +11,7 @@ contributors: users: [mattaereal, pinalikefruit] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -37,6 +37,7 @@ These steps apply to developers, operators, admins, and contributors who use SSH ### Setup Checklist + - [ ] Use **Ed25519** for new software keys by default - [ ] Add a **strong passphrase** to every human-held software key - [ ] For higher-risk access, prefer a **hardware-backed security-key SSH credential** such as `ed25519-sk` @@ -51,6 +52,7 @@ These steps apply to developers, operators, admins, and contributors who use SSH rotation - [ ] Keep `~/.ssh` and private key files accessible only to you - [ ] Review and remove stale keys after device loss, role changes, or offboarding + ### Passphrases and Local Protection @@ -106,6 +108,7 @@ team. ### Program Checklist + - [ ] Maintain an inventory for each SSH credential: owner, device, purpose, target systems, creation date, and revoke trigger - [ ] Require one key per person, device, and purpose instead of shared identities @@ -115,6 +118,7 @@ team. - [ ] Revoke keys immediately after offboarding, device loss, or suspected compromise - [ ] Keep human access and automation access logically separate - [ ] Document a simple recovery and reissue process for lost devices and security keys + ### Git Hosting, CI/CD, and Automation diff --git a/docs/pages/guides/endpoint-security/zoom-hardening.mdx b/docs/pages/guides/endpoint-security/zoom-hardening.mdx index 3bd82fe2..6022db46 100644 --- a/docs/pages/guides/endpoint-security/zoom-hardening.mdx +++ b/docs/pages/guides/endpoint-security/zoom-hardening.mdx @@ -13,7 +13,7 @@ contributors: users: [] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -52,6 +52,7 @@ These mitigations address the specific attack vectors described in the Trail of COMET research and should be treated as **non-negotiable** for any organization handling sensitive assets. + - [ ] **Disable remote control**: Settings > Meeting > In Meeting (Basic) > Remote control > **OFF** - [ ] **Disable participant screen sharing (host only)**: Settings > Meeting > In Meeting (Basic) > Screen sharing > Who can share? > **Host Only** @@ -65,17 +66,20 @@ sensitive assets. [macOS mitigations](#macos-specific-mitigations) below. - [ ] **Remove Zoom desktop client when possible**: Uninstall entirely to eliminate the attack surface. + ### Optional General Zoom security best practices. These do not directly mitigate the ELUSIVE COMET attack but improve overall meeting security hygiene. + - [ ] **Enable waiting rooms**: Settings > Meeting > Security > Waiting Room > **ON** - [ ] **Require meeting passcodes**: Settings > Meeting > Security > Require a passcode when scheduling new meetings > **ON** - [ ] **Disable automatic recording**: Settings > Meeting > Recording > Automatic recording > **OFF** (enable only when explicitly needed) + ## macOS-specific mitigations diff --git a/docs/pages/incident-management/forensic-readiness.mdx b/docs/pages/incident-management/forensic-readiness.mdx index 488821c6..f6acd213 100644 --- a/docs/pages/incident-management/forensic-readiness.mdx +++ b/docs/pages/incident-management/forensic-readiness.mdx @@ -15,7 +15,7 @@ contributors: users: [] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -122,6 +122,7 @@ silent mutation, and associated with a defensible chain of custody. That is a di ### Best-practice checklist + - [ ] All critical evidence sources are inventoried and classified by volatility - [ ] Retention periods are defined for each evidence source and meet or exceed regulatory requirements - [ ] High-volatility evidence (ephemeral containers, in-memory data) has automated capture before loss @@ -132,6 +133,7 @@ silent mutation, and associated with a defensible chain of custody. That is a di - [ ] Forensic readiness procedures are referenced in the incident response plan - [ ] Tabletop exercises include forensic readiness validation at least annually - [ ] Access to forensic artifacts is logged and restricted to authorized personnel + ### Role-based tips diff --git a/docs/pages/incident-management/incident-response-template/communications.mdx b/docs/pages/incident-management/incident-response-template/communications.mdx index 2d7c1061..18f993dc 100644 --- a/docs/pages/incident-management/incident-response-template/communications.mdx +++ b/docs/pages/incident-management/incident-response-template/communications.mdx @@ -10,7 +10,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -26,11 +26,13 @@ Templates and building blocks for incident communications. Adapt these to your s ### Checklist + - [ ] Get approval from Incident Leader or Decision Maker - [ ] Verify facts are accurate - [ ] Avoid speculation about root cause (until confirmed) - [ ] Include what users should do (or not do) - [ ] State when you'll provide the next update + ### What to Include diff --git a/docs/pages/incident-management/incident-response-template/contacts.mdx b/docs/pages/incident-management/incident-response-template/contacts.mdx index b199aad2..206bd0a3 100644 --- a/docs/pages/incident-management/incident-response-template/contacts.mdx +++ b/docs/pages/incident-management/incident-response-template/contacts.mdx @@ -10,7 +10,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -126,16 +126,20 @@ Protocols, exchanges, or other partners to notify during major incidents. For P1 (critical) incidents, contact in this order: + 1. [ ] SEAL 911 (if active exploit) 2. [ ] Decision Makers (internal) 3. [ ] Security Partners (if needed) 4. [ ] Legal (if fund loss or regulatory implications) + ## Maintenance + - [ ] Review and update quarterly - [ ] Verify contact info after team changes - [ ] Test escalation paths periodically + **Owner:** [Assign someone to maintain this document] diff --git a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx index fa350580..bcea5444 100644 --- a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx +++ b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -159,10 +159,12 @@ If a temporary fix (rollback, pause, disable feature) is faster than a full fix **Checklist:** + - [ ] Apply temporary mitigation - [ ] Verify it's working - [ ] Notify stakeholders - [ ] Plan permanent fix with owner and timeline + See [Runbooks](./runbooks/overview) for step-by-step guides for specific incident types. diff --git a/docs/pages/incident-management/incident-response-template/overview.mdx b/docs/pages/incident-management/incident-response-template/overview.mdx index 428b71fa..77f104c1 100644 --- a/docs/pages/incident-management/incident-response-template/overview.mdx +++ b/docs/pages/incident-management/incident-response-template/overview.mdx @@ -10,7 +10,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -102,6 +102,7 @@ Review and adapt these pages for your own internal incident response documentati Before using this template, customize these sections: + - [ ] **Incident Response Policy** - [ ] Update severity level examples for your protocol - [ ] Add your communication tools (Slack/Discord/Telegram) @@ -119,6 +120,7 @@ Before using this template, customize these sections: - [ ] Customize for your specific infrastructure - [ ] Add protocol-specific scenarios - [ ] Fill in actual commands and dashboards + ### Quick Start diff --git a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx index b53debc9..4b59d214 100644 --- a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx +++ b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -148,12 +148,14 @@ ex. With 8 people per rotation, each person is on-call one week every two months Before going on-call, complete: + - [ ] Review [Incident Response Policy](./incident-response-policy) - [ ] Review [Incident Log](./templates/incident-log-template) and [Post-Mortem](./templates/post-mortem-template) templates - [ ] Read 2-3 past post-mortems - [ ] Understand basic architecture (infra and smart contracts) - [ ] Know how to reach SMEs and Decision Makers - [ ] Test alerting system access + ### On-Call Expectations @@ -191,12 +193,14 @@ These people should be reachable 24/7 for critical incidents. Consider: Ensure your on-call personnel have access to: + - [ ] Alerting system (PagerDuty, etc.) - [ ] Communication platform (Slack, Discord, etc.) - [ ] Video conferencing - [ ] Monitoring dashboards - [ ] On-call schedule - [ ] [Contacts](./contacts) list + ## Choosing Your Model diff --git a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx index 55041860..0a4bf980 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -36,10 +36,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Unexpected code in deployed artifacts - [ ] CI/CD configuration changed without approval - [ ] Secrets accessed or exfiltrated - [ ] Unauthorized workflow runs + ### Confirm Compromise @@ -49,26 +51,32 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## Immediate Actions -1. [ ] Disable compromised pipelines -2. [ ] Rotate all secrets and tokens -3. [ ] Take down potentially compromised deployments -4. [ ] Audit recent builds and deployments + +- [ ] Disable compromised pipelines +- [ ] Rotate all secrets and tokens +- [ ] Take down potentially compromised deployments +- [ ] Audit recent builds and deployments + ## Mitigation -1. [ ] Audit CI/CD configuration for unauthorized changes -2. [ ] Rebuild from trusted commit using clean pipeline -3. [ ] Implement additional approval requirements -4. [ ] Review and restrict pipeline permissions + +- [ ] Audit CI/CD configuration for unauthorized changes +- [ ] Rebuild from trusted commit using clean pipeline +- [ ] Implement additional approval requirements +- [ ] Review and restrict pipeline permissions + ## Prevention + - [ ] Require approval for CI/CD config changes - [ ] Use short-lived credentials - [ ] Implement branch protection - [ ] Audit pipeline access regularly - [ ] Use signed commits - [ ] Separate build and deploy permissions + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx index d9347d79..b92bbfd0 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -36,9 +36,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Malicious files being served - [ ] File hashes don't match expected - [ ] Unauthorized access in provider logs + ### Confirm Compromise @@ -47,25 +49,31 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## Immediate Actions -1. [ ] Purge CDN cache -2. [ ] Take down site or redirect to maintenance page -3. [ ] Rotate all access credentials -4. [ ] Review access logs for unauthorized activity + +- [ ] Purge CDN cache +- [ ] Take down site or redirect to maintenance page +- [ ] Rotate all access credentials +- [ ] Review access logs for unauthorized activity + ## Mitigation -1. [ ] Redeploy from verified source (git, not existing infra) -2. [ ] Verify deployment matches expected -3. [ ] Enable additional access controls -4. [ ] Set up file integrity monitoring + +- [ ] Redeploy from verified source (git, not existing infra) +- [ ] Verify deployment matches expected +- [ ] Enable additional access controls +- [ ] Set up file integrity monitoring + ## Prevention + - [ ] Limit hosting/CDN admin access - [ ] Enable 2FA on all accounts - [ ] Use subresource integrity (SRI) - [ ] Implement Content Security Policy (CSP) - [ ] Regular access audits + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx index f2c0b604..1016af3a 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -37,11 +37,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Website/API unresponsive or slow - [ ] Monitoring shows traffic spike - [ ] CDN/hosting alerts - [ ] Error rate increase - [ ] Legitimate requests timing out + ### Differentiation @@ -59,9 +61,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr **Why:** Distinguish from application issues + - [ ] Check CDN/WAF dashboards - [ ] Review traffic patterns - [ ] Check if specific endpoints targeted + ### Step 2: Enable DDoS Protection @@ -81,18 +85,22 @@ For AWS: ### Step 3: Assess Impact + - [ ] Which services affected? - [ ] Are critical functions available? - [ ] User impact level? + ## Investigation ### Key Questions + - [ ] Attack type (volumetric, protocol, application layer)? - [ ] Targeted endpoints? - [ ] Attack source patterns? - [ ] Why now? (retaliation, extortion, distraction?) + ### Data to Collect @@ -128,8 +136,10 @@ For AWS: ## Escalation + - [ ] [CDN/hosting provider](../contacts#infrastructure-vendors) - for attack mitigation support - [ ] [Decision Makers](../contacts#decision-makers) - if extended outage + ## Recovery @@ -142,10 +152,12 @@ For AWS: ### Post-Attack + - [ ] Review logs for attack details - [ ] Update protection rules - [ ] Document attack patterns - [ ] Consider permanent mitigations + ## Communication @@ -164,11 +176,13 @@ Usually not needed for brief DDoS attacks. Avoid drawing attention. After resolving, consider: + - [ ] Always-on DDoS protection - [ ] Rate limiting by default - [ ] Geographic restrictions if appropriate - [ ] Improved caching - [ ] Backup/failover infrastructure + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx index 6919a27b..13b8e4b9 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -36,10 +36,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Unexpected behavior after dependency update - [ ] Security advisory for a package you use - [ ] Malicious code found in node_modules or similar - [ ] Lockfile changes you didn't make + ### Confirm Dependency Attack @@ -53,26 +55,32 @@ Check for recent lockfile changes in git history. ## Immediate Actions + 1. [ ] Take down site to stop serving malicious code 2. [ ] Identify the malicious package 3. [ ] Pin dependencies to last known good version 4. [ ] Rebuild from clean environment + ## Mitigation + 1. [ ] Remove or replace malicious package 2. [ ] Update lockfile with known good versions 3. [ ] Rebuild using `npm ci` or `yarn --frozen-lockfile` 4. [ ] Redeploy verified build + ## Prevention + - [ ] Use lockfiles and commit them - [ ] Use `npm ci` / `yarn --frozen-lockfile` in CI - [ ] Regularly audit dependencies - [ ] Consider using a private registry - [ ] Pin exact versions for critical packages - [ ] Review dependency changes in PRs + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx index 7c945fcc..8387c843 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -36,9 +36,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Domain pointing to wrong IP - [ ] Users redirected to malicious site - [ ] SSL certificate errors (attacker using different cert) + ### Confirm DNS Hijack @@ -49,10 +51,12 @@ dig yourdomain.com ## Immediate Actions + 1. [ ] Regain access to DNS provider account 2. [ ] Enable 2FA if not already enabled 3. [ ] Point DNS to known good infrastructure or maintenance page 4. [ ] Enable DNS lock / registrar lock + ## Mitigation @@ -60,11 +64,13 @@ dig yourdomain.com ## Prevention + - [ ] Enable registrar lock - [ ] Use DNSSEC - [ ] Enable 2FA on DNS provider - [ ] Limit DNS admin access - [ ] Monitor DNS records for changes + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx index 9c1a9f64..aa93936b 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -37,12 +37,14 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Users report unexpected transaction requests - [ ] UI behaving differently than expected - [ ] Wallet drainer detected - [ ] Injected scripts in page source - [ ] DNS/domain issues - [ ] Community reports of phishing via official domain + ### Attack Vectors @@ -62,18 +64,22 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr Options: + - [ ] Point DNS to maintenance page - [ ] Disable CDN distribution - [ ] Remove site from hosting - [ ] Add banner/warning if partial control + ### Step 2: Warn Users **Why:** Prevent further damage + - [ ] Post on Twitter/X - [ ] Post in Discord/Telegram - [ ] Update status page + Message template: > Our website may be compromised. Do NOT interact with [domain] or approve any transactions until further notice. @@ -81,10 +87,12 @@ Message template: ### Step 3: Assess Scope + - [ ] What was changed? - [ ] How long was it compromised? - [ ] How many users potentially affected? - [ ] Were any transactions signed? + ## Investigation @@ -92,7 +100,9 @@ Message template: The first priority is understanding how the attacker gained access so you can close that vector: + - [ ] **How did attacker gain access?** (DNS, CDN, dependencies, CI/CD, hosting) + Once identified, go to the specific runbook: @@ -105,9 +115,11 @@ Once identified, go to the specific runbook: After the threat is contained, investigate impact: + - [ ] What was injected/changed? - [ ] Which users interacted during compromise window? - [ ] What were users tricked into signing? + ### Check These @@ -132,11 +144,13 @@ See the specific runbook for detailed mitigation steps: ### Before Restoring Service + - [ ] Root cause identified - [ ] Vulnerability fixed - [ ] Fresh deployment from verified source - [ ] All credentials rotated - [ ] Additional security measures in place + ### Restoring Service @@ -150,27 +164,33 @@ See the specific runbook for detailed mitigation steps: If users signed malicious transactions: + - [ ] Compile list of affected addresses (from chain data) - [ ] Provide guidance on revoking approvals - [ ] Consider compensation if protocol at fault - [ ] Document for post-mortem + ## Escalation + - [ ] [Decision Makers](../contacts#decision-makers) - immediately - [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - if hosting/CDN involved - [ ] [Legal & Communications](../contacts#legal--communications) - for user communication + ## Prevention Checklist After resolving, review: + - [ ] DNS provider security (2FA, lock) - [ ] Hosting access controls - [ ] CI/CD security - [ ] Dependency management - [ ] Subresource integrity - [ ] Content Security Policy + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx index 5442690e..8df1814e 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -37,11 +37,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Unauthorized transactions from controlled addresses - [ ] Unexpected multisig proposals - [ ] Key holder reports compromise - [ ] Suspicious signing activity - [ ] Social engineering attempt succeeded + ### Key Types @@ -58,17 +60,21 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr **Why:** Avoid false positives, but err on side of caution + - [ ] Verify with key holder directly (not via potentially compromised channels) - [ ] Check for unauthorized transactions - [ ] Review recent signing activity + ### Step 2: Assess Blast Radius **Why:** Understand what the attacker can do + - [ ] What can this key sign? - [ ] Are there timelocks? - [ ] What other systems use this key? + ### Step 3: Revoke/Rotate @@ -76,34 +82,44 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr For multisig signers: + - [ ] Remove compromised signer - [ ] Add replacement signer + For admin keys: + - [ ] Transfer ownership to new address - [ ] Or revoke permissions if possible + For hot wallets: + - [ ] Move remaining funds to secure address + ### Step 4: Check for Damage **Why:** Understand if attacker acted + - [ ] Review all transactions from compromised key - [ ] Check pending proposals/timelocks - [ ] Audit any systems key had access to + ## Investigation ### Key Questions + - [ ] How was the key compromised? (phishing, malware, insider, leaked) - [ ] When was it compromised? - [ ] What did the attacker do (if anything)? - [ ] Are other keys at risk? + ### Evidence to Collect @@ -140,20 +156,24 @@ For hot wallets: ## Escalation + - [ ] [Decision Makers](../contacts#decision-makers) - immediately for any confirmed compromise - [ ] [Security Partners](../contacts#security-partners) - for investigation support - [ ] [Legal](../contacts#legal--communications) - if funds were stolen + ## Prevention Checklist After resolving, review: + - [ ] Key storage practices - [ ] Phishing awareness training - [ ] Hardware wallet usage - [ ] Multisig thresholds - [ ] Access logging - [ ] Key rotation schedule + ## Related diff --git a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx index 6caba362..2e9ea630 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -61,11 +61,13 @@ Good runbooks: Consider creating runbooks for: + - [ ] Oracle manipulation - [ ] Governance attack - [ ] SSL certificate issues - [ ] Deployment failure/rollback - [ ] Data inconsistency + *See [Incident Response Policy](../incident-response-policy) for the overall response process.* diff --git a/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx b/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx index 470d18dc..5021e79e 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -37,11 +37,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Unexpected fund movements - [ ] On-chain monitoring alerts - [ ] Unusual transaction patterns - [ ] Community reports of lost funds - [ ] Abnormal contract state changes + ### Alerts @@ -60,9 +62,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr **Why:** Understand what's at risk before acting + - [ ] Check total funds at risk - [ ] Identify affected contracts - [ ] Determine if exploit is ongoing + ### Step 2: Contact SEAL 911 @@ -86,20 +90,24 @@ If your contracts have pause functionality: **Why:** Needed for investigation and potential recovery + - [ ] Screenshot/save relevant transactions - [ ] Note block numbers - [ ] Save mempool data if available - [ ] Document attacker addresses + ## Investigation ### Key Questions + - [ ] What vulnerability was exploited? - [ ] How much was taken/at risk? - [ ] Is the exploit still possible? - [ ] Are other contracts affected? - [ ] Was this reported via bug bounty first? + ### Information to Gather @@ -143,17 +151,21 @@ If your contracts have pause functionality: Contact immediately: + - [ ] [Decision Makers](../contacts#decision-makers) - [ ] [Security Partners](../contacts#security-partners) - [ ] [Legal](../contacts#legal--communications) if significant fund loss + ## Post-Exploit + - [ ] Determine fix approach - [ ] Plan for affected users (if any) - [ ] Prepare public communication - [ ] Consider disclosure timeline - [ ] Engage with law enforcement if appropriate + ## Common Root Causes diff --git a/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx b/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx index fe898573..cd2c153e 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -37,10 +37,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### Symptoms + - [ ] Specific functionality broken - [ ] Errors referencing external service - [ ] Status page shows provider outage - [ ] Timeouts to external endpoints + ### Common Dependencies @@ -60,21 +62,27 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr **Why:** Verify it's not your own infrastructure + - [ ] Check provider status page - [ ] Test provider directly - [ ] Check if other users reporting (Twitter, Discord) + ### Step 2: Assess Your Impact + - [ ] Which of your services affected? - [ ] What functionality is degraded/broken? - [ ] User-facing impact? + ### Step 3: Enable Fallback (if available) + - [ ] Switch to backup provider - [ ] Enable cached/degraded mode - [ ] Disable affected features gracefully + ## By Service Type @@ -131,9 +139,11 @@ Include: ## Monitoring the Outage + - [ ] Subscribe to provider status updates - [ ] Set reminder to check every 15-30 min - [ ] Monitor your own metrics for recovery + ## Recovery @@ -146,26 +156,32 @@ Include: ### Post-Outage + - [ ] Document timeline - [ ] Review if fallback worked - [ ] Assess if additional redundancy needed - [ ] Consider SLA review with provider + ## Escalation + - [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - contact provider support - [ ] [Decision Makers](../contacts#decision-makers) - if extended outage or no ETA + ## Prevention Reduce third-party dependency risk: + - [ ] Multiple RPC providers - [ ] Multi-region hosting - [ ] CDN with failover - [ ] Graceful degradation - [ ] Cached fallbacks where appropriate - [ ] Regular dependency review + ## Provider Contacts diff --git a/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx b/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx index 38ec3157..c7629280 100644 --- a/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -88,13 +88,17 @@ HH:MM UTC - ... ### Immediate + - [ ] [Action] @[Owner] - [ ] [Action] @[Owner] + ### Resolution + - [ ] [Action] @[Owner] - [ ] [Action] @[Owner] + ## Resolution Summary @@ -102,8 +106,10 @@ HH:MM UTC - ... ### Verification + - [ ] [Check 1] - [ ] [Check 2] + ## Communications Sent @@ -113,9 +119,11 @@ HH:MM UTC - ... ## Post-Incident + - [ ] Post-mortem scheduled for: [date] - [ ] [Post-mortem document](./post-mortem-template) created (save to your post-mortems folder) - [ ] Action items assigned + ## Links & Evidence diff --git a/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx b/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx index bffa908a..4671e33f 100644 --- a/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -135,9 +135,11 @@ See linked Incident Log for detailed timeline. Should we create or update a [runbook](../runbooks/overview) based on this incident? + - [ ] New runbook needed: [type] - [ ] Existing runbook to update: [which one] - [ ] No runbook changes needed + ## Detection diff --git a/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx b/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx index 046ee776..18fda912 100644 --- a/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx @@ -11,7 +11,7 @@ contributors: --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../../components' @@ -38,9 +38,11 @@ Copy this template to create runbooks for specific incident types. ### Symptoms + - [ ] Symptom 1 - [ ] Symptom 2 - [ ] Symptom 3 + ### Alerts @@ -75,9 +77,11 @@ If you see [X] but not [Y], it might be [different issue] instead. ### Key Questions + - [ ] What is the scope? - [ ] When did it start? - [ ] What changed recently? + ### Information to Gather @@ -112,16 +116,20 @@ If you see [X] but not [Y], it might be [different issue] instead. Escalate to [Contacts](../contacts) if: + - [ ] Mitigation doesn't work within [time] - [ ] Impact expands - [ ] [Condition] + ## Resolution Checklist + - [ ] Mitigation verified - [ ] Stakeholders notified - [ ] Timeline documented in [Incident Log](../templates/incident-log-template) - [ ] Post-mortem scheduled if warranted + ## Common Root Causes diff --git a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx index d663a773..541d3391 100644 --- a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx +++ b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx @@ -9,7 +9,7 @@ contributors: users: [SEAL] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -35,17 +35,22 @@ the security researchers. ### Perform Immediately + - [ ] Notify SEAL 911 Bot of the incident. Use this message template to get started. - [ ] Create a War Room with audio and share the invite link with trusted individuals. - [ ] Duplicate this document to allow collaboration and share the link in the War Room. - [ ] Review the Advice to Keep in Mind section. + ### Perform in Parallel by Role 1. **Assign Key Roles to War Room Members**: + - [ ] Assign members to specific roles. + 2. **Analysis**: + - [ ] Scope the impact of the attack. - [ ] Gather Transactions Involved. - [ ] Gather Affected Addresses. @@ -53,27 +58,34 @@ the security researchers. - [ ] Gather Attacker Information. - [ ] Investigate the issue and update the Issue Description. - [ ] Propose workable solutions. + 3. **Protocol actions**: + - [ ] Take immediate corrective/preventative actions to prevent further loss of funds. - [ ] Pause contracts if possible. - [ ] Execute pre-made defensive scripts. - [ ] Prioritize proposed solutions. - [ ] Validate and execute the solution. - [ ] Prepare monitoring alerts for situations that require future actions. + 4. **Web actions**: + - [ ] Disable deposits and/or withdrawals as needed in the web UI. - [ ] Enable front-end IP or Address blacklisting. - [ ] Create front-end for any user actions necessary (approval revoking, fund migrating, etc.). + 5. **Communications**: + - [ ] Identify social platforms that communications on the incident must be sent to. - [ ] Prepare messages for incident communication internally and externally. - [ ] Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols). - [ ] Notify block explorers (like Etherscan) for attacker address labeling. - [ ] Continuously monitor social media for users providing additional information that aids whitehat efforts. - [ ] Monitor War Room efforts and maintain the Event Timeline. + ### After all of the above is complete, consider Post Incident Actions @@ -196,9 +208,11 @@ executes the rescue via EIP-7702 delegation. The script also resets the authoriz ### When to Use It + - [ ] A wallet's private key is confirmed compromised and funds remain. - [ ] The rescue team has a safe destination wallet and the victim's private key. - [ ] Someone on the team can run Bash scripts with Foundry's `cast` installed. + ### Important Caveats diff --git a/docs/pages/multisig-for-protocols/implementation-checklist.mdx b/docs/pages/multisig-for-protocols/implementation-checklist.mdx index c3f12718..8839e74e 100644 --- a/docs/pages/multisig-for-protocols/implementation-checklist.mdx +++ b/docs/pages/multisig-for-protocols/implementation-checklist.mdx @@ -12,7 +12,7 @@ contributors: users: [pinalikefruit, engn33r] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -29,72 +29,90 @@ all applicable sections before beginning multisig operations. ### Planning & Setup + - [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification) - [ ] I have selected appropriate thresholds based on the classification guidance - [ ] I have identified and verified all signers for the multisig - [ ] I have deployed the multisig with correct configuration - [ ] I have set up required modules (eg. allowance module to rescue assets) + ### Documentation & Communication + - [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup) - [ ] I have tested emergency notification procedures - [ ] I have documented emergency contact information + ### Ongoing Management + - [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - [ ] I have verified all signers have completed training requirements - [ ] I understand signer rotation procedures for my multisig type + ## For Signers ### Hardware & Security Setup + - [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - [ ] I have set up my hardware wallet with proper firmware and PIN - [ ] I have created and tested backup hardware wallet with same seed - [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management) - [ ] I have created dedicated accounts for each multisig I'm signing for + ### Operational Readiness + - [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup) - [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) - [ ] I understand my multisig's classification and response time requirements - [ ] I have completed a test transaction with the multisig team + ### Transaction Verification + - [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources → Transaction Verification](/wallet-security/tools-and-resources#transaction-verification) - [ ] I understand how to verify transaction hashes before signing - [ ] I can decode and verify transaction details (amounts, recipients, contract calls) - [ ] I have practiced verifying both simple transfers and complex transactions + ### Emergency Preparedness + - [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - [ ] I have tested backup communication methods with my team - [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting) + ### Personal Security + - [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - [ ] I use dedicated devices or accounts for multisig operations when required - [ ] I have implemented travel security procedures appropriate for my risk level - [ ] I understand incident reporting procedures for security concerns + ### Compliance + - [ ] I have read and understand all sections of this security framework - [ ] I understand my specific role requirements based on multisig classification - [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding) - [ ] I commit to following these security procedures and reporting any deviations + ## Specialized Training by Use Case @@ -102,56 +120,71 @@ all applicable sections before beginning multisig operations. Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements): + - [ ] I understand 24/7 availability requirements - [ ] I have participated in emergency simulation drills - [ ] I know how to respond to emergency paging - [ ] I understand streamlined verification procedures for emergencies + ### Treasury Multisigs + - [ ] I understand allowance module configuration and purpose - [ ] I know governance rescue procedures - [ ] I understand financial reporting requirements + ### Smart Contract Control Multisigs + - [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration) - [ ] I know how to verify staged transactions - [ ] I understand higher threshold requirements for upgrades + ## Practical Skills Assessment ### Transaction Verification (EVM) + - [ ] I can successfully verify a Safe transaction hash using CLI tools - [ ] I can decode transaction calldata and identify recipients and amounts - [ ] I can identify risky transaction types and warnings - [ ] I can verify nested Safe transactions if applicable + ### Transaction Verification (Solana) + - [ ] I can analyze Solana transaction instruction data - [ ] I can convert hex values to decimal for amount verification - [ ] I can identify different transaction types (SOL transfer, token transfer, config changes) + ### Emergency Procedures + - [ ] I can access backup UIs and complete a transaction - [ ] I can contact team via backup communication channels - [ ] I know how to report key compromise immediately - [ ] I can execute identity verification procedures if needed + ### Tool Proficiency + - [ ] I am comfortable using my hardware wallet for signing - [ ] I can navigate backup block explorers - [ ] I can use alternative RPC endpoints - [ ] I understand how to manually simulate transactions + ## Documentation Review ### Required Reading Completed + - [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs - [ ] [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - Device security requirements - [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures @@ -159,39 +192,48 @@ Additional requirements from [Use Case Specific Requirements](/multisig-for-prot Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures - [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols - [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security + ### Role-Specific Documentation **For Administrators:** + - [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification) - [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - [ ] [Communication Setup](/multisig-for-protocols/communication-setup) - [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) + **For Specialized Use Cases:** + - [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements) - [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration) (if applicable) + ## Certification and Acknowledgment ### Training Completion + - [ ] I have completed all applicable training requirements - [ ] I have successfully demonstrated practical skills - [ ] I understand the security implications of my role - [ ] I acknowledge my responsibilities as a multisig participant + ### Ongoing Commitment + - [ ] I commit to following all security procedures outlined in this framework - [ ] I will report any security incidents or concerns promptly - [ ] I will participate in regular training updates and refreshers - [ ] I will maintain the required level of security for my role + ### Trainer Verification (if applicable) @@ -201,10 +243,12 @@ Trainer: _________________ Date: _________________ Trainee has demonstrated competency in: + - [ ] Transaction verification procedures - [ ] Emergency response protocols - [ ] Security best practices - [ ] Role-specific requirements + **Signature:** _________________ diff --git a/docs/pages/multisig-for-protocols/runbooks/emergency-pause.mdx b/docs/pages/multisig-for-protocols/runbooks/emergency-pause.mdx index 252e5908..f8f12944 100644 --- a/docs/pages/multisig-for-protocols/runbooks/emergency-pause.mdx +++ b/docs/pages/multisig-for-protocols/runbooks/emergency-pause.mdx @@ -10,7 +10,7 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -44,9 +44,11 @@ addresses, pause functions, emergency contacts, and communication channels. ### 1. Alert Team + - [ ] Send alert to emergency Signal group - [ ] Page signers via configured paging system - [ ] Notify the security contact + **Alert template**: @@ -59,10 +61,12 @@ Respond ASAP - <2hr SLA ### 2. Assess Situation + - [ ] Confirm threat is real (not false alarm) - [ ] Identify affected contracts or assets - [ ] Determine which pause function(s) to call - [ ] Estimate urgency + ### 3. Prepare Transaction @@ -91,15 +95,19 @@ Emergency signing follows abbreviated verification. ### Sign and Communicate + - [ ] Sign immediately after verification - [ ] Message: "Signed - [X/Y] - [your name]" - [ ] Stay available until executed + ### Execute + - [ ] Execute as soon as threshold is reached - [ ] Verify pause took effect (check contract state) - [ ] Communicate: "EXECUTED - pause confirmed" + ## Contract Reference @@ -113,22 +121,28 @@ Emergency signing follows abbreviated verification. ### Immediate (Within 1 hour) + - [ ] Confirm pause is effective - [ ] Document incident using [Incident Reporting](/multisig-for-protocols/incident-reporting) - [ ] Notify stakeholders + ### Short-term (Within 24 hours) + - [ ] Root cause analysis - [ ] Plan for resolution - [ ] Draft public communication if needed + ### Resolution + - [ ] Fix underlying issue - [ ] Test fix thoroughly - [ ] Plan unpause procedure - [ ] Execute unpause with full verification (not emergency process) + ## If Primary UI is Down diff --git a/docs/pages/multisig-for-protocols/runbooks/signer-rotation.mdx b/docs/pages/multisig-for-protocols/runbooks/signer-rotation.mdx index 04a2f973..14524f31 100644 --- a/docs/pages/multisig-for-protocols/runbooks/signer-rotation.mdx +++ b/docs/pages/multisig-for-protocols/runbooks/signer-rotation.mdx @@ -10,7 +10,7 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -40,11 +40,13 @@ addresses, signer requirements, and communication channels. ## Prerequisites + - [ ] Reason for change documented - [ ] New signer has completed [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) (if new) - [ ] New signer's address verified via signed message - [ ] Change maintains minimum signer count and threshold requirements - [ ] If reducing signers or threshold: justification documented and approved + ## Adding a Signer @@ -150,20 +152,24 @@ Can combine add and remove in a single transaction: After execution: + - [ ] Update registration or internal documentation with the new signer list - [ ] Update communication channel membership - [ ] Removed signer leaves communication channels - [ ] Test that the new signer can successfully sign a test transaction + ## Offboarding Checklist When removing a signer: + - [ ] Signer removed from multisig on-chain - [ ] Signer removed from communication channels - [ ] Documentation updated - [ ] Signer deleted local sensitive information - [ ] Any shared credentials rotated (if applicable) + **Timeline requirements**: diff --git a/docs/pages/multisig-for-protocols/runbooks/threshold-change.mdx b/docs/pages/multisig-for-protocols/runbooks/threshold-change.mdx index 048c26a3..17caa88a 100644 --- a/docs/pages/multisig-for-protocols/runbooks/threshold-change.mdx +++ b/docs/pages/multisig-for-protocols/runbooks/threshold-change.mdx @@ -10,7 +10,7 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -40,12 +40,14 @@ your organization's policies. ## Prerequisites + - [ ] Justification documented - [ ] New threshold meets policy requirements: - Minimum 50% of signers - Avoid `N of N` configurations - [ ] If decreasing: approval from security contact - [ ] All signers notified of change + ## Policy Requirements @@ -87,16 +89,20 @@ your organization's policies. ### 3. Sign and Execute + - [ ] Verify hash on hardware wallet - [ ] Sign immediately after verification - [ ] Message: "Signed - [X/Y] - [your name]" - [ ] Stay available until executed - [ ] Last signer executes once threshold is reached + ### 4. Verify + - [ ] Check Safe settings show new threshold - [ ] Test that the next transaction requires new threshold + ## Solana (Squads) Procedure @@ -119,22 +125,28 @@ your organization's policies. ### 3. Sign and Execute + - [ ] Verify proposal details on hardware wallet - [ ] Sign immediately after verification - [ ] Message: "Signed - [X/Y] - [your name]" - [ ] Stay available until executed - [ ] Last signer executes once threshold is reached + ### 4. Verify + - [ ] Check Squads settings show new threshold - [ ] Test that the next transaction requires new threshold + ## Post-Change + - [ ] Update registration or internal documentation with new threshold - [ ] Notify all signers of new threshold - [ ] Update any documentation referencing old threshold + ## Common Scenarios diff --git a/docs/pages/multisig-for-protocols/runbooks/token-transfer.mdx b/docs/pages/multisig-for-protocols/runbooks/token-transfer.mdx index 2e2d5bf6..57cea0e8 100644 --- a/docs/pages/multisig-for-protocols/runbooks/token-transfer.mdx +++ b/docs/pages/multisig-for-protocols/runbooks/token-transfer.mdx @@ -10,7 +10,7 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -38,9 +38,11 @@ Sending tokens (ETH, ERC20, SOL, SPL tokens) from a multisig to another address. ## Prerequisites + - [ ] Recipient address verified via independent source (not just chat message) - [ ] Amount confirmed - [ ] Reason for transfer documented or approved + ## EVM (Safe) Procedure @@ -86,16 +88,20 @@ Or use [OpenZeppelin Safe Utils](https://safe-utils.openzeppelin.com). ### 3. Sign + - [ ] Review transaction on hardware wallet - [ ] Verify message hash matches tool output - [ ] Sign - [ ] Communicate: "Verified and signed, X more needed" + ### 4. Execute + - [ ] Last signer clicks "Execute" (or designated executor) - [ ] Confirm transaction on-chain via block explorer - [ ] Communicate: "Executed - [tx hash]" + ## Solana (Squads) Procedure @@ -129,16 +135,20 @@ Or use [OpenZeppelin Safe Utils](https://safe-utils.openzeppelin.com). ### 3. Sign + - [ ] Click "Approve" - [ ] Verify hash in Squads UI matches Ledger display - [ ] Sign on Ledger - [ ] Communicate: "Verified and signed, X more needed" + ### 4. Execute + - [ ] Last signer executes - [ ] Verify on Solana Explorer - [ ] Communicate: "Executed - [tx signature]" + ## Verification Details diff --git a/docs/pages/multisig-for-protocols/setup-and-configuration.mdx b/docs/pages/multisig-for-protocols/setup-and-configuration.mdx index f51016d3..4cc80166 100644 --- a/docs/pages/multisig-for-protocols/setup-and-configuration.mdx +++ b/docs/pages/multisig-for-protocols/setup-and-configuration.mdx @@ -12,7 +12,7 @@ contributors: users: [pinalikefruit, engn33r] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -120,6 +120,7 @@ invariant is violated. ## Pre-Launch Checklist + - [ ] Safe deployed with correct threshold - [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process) - [ ] Allowance module configured (if required) @@ -127,6 +128,7 @@ invariant is violated. - [ ] All signers confirmed they can sign - [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction - [ ] Safe addresses documented for all networks + ### Practice on Testnet diff --git a/docs/pages/opsec/google/overview.mdx b/docs/pages/opsec/google/overview.mdx index 2ce9f388..c075e04e 100644 --- a/docs/pages/opsec/google/overview.mdx +++ b/docs/pages/opsec/google/overview.mdx @@ -12,7 +12,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../../components' @@ -42,6 +42,7 @@ These settings apply to your personal Google account. All team members and admin ### Account Security Checklist + - [Google Security Settings](https://myaccount.google.com/security): - [ ] Settings > Security > Skip passwords when possible > **Enabled** - *Skipping password entry allows you to renew logins in public places without having to type out your password or @@ -72,6 +73,7 @@ These settings apply to your personal Google account. All team members and admin - Publicly visible personal info can aid attackers in impersonating you. - [ ] Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary - [ ] **Birthday:** Consider making it private + --- @@ -79,6 +81,7 @@ These settings apply to your personal Google account. All team members and admin For a comprehensive security review, follow these steps from [Google Security](https://myaccount.google.com/security): + - [ ] "Your connection to third-party apps & Services" > Revoke all applications that should not be connected - [ ] "Log out of all unknown devices" - [ ] "Turn off" skip password when possible (below previous step) @@ -86,6 +89,7 @@ For a comprehensive security review, follow these steps from [Google Security](h - [ ] Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all. - [ ] Change your password after completing these steps - [ ] Note down your backup codes + > If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored > in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline. @@ -98,17 +102,21 @@ For those who are public figures or need heightened security, Google's **Advance considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account recovery more challenging. + - [ ] [Enroll in Advanced Protection Program](https://myaccount.google.com/advanced-protection/landing) + --- ### Best Practices & Ongoing Maintenance + - [ ] **Review Security Alerts:** Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes. - [ ] **Perform a Security Checkup:** Regularly visit [Google's Security Checkup](https://myaccount.google.com/security-checkup) to identify potential issues and resolve them. - [ ] **Consider** using identity **monitoring** apps like [Push Security](https://pushsecurity.com). + --- @@ -134,6 +142,7 @@ These settings and practices apply to Google Workspace administrators with eleva #### Rules and Notifications - [Rules](https://admin.google.com/ac/ax) > Enable notifications for security events + - [ ] "User's password changed" - [ ] "Suspicious login" - [ ] "User granted Admin privilege" @@ -141,9 +150,11 @@ These settings and practices apply to Google Workspace administrators with eleva - [ ] "Primary admin changed" - [ ] "Leaked password" - [ ] "Device compromised" [[1]](#1-security-alerts) + #### Security Settings + - [ ] Security > Overview > Less Secure Apps > **Disable access to less secure apps** - [ ] Security > Authentication > 2-Step Verification > **Allow users to turn on 2-Step Verification** - [ ] Enforcement > **On** @@ -156,9 +167,11 @@ These settings and practices apply to Google Workspace administrators with eleva - [ ] Security > Access and data control > Google Cloud session control > Reauthentication policy > **Require reauthentication** - [ ] Exempt Trusted apps > **Off** - [ ] Reauthentication frequency > **16** + #### Apps and Data Control + - [ ] Apps > Google Workspace > Drive and Docs > Sharing options > - [ ] Sharing outside of organization > **OFF** or **ALLOWLISTED DOMAINS** - [ ] Allow users in organization to receive files from users or shared drives outside of @@ -167,10 +180,12 @@ These settings and practices apply to Google Workspace administrators with eleva web content visible to anyone with the link > **Off** - [ ] Distributing content outside of organization > **No one** - [ ] Apps > Google Workspace > Settings for Google Chat > Service Settings > **OFF for everyone** + #### Gmail Security - Apps > Google Workspace > Settings for Gmail > + - [ ] Authenticate email > Set up **DKIM** with your DNS provider - **Safety >** - [ ] Attachments > **Enable** all protections and set to quarantine @@ -179,6 +194,7 @@ These settings and practices apply to Google Workspace administrators with eleva - [ ] Spoofing and authentication > **Enable** all and set to quarantine - [ ] **Protect against any unauthenticated emails** can be set to **Keep email in inbox and show warning** in order to prevent blocking external emails + #### Email Authentication diff --git a/docs/pages/opsec/secure-operating-systems.mdx b/docs/pages/opsec/secure-operating-systems.mdx index d796e091..759746ce 100644 --- a/docs/pages/opsec/secure-operating-systems.mdx +++ b/docs/pages/opsec/secure-operating-systems.mdx @@ -14,7 +14,7 @@ contributors: users: [mattaereal] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -119,6 +119,7 @@ strong sandboxing and exploit mitigations while maintaining Android app compatib ### Setup Recommendations + - [ ] Use a **dedicated Pixel device** for crypto operations (not your daily phone) - [ ] Create a **separate user profile** for wallet apps — keep it isolated from messaging and browsing - [ ] **Disable network access** for wallet apps that don't need it (GrapheneOS supports per-app @@ -126,6 +127,7 @@ strong sandboxing and exploit mitigations while maintaining Android app compatib - [ ] Enable **auto-reboot** after a period of inactivity to clear RAM - [ ] Use a **strong alphanumeric passcode**, not a PIN or pattern - [ ] Keep the device updated — GrapheneOS ships security patches within days of upstream releases + ### Limitations @@ -205,6 +207,7 @@ systems on practical day-to-day security at team scale. ### macOS + - [ ] Enable [FileVault](https://support.apple.com/guide/mac-help/protect-data-on-your-mac-with-filevault-mh11785/mac) full-disk encryption - [ ] Enable the built-in firewall (System Settings > Network > Firewall) @@ -212,9 +215,11 @@ systems on practical day-to-day security at team scale. - [ ] Use a non-admin account for daily work - [ ] Disable automatic login and require password on wake - [ ] Review and restrict app permissions (Full Disk Access, Accessibility, Input Monitoring) + ### Linux + - [ ] Enable full-disk encryption (LUKS) at install time - [ ] Use a distribution with timely security updates (Fedora, Debian Stable, Ubuntu LTS) - [ ] Enable a firewall (`ufw` or `firewalld`) @@ -222,15 +227,18 @@ systems on practical day-to-day security at team scale. applications - [ ] Disable SSH password authentication — use key-based only - [ ] Consider [Kicksecure](https://www.kicksecure.com/) as a hardened Debian derivative + ### Windows + - [ ] Enable BitLocker full-disk encryption - [ ] Keep Windows and drivers fully updated - [ ] Use Microsoft Defender with tamper protection enabled - [ ] Use a standard user account for daily work - [ ] Disable or restrict unnecessary remote access services - [ ] Review browser extensions and installed applications regularly + ## Further Reading diff --git a/docs/pages/safe-harbor/self-checklist.mdx b/docs/pages/safe-harbor/self-checklist.mdx index e65d1598..9e3ad9ee 100644 --- a/docs/pages/safe-harbor/self-checklist.mdx +++ b/docs/pages/safe-harbor/self-checklist.mdx @@ -11,7 +11,7 @@ contributors: users: [dickson] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -26,6 +26,7 @@ protocol. ## Can Safe Harbor Help Your Protocol? + - [ ] **Do you hold user funds in smart contracts?** Without Safe Harbor, whitehats who could save your users' funds might hesitate to act due to legal uncertainty around unauthorized access. - [ ] **Do you want whitehats to help during active attacks?** Safe Harbor gives ethical hackers legal protection to @@ -34,6 +35,7 @@ intervene immediately, before attackers can drain your protocol. bounty can't cover - live attacks happening right now when disclosure timelines don't matter. - [ ] **Do you want to increase the odds of recovering funds?** Safe Harbor encourages rescue attempts by trusted whitehats. + If you checked any of the above - you can benefit from adopting our Safe Harbor. diff --git a/docs/pages/supply-chain/incident-response-supply-chain.mdx b/docs/pages/supply-chain/incident-response-supply-chain.mdx index 423ca210..996b3bae 100644 --- a/docs/pages/supply-chain/incident-response-supply-chain.mdx +++ b/docs/pages/supply-chain/incident-response-supply-chain.mdx @@ -10,7 +10,7 @@ contributors: users: [scode2277] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -139,6 +139,7 @@ Once the immediate threat is contained: 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. @@ -149,6 +150,7 @@ When a supply chain compromise is reported: - [ ] 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 diff --git a/docs/pages/wallet-security/smart-contract-interaction-security.mdx b/docs/pages/wallet-security/smart-contract-interaction-security.mdx index 23768086..64ac581e 100644 --- a/docs/pages/wallet-security/smart-contract-interaction-security.mdx +++ b/docs/pages/wallet-security/smart-contract-interaction-security.mdx @@ -13,7 +13,7 @@ contributors: users: [] --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' @@ -114,6 +114,7 @@ in Microsoft threat research. ## Quick Reference Checklist + - [ ] **Verify the contract address** — Cross-reference against official docs and block explorer labels (see [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions)) @@ -124,6 +125,7 @@ in Microsoft threat research. - [ ] **Read what you are signing** — Inspect EIP-712 domains, types, and values. If you don't understand it, don't sign it. - [ ] **Use MEV protection for DEX trades** — Route through Flashbots Protect or MEV Blocker. + --- From 9517c4a7e47db220b1e91a8d575401707e0590e2 Mon Sep 17 00:00:00 2001 From: Sara Russo Date: Mon, 18 May 2026 15:47:41 +0200 Subject: [PATCH 2/3] Add checklist guidance to contributing guidelines --- docs/pages/config/template.mdx | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/docs/pages/config/template.mdx b/docs/pages/config/template.mdx index ca4bbe27..6cd63f6a 100644 --- a/docs/pages/config/template.mdx +++ b/docs/pages/config/template.mdx @@ -115,7 +115,8 @@ contributors: docs/pages///.mdx, add one more '../' so the import becomes '../../../../components'. */} -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' +{/* Add Checklist to the import above only if your page uses interactive checklists. */} @@ -163,7 +164,22 @@ Use ### subsections within each one as needed. Common formats to mix and match within a section: - **Walkthrough**: numbered steps, top to bottom. Use when order matters. -- **Checklist**: bullet points the reader can tick. Use when order does not matter. +- **Checklist**: action items the reader can tick off. Use when order does not matter. + Use the `` component — never plain `- [ ]` syntax, which renders as a static, + non-interactive checkbox. Each block needs a unique `id` (kebab-case) per page: + + ```mdx + + - [ ] First item + - [ ] Second item + - Descriptive sub-bullet (no checkbox, renders as a bullet) + + ``` + + Rules: `id` values must be unique within the page. Do not use `> blockquote` syntax + inside a `` block (use `- _Note: ..._` instead). Keep nesting shallow + (avoid 5+ levels). See [`guides/account-management/github.mdx`](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/guides/account-management/github.mdx) + for a full worked example. - **Decision tree or matrix**: table or branching guide. Use when the right answer depends on the reader's situation. - **Plain explanation**: paragraphs. Use when the content is conceptual or From db0d88b0371ca0b301210e7c3923e0ae723e6074 Mon Sep 17 00:00:00 2001 From: Sara Russo Date: Mon, 18 May 2026 15:53:10 +0200 Subject: [PATCH 3/3] fix build error by removing block comment --- docs/pages/config/template.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/pages/config/template.mdx b/docs/pages/config/template.mdx index 6cd63f6a..951ce520 100644 --- a/docs/pages/config/template.mdx +++ b/docs/pages/config/template.mdx @@ -114,9 +114,11 @@ contributors: framework folder). If your page sits one level deeper, for example docs/pages///.mdx, add one more '../' so the import becomes '../../../../components'. + + If your page uses interactive checklists, add Checklist to the import: + import { ..., Checklist } from '../../../components' */} -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Checklist } from '../../../components' -{/* Add Checklist to the import above only if your page uses interactive checklists. */} +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components'