Web3 application penetration testing: Scope Creep Traps and How to Avoid Them

A Practical Guide for Scoping Web3 Pentests Without Burning Time or Budget

Looking to nail down your Web3 pentests? You’ve come to the right place! Let’s dive into the 12 most common traps that can cause scope creep, whether you're dealing with L1/L2, AA/4337, bridges, oracles, MEV, or supply chain issues. We’ll give you some solid acceptance criteria, examples, and checklists to keep everything on track.

Common Scope-Creep Traps

1. Undefined Objectives
   You gotta know what you’re after. Set clear goals to keep your team on the right path.
2. Vague Requirements
   Avoid confusion by being specific about what you're testing. Clarity is key!
3. Inadequate Stakeholder Engagement
   Get everyone who's involved on the same page early on. Regular check-ins can save you from surprises later.
4. Complex Systems
   Don’t bite off more than you can chew. Break down complex systems into manageable parts.
5. Overlooking Dependencies
   Know what relies on what. Mapping out dependencies can help you spot potential pitfalls.
6. Ignoring Past Findings
   Learn from previous tests. Review past reports to inform your current scope.
7. Last-Minute Changes
   Try to minimize changes once the scope is set. If something comes up, assess the impact carefully before proceeding.
8. Overestimating Resources
   Be realistic about what your team can handle. Avoid stretching your resources too thin.
9. Assuming You Know Everything
   No one has all the answers. Encourage team members to share their insights and expertise.
10. Poor Documentation
    Keep track of everything. Good documentation can clarify the scope and prevent misunderstandings.
11. Ignoring Regulations
    Stay updated on compliance and regulations relevant to your project. Don't let legal issues derail your efforts.
12. Failure to Review
    Before kicking off, conduct a final review of the scope with all stakeholders. This last check can catch any lingering issues.

Concrete Acceptance Criteria

• Clear Objectives: Clearly defined goals for each testing phase.
• Documented Requirements: A detailed list of what will and won’t be tested.
• Stakeholder Sign-off: A handshake (or digital equivalent) from all involved parties before moving forward.
• Defined Timelines: Specific deadlines for each segment of the project.
• Regular Updates: Scheduled check-ins to discuss progress and any changes needed.

Examples and Checklists

Example Objective

• Objective: Assess the security of smart contracts deployed on the XYZ blockchain.

Example Checklist

• Define the scope of testing.
• Gather requirements from stakeholders.
• Map dependencies between components.
• Review past pentest reports for insights.
• Obtain final sign-off before starting.

By keeping these considerations in mind, you can set up a Web3 pentest that stays within budget and on schedule. Good luck out there!

Who this is for

Decision-makers and security heads at startups and established companies who are gearing up for a Web3 security project can be working with either their in-house teams or outside vendors. This could involve audits, contests, or penetration tests.

---

Why Web3 pentests are uniquely vulnerable to scope creep

In Web3, figuring out "the app" is a bit like chasing a moving target. You've got on-chain logic scattered across different networks, and then there are off-chain services like relayers, bundlers, and oracles. Not to mention those cross-chain bridges, wallet libraries, and the ever-evolving L2 rollup infrastructure. It can get pretty wild!

And let’s not forget the stakes - missing out on something important can be costly. Just in 2024 alone, hundreds of millions were lost to hacks and rug pulls, with Ethereum and BNB Chain taking the brunt of it. You can read more about it here.

At the same time, the security baseline is evolving pretty quickly. OWASP just dropped their Smart Contract Top 10, which now includes contemporary DeFi risks such as price oracle manipulation and exploits stemming from flash loans. Make sure your scope takes this updated risk landscape into account--not just those old-school SWC checks. (scs.owasp.org)

Here are the 12 common traps that can lead to Web3 pentest scopes either expanding too much or missing key areas. We’ll also share some tips on how to steer clear of these pitfalls.

---

Trap 1 -- L2 finality and “training wheels” are hand‑waved

What’s out of scope:

• Fault/fraud proofs (Are they live? Who can challenge them? What’s the challenge period?).
• Forced transaction inclusion when the sequencer is down.
• Security council powers and upgrade processes that could sidestep “trustless” withdrawals.

Why It Matters:

• In 2024, OP Stack chains rolled out permissionless fault proofs in what they call “Stage 1”. But here's the kicker: they still have a Security Council that can step in when needed. So, if your protocol is leaning on L2 withdrawals or finality guarantees, be aware that your security assumptions could shift overnight--no testing those control planes needed. Check it out here: (cointelegraph.com).
• The whole deal with forced-inclusion semantics--like timing, gas caps, and the “sequencer window”--can really shake things up when it comes to censorship resistance and emergency exits. Dive into the details at (docs.optimism.io).

How to Scope It Right

• Start by laying out the targeted networks and their current decentralization stage along with their proof status. For example, you might say something like, “Base Mainnet, Stage 1 with permissionless fault proofs set for Oct 2024.” (theblock.co)
• Don’t forget to add acceptance tests! You should cover things like forced L2 deposit inclusion through the L1 portal and how the system behaves during different downtime windows: under 30 minutes, between 30 minutes and 12 hours, and over 12 hours. (docs.optimism.io)
• Finally, make sure to mention whether governance multisigs or security councils that could pause or upgrade rollup contracts are in the scope for simulating adverse changes. This includes stuff like timelocks and notice periods. (coindesk.com)

---

Trap 2 -- Account Abstraction (ERC‑4337) gets lumped into “wallet testing”

What’s going out of scope:

• EntryPoint version and configuration.
• Bundler simulation guarantees.
• Paymaster griefing/abuse and those tricky signature packing edge cases.

Why it matters:

• There have been real-life incidents and research highlighting some weaknesses in signature/packing and even cases of paymaster abuse. This usually happens when developers stray from the original specifications or lean too much on off-chain packing. You can read more about it here.
• The AA spec has built-in protections against griefing and sets specific validation rules that need thorough deterministic testing. If you're curious, check out the details here.

How to Scope it Right:

• Make sure to pin down the EntryPoint version(s), target chains, and types of paymasters you'll be working with, such as verifying paymaster or ERC‑20 paymaster. Also, don't forget to test for packed UserOperation hashing equivalence, both between signers and during on-chain validation. You can check out more on this here.
• Set clear acceptance criteria for bundler simulations. This means rejecting UserOps that go over gas limits or that fail non-deterministic checks. And definitely test for griefing by simulating replays and calls that could get reverted. More details can be found here.
• If you're leaning on community reference implementations, be specific about which repositories and commits you're covering. You can find additional info here.

---

Trap 3 -- “Bridge in the middle” is waved away as a third party

What’s out of scope:

• Messaging and verification processes on every connected chain, as well as guardians, validators, and the program constraints that come with them.
• Rate limits and governance powers, like the ability to pause or upgrade bridge contracts.
• Cross-chain replay and those tricky partial failure scenarios.

Why It Matters:

• Understanding scope boundaries is crucial because it helps you identify “extractable TVL” design flaws rather than letting them slip through the cracks. Well-established bug bounties clearly outline specific assets, chain components, and what’s off-limits; your penetration test should be just as detailed. Check out more about it here.

How to Scope It Right

• List out each bridge or messaging stack you rely on and clarify what you're testing: is it just “our integration,” “our integration plus bridge contracts on chain X,” or something more comprehensive like “end-to-end including guardians and validators”? You can take inspiration from the “Assets in Scope” and “Impacts in Scope” tables from bounties. Check it out here: immunefi.com.
• Make sure to follow the rules on prohibited activities--like no messing around with destructive tests on mainnet; stick to using local forks instead. Also, it’s a good idea to ask for proof of concepts (POCs) on those forked networks. More info can be found at immunefi.com.
• When it comes to understanding risks, get everyone on the same page with a bridge risk taxonomy. Think about things like native verification versus external validators versus optimistic bridges, and tailor your testing accordingly. You can read more about it at forum.l2beat.com.

---

Trap 4 -- Oracle risk is treated as “read-only”

What’s not included:

• Heartbeat and deviation thresholds, along with staleness checks.
• Pricing that takes confidence intervals into account, plus adversarial selection.
• Handling multi-feed composition drift.

Why it matters:

• Chainlink feeds refresh based on deviations or heartbeat signals, but stale data and variations across chains can mess with some fundamental assumptions. Pyth takes it a step further by showing confidence intervals, which can help in making more cautious valuations and settlement strategies. These behaviors are something we can actually test out. (docs.chain.link)

How to Scope It Right:

• Make sure to include invariant tests for “price freshness.” You can do this by using updatedAt/round timestamps from Chainlink or setting up “no older than” guards from Pyth. Don’t forget to outline failure actions as well! (docs.chain.link)
• When it comes to derivatives and lending, it's super important to clarify how you’re using confidence intervals. For instance, you might opt for μ + σ when assessing liabilities. Plus, be sure to set thresholds that will trigger pauses if things get a little too wild. (docs.pyth.network)
• Don’t skimp on the details! Clearly state the precise feeds you’re working with (think addresses and networks), along with the expected heartbeat and deviation to measure against. Remember, it’s a no-no to assume that mainnet values are the same across different chains. (data.chain.link)

---

Trap 5 -- Upgradeability is “just OZ proxies”

What we're not covering:

• The differences between UUPS, Transparent, and Beacon.
• ERC‑1967 slots, proxiable UUID checks, and the non‑UUPS upgrade lock-in.
• Timelock coverage and testing for governance execution.

Why it matters:

• Getting upgrades wrong can really mess things up, like causing proxies to fail or ditching important safety checks. The security of upgrades isn’t just about saying “we use OpenZeppelin”; it actually hinges on the upgrade pattern and who has access control. Check out more info here.

How to Scope It Right:

• State Upgrade Patterns and Test Cases: Make sure to reject any non-UUPS implementations. You should also check for the proxiableUUID and simulate some admin mishaps--like making direct calls to the implementation--to ensure that onlyProxy() is working as it should. Get all the details here.
• TimelockController Behaviors: Don't forget to include the behaviors of the TimelockController in your scope. This means checking out the minimum delays, setting up the proposer/executor roles, and making sure the user exit windows are linked to the timelocks. You can dive deeper into this here.

---

Trap 6 -- MEV/front‑running is filed under “out of scope mempool”

What Goes Out of Scope

• Route-level sandwich risk for swaps/mints.
• Private order flow policies and Protect RPC behavior.
• Refunds and delivery guarantees for private transactions.

Why it matters:

• In a lot of protocols, what we often call an “exploit” is really just a sneaky way to make money through reordering, rather than an actual bug. If your user experience relies on private submission (like with Flashbots Protect), you definitely want to put it through its paces. Make sure to test everything--including defaults, rate limits, and what happens if private inclusion doesn’t work. Check out the details here.

How to Scope It Right

• First off, decide if you're going to use private RPC in your tests. Make sure to pin down your Protect settings like builders, retries, and mempool fallback. And don't forget to specify your acceptance criteria: “no on-chain reveal if revert,” “retry N blocks,” and “status observable via Protect API.” You can check out the details in the Protect settings guide.
• Also, consider adding some simulated sandwich attempts on forks compared to private-path submissions to really test those mitigations. For more info, head over to the Flashbots overview.

---

Trap 7 -- Supply chain risks are “DevOps’ problem”

What’s Out of Scope:

• The integrity of packages related to wallet connectors and SDKs.
• Build provenance and any associated attestations.
• Release controls specifically for libraries that handle security-sensitive functions.

Why it matters:

• Back in December 2023, there was a pretty alarming compromise with the Ledger Connect Kit. It ended up injecting a wallet drainer through a popular npm package. Any dapps that were using it faced issues until they managed to upgrade--classic case of a scope leak in “someone else’s library.” You can read more about it here.
• On the flip side, modern frameworks like SLSA are stepping up the game. They outline practical levels for build provenance and have some hardened builders in place. This means you can actually require them in your Statement of Work (SoW). Check out the details on their site here.

How to Scope It Right

• Keep your supply chain controls in check: make sure you get those signed releases or SLSA Build L2+ attestations for any crucial off-chain stuff like SDKs, connectors, and relayers. And don't forget to run some simulated dependency downgrade or poison tests in your staging environment. You can find more about this over at slsa.dev.
• Make sure to document your dependency pins and update your playbooks regularly. It's super important to include rollback testing for any packages that might get compromised. Check out the details on this from ledger.com.

---

Trap 8 -- “Runtime security” is left to ops, not tested

What’s out of scope:

• Keeping an eye on admin actions like pausing, minting, and upgrade queues on the blockchain.
• Automatic responses (like pausing, limited killswitches) and how reliable alerts are.

Why it matters:

• It's important to check if your monitors are capable of catching critical events and if the responses (like pauses and role revocations) are functioning as intended. With OpenZeppelin shifting towards an open-source Monitor/Relayer model and planning to phase out its Defender SaaS by July 1, 2026, teams really need to take charge of their runtime stack. For more details, check out the full post on OpenZeppelin's blog.

How to Scope It Right:

• Make sure to include monitors in your scope. This means you’ll want to define event filters, like Timelock CallScheduled, role grants, and Pausable toggles. Also, think about your alert routes and “break-glass” Actions. Don't forget to validate those alert-to-action SLOs on testnets or forks. Check out the details in the OpenZeppelin docs!

---

Trap 9 -- Contest vs. audit vs. pentest: mismatched expectations

What gets tossed out of scope:

• Commit freezes, scope differences, and mitigation reviews.
• Repo readiness (including documentation, threat models, and test coverage).
• Off-chain components (like APIs, bots, and UIs) in code-only contests.

Why it matters:

• When it comes to contest platforms like Sherlock and Code4rena, they really focus on covering a wide range of code snapshots quickly. However, this can lead to overlooking integrated behaviors unless they’re specifically targeted and supported by thorough mitigation reviews. You can check out more about it here.

How to Scope It Right

• Make a choice early on: will it be a contest for code diff coverage with a follow-up on any mitigation, or are we diving deep into a full-on pentest for off-chain infrastructure? Don’t forget to get scouts or pre-audit scoping when you can to ensure the Statement of Work (SoW) feels realistic. Check out more about it at code4rena.dev.

---

Trap 10 -- “Tools = coverage” (SWC-only checklists)

What we’re leaving behind:

• Modern vulnerability types like oracle manipulation, AA griefing, and bridge logic.
• The fact that static and dynamic tools can overlook actual bugs in the wild if they don’t have invariants and formal rules to guide them.

Why it matters:

• The SWC registry isn't being actively maintained anymore, so it’s a good idea to lean on contemporary standards like OWASP SCSVS and EthTrust. It’s also smart to stack tools that include invariants and properties. There’s evidence out there showing that tools can really fall short when dealing with actual code unless they have realistic datasets to work with. (github.com)

How to Scope it Right

• Requirements: Make sure you include Slither for static analysis, Echidna for property fuzzing, and use Foundry invariants alongside formal specs from Certora for those high-risk modules--focusing on the specific properties you need to prove. You can read more about it here.

---

Trap 11 -- “Mainnet fork” is unspecified

What’s not included:

• The choice of which block to fork, the specific RPC, and the little quirks that come with each chain.
• Any issues related to impersonation and those pesky rate limits that can mess with reproducibility.

Why it Matters

• Reproducible forks rely on pinned block numbers and dependable archive RPCs. Just a heads up: defaults can change how tests behave from one run to another. Check it out here: (hardhat.org)

How to Scope It Right

• Make sure to pin per-test forks (like network, block, RPC URL); jot down impersonation accounts; and double-check limits (like Flashbots Protect RPC read limits) for those integrated tests. You can find more details over at v2.hardhat.org.

---

Trap 12 -- “Governance is out of scope”

What Goes Out of Scope:

• Timelock windows, proposal flows, and testing for those tricky edge cases.
• Emergency powers like pausing or upgrading, as well as exit windows for users.

Why it matters:

• Governance is your final control surface in production. To properly test it, you need to simulate proposals, manage queuing, handle execution, and manage user exits all within set timeframes. Check out more about this here.

How to Get It Right:

• Make sure to include governance E2E tests in your scope. This means you'll want to simulate proposals that can upgrade implementations, switch up oracle feeds, or toggle the Pausable feature. It’s crucial to check that minimum delays are enforced and that alerts actually trigger when they should. You can find more info here: docs.openzeppelin.com.

---

A copy‑paste scoping template that prevents scope creep

Feel free to kick off your SoW/RFP with this as a foundation.

• Networks and Stages
  • Networks: We've got Ethereum Mainnet (block X), Arbitrum One (block Y), Base (Stage 1 as of 2024‑10), and OP Mainnet (Stage 1 as of 2024‑06). Check out more about it on Cointelegraph.
  • Forked Testing: Pin blocks and RPCs per test suite (Hardhat/Anvil). For more info, visit Hardhat.
• On‑Chain Targets (Exact)
  • We'll need contract addresses, ABIs, and those proxy patterns (UUPS/Transparent/Beacon), plus commit hashes for the code we're reviewing. Here’s an example format inspired by public audits that pin commits and folder scopes. To dive deeper, check out OpenZeppelin.
• Cross‑Chain and Bridges
  • Make sure to include the bridges used, the chains involved, and the various components: “integration only,” “messaging contracts on X,” or “guardians/validators.” It’ll help to follow the “Impacts in Scope” table style. More info can be found at Immunefi.
• Account Abstraction (If Any)
  • We’ll need details on the EntryPoint version, the bundler environment, paymaster type, sponsorship rules, and any griefing protections to test. More on that at ERC 4337 Docs.
• Oracles
  • Don't forget to include the Chainlink feed addresses with their expected heartbeat/deviation; also list Pyth feeds with confidence thresholds and staleness windows, along with required fallback/pausing behavior. Check out Chainlink Docs for the scoop.
• MEV and Transaction Delivery
  • We need to talk about the use of private RPC, builder share, retries, and refunds. Be clear about the expected outcomes for revert behavior and on‑chain exposure. For more details, swing by Flashbots Docs.
• Governance and Upgrades
  • Keep an eye on timelock delays, proposer/executor roles, and emergency pause tests; also check UUPS upgrade requirements (proxiableUUID, onlyProxy). You can learn more from OpenZeppelin.
• Runtime Security
  • We’ll need to set up monitoring rules (events/functions), alert channels, and test automated actions on testnet or fork. For more, head over to OpenZeppelin Defender Docs.
• Supply Chain and Build Provenance
  • Make sure to require SLSA Build L2+ attestations or something equally robust for critical off‑chain artifacts; don’t forget to verify lockfiles and release signing. More on that at SLSA.
• Out of Scope (Explicit)
  • Just to clarify, this includes things like mainnet destructive testing, third-party SaaS backends unless they're listed, and off-protocol UIs--basically sticking to the bounty “Prohibited Activities” guidelines. Check out more at Immunefi.
• Deliverables
  • We’re looking for reproducible forks, PoCs, invariant/property specs, formal verification rules for those critical modules, and a mitigation review window.

---

Two concrete example scopes

1) DeFi Lending on an OP Stack L2 with Chainlink Oracles and UUPS Upgrades

• What’s Included: We’re diving into lending markets, using UUPS proxies, Timelock governance, and those handy Chainlink ETH/USD and WBTC/USD feeds. Plus, we’ll be testing some sequencer downtime scenarios where L1 deposits are forced into L2. We'll be working with Stage‑1 fault proof assumptions, and yes, we’ll be rejecting any non-UUPS upgrades while ensuring the proxiableUUID checks out. Don’t forget, we’re enforcing governance delays and keeping an eye out for alerts on CallScheduled and Upgraded events. (optimism.io)
• Acceptance Criteria: We’ll be on the lookout for stale price detection through updatedAt, making sure to hit pause if the heartbeat misses a beat. Forced inclusions will be accepted once the window closes, and the timelock will need a minimum delay of at least the specified hours. (docs.chain.link)

2) ERC‑4337 Smart Account + ERC‑20 Paymaster on Base

• What’s included: We’re looking at EntryPoint versions v0.6+/v0.7+/v0.8.x (pin), VerifyingPaymaster, simulating the bundler, ensuring signature packing is equivalent, and implementing griefing resistance (like handling invalid operations, replay attacks, and sponsorship policies). Also, don’t forget the tests using the private submission path via Protect RPC that makes for a gasless user experience! You can find more details here.
• What we need for acceptance: We’ve got to make sure that any changes to initCode or callData after a signature are caught; we also need a deterministic validatePaymasterUserOp. The bundler should reject operations that go over the gas limits, and we need to keep any reverted ops off-chain with that private path. More insights can be found here.

---

Emerging best practices to bake into every 2025 scope

• Start with the OWASP Smart Contract Top 10 (2025) as your main coverage guide--don’t just stick to SWC. (scs.owasp.org)
• Make sure to connect contest or audit results to SCSVS controls and ask for a thorough review of any mitigations--this is especially important after public contests. (scs.owasp.org)
• View bridges as key dependencies, outlining their impact scopes and multi-chain proof-of-concepts. (immunefi.com)
• Assume that AA stacks fall within scope whenever users aren’t holding native gas; be sure to test paymaster economics and griefing protections. (docs.erc4337.io)
• Ask for SLSA-style attestations for wallet connectors and SDKs, and don’t forget to include dependency compromise drills in your security runbooks. (slsa.dev)
• Get your L2 assumptions in line with the current level of decentralization and proof systems, and take some time to test forced inclusion and withdrawal paths. (cointelegraph.com)

---

Tooling that supports strong scoping (and how to require it)

• Static analysis: Check out Slither for the baseline. It’s a top choice for diving deep into smart contracts. (blog.trailofbits.com)
• Property fuzzing: Give Echidna a go! Also, Foundry offers fuzzing and invariant checks with pinned blocks and can replay counterexamples. It’s super handy. (blog.trailofbits.com)
• Formal verification: For keeping your rules in check--like debt accounting, liquidation invariants, and governance correctness--Certora Prover is your best bet. (docs.certora.com)
• Private submission & MEV hygiene: Don't forget about Flashbots Protect RPC. You can configure it explicitly for your needs, which is super useful. (docs.flashbots.net)

Make sure to include these in the SoW as necessary methodologies and deliverables--not just “nice to have” tools.

---

Final checklist: questions that kill scope creep early

• What specific commits, addresses, and networks are you putting to the test? Are the forks locked in?
• Which rollup proof or upgrade model are you working with? Have you tested forced-inclusion and challenge windows?
• Are the AA components like EntryPoint, bundlers, and paymasters getting the love they deserve with deterministic validation tests?
• What about oracles and feeds? Are we covering them with checks for staleness and confidence-aware invariants?
• Which bridges and messaging layers are we focusing on, which chains are involved, and what impacts have we considered?
• Are we testing governance and upgrades from start to finish, including timelock delays and alert setups?
• Do we have runtime monitoring and break-glass procedures in place for testing?
• Lastly, are we verifying supply chain protections, like attestations and signed releases?

If you can nail down these answers, you'll steer clear of about 80% of the time and cost overruns we often see in Web3 pentests.

---

How 7Block Labs runs “scope‑tight” Web3 pentests

• Scope Gating Workshop: Let’s spend 90 minutes working with that template, confirming our dependencies, and figuring out what’s out-of-scope but needs a solid business reason to be excluded.
• Release Candidate Pinning: This is where we freeze the code and set our commit hash(es). We’ll create a testable “audit kit” to fill in any documentation gaps before launch day. (This is similar to the commit-pinned scopes we use in public audits.) (openzeppelin.com)
• Multi-modal Testing: We’re talking static analysis, property fuzzing, invariants on forks, and some formal rules for those high-risk modules; plus, we can throw in optional private-orderflow path tests. (blog.trailofbits.com)
• Mitigation Review + Runtime Drill: Time for a fix-review with the same crew, and we’ll also run a tabletop session to monitor our runtime alerts and validate the runbooks. (docs.openzeppelin.com)

Looking for a scoping session that fits your tech stack--whether that's L2s, bridges, AA, or oracles? We'd love to set one up with your engineering and product teams!

---

References (selected)

• Check out the OWASP Smart Contract Top 10 (2025) for the latest security insights on smart contracts. (scs.owasp.org)
• Take a look at the 2024 loss trends and targets to understand how crypto hacks and rug pulls resulted in a staggering $473 million in losses! (coindesk.com)
• Curious about OP Stack? Here’s the scoop on fault proofs and stages that you’ll want to know about. (cointelegraph.com)
• When it comes to forced transactions on OP Stack, here’s a handy guide to get you up to speed. (docs.optimism.io)
• Interested in the latest on Wormhole bounty scope patterns? Dive into the details here. (immunefi.com)
• Learn about the potential risks and protections of ERC‑4337 to keep your projects secure. (alchemy.com)
• For those using UUPS/1967 proxies, make sure to check out how to enhance your safety. (docs.openzeppelin.com)
• Don’t miss the best practices for Chainlink and Pyth oracles--they’re crucial for getting reliable data feeds. (docs.chain.link)
• Discover what’s up with Flashbots Protect RPC behavior to keep your transactions secure. (docs.flashbots.net)
• Just a heads up about the Ledger Connect Kit supply-chain incident--you'll want to know what went down. (ledger.com)
• Get informed about the SLSA supply chain levels, which could be a game changer for your security strategy. (slsa.dev)
• If you’re into development, you’ll want to check out the Foundry/Hardhat forking guidance. It’s super helpful for those looking to fork the mainnet. (hardhat.org)
• Lastly, take note of the OpenZeppelin Defender sunset--find out what this means for the OSS Monitor and Relayer. (blog.openzeppelin.com)

---