Ask a Security Firm What Your Next Upgrade Breaks Before You Hire It

The real test is not whether a firm can read today's contracts. It is whether it can explain how tomorrow's upgrade changes assumptions in code that looks untouched.

Establish the problem with technical depth

Most teams still choose a smart contract security firm by asking the wrong questions. Who has the best logo? Who audited the hot protocol everyone references? Who can deliver before the token launch or the board meeting? Those questions are understandable. Founders are under pressure to show diligence. CTOs are under pressure to reduce risk quickly. But none of that gets to the real issue.

The real issue is whether the firm can tell you how the next change will alter risk, including in contracts that appear untouched. That is the difference between hiring a reviewer and hiring a receipt generator. A live protocol almost never fails because one engineer forgot that reentrancy exists. It fails because a new permission, integration, upgrade, or feature quietly changes what old code is now allowed to trust.

Penpie's September 2024 exploit is the cleanest case study. In its official post-mortem, Penpie said an attacker stole 11,113.6 ETH, about $27.35 million, on September 3, 2024. The root cause was a reentrancy protection weakness in PendleStakingBaseUpg::batchHarvestMarketRewards(), exploited through a malicious SY contract registered as a fake Pendle market. The most important detail came later in the same write-up. Penpie said that when it introduced permissionless pool registration in May 2024, that feature was audited by AstraSec, but PendleStakingBaseUpg itself was not included in scope because it had not undergone significant changes after the initial audit.

That is the whole procurement lesson in one paragraph. The dangerous contract was not necessarily the contract that changed most visibly. The dangerous assumption was that the new feature's review scope and the old contract's risk surface were still aligned. They were not. The protocol changed what kinds of counterparties could reach the old logic, and the old logic became newly unsafe.

Nomad's official root cause analysis exposed the same problem from the upgrade side. Nomad said an implementation bug in the Replica contract allowed forged messages to pass authentication, and that the relevant code was introduced in a smart contract upgrade on June 21, 2022. The failure depended on how initialization and root confirmation interacted, not just on one obviously reckless line standing alone. In other words, a routine upgrade changed the meaning of a safety check.

That is why this matters to both investors and builders. Investors are not really underwriting a code snapshot. They are underwriting how the team changes production truth. Engineers are not hiring a firm to admire the current repository. They are hiring one to explain which assumptions the next upgrade, integration, or role change can quietly invalidate.

The mechanism, the mistake, the misunderstanding

Upgrades and feature changes usually break systems in three ways: assumption drift, scope drift, and authority drift.

Assumption drift is what Penpie ran into. A contract that once only had to tolerate trusted market registration was suddenly reachable through a permissionless path. The code may have looked mostly familiar. The assumptions around who could touch it and in what sequence had changed. That is exactly the sort of thing attackers exploit and point-in-time scope definitions miss.

Scope drift is the quieter procurement mistake. Teams and vendors alike tend to treat audit scope like a file list. If a contract did not change much, they assume it did not need the same scrutiny. That is often false. The better question is which contracts have their threat model changed by the new release. OpenZeppelin's readiness guide frames security as a lifecycle running through plan, code, test, audit, deploy, and monitor. That is useful because it forces a broader view: the review surface is not just changed files, it is the set of components whose truth conditions changed.

Authority drift is what turns a normal release into a treasury event. OpenZeppelin's access-control documentation makes the core point plainly: permissions may govern who can mint, freeze, vote, or perform other critical actions. Once a new feature or upgrade lands, the blast radius of those permissions can change even if the role names do not. Who can approve the rollout? Who can pause it? Who can add a new market, change a dependency, or bypass a queue during an emergency? If a firm reviews code without reviewing the authority model around the release, it is leaving half the risk unpriced.

This is where good testing and good review finally meet. Foundry's invariant testing guidance is explicit that invariant tests are about properties that should remain true regardless of action sequence. That is the right frame for choosing a firm too. You do not want a reviewer that only points at suspicious lines. You want one that can name the invariant a new release might break, then explain how it would test that invariant across hostile sequences, integrations, and upgrade states. Solidity's own security documentation adds one more uncomfortable point: even bug-free contract code still depends on compilers and platforms that can have security-relevant bugs. That is why exact build context, not just source review, belongs in scope.

The misunderstanding at the center of this market is simple. Buyers think they are hiring someone to read today's contracts. The better buyers hire someone to explain tomorrow's changed assumptions.

What good looks like

What good looks like is surprisingly concrete.

1. Ask for a change-surface map, not just a scope list. The firm should be able to show the touched files, the untouched contracts whose assumptions change because of the release, the privileged roles involved, and the external dependencies newly trusted. If the answer is just a repository path and a date range, it is too shallow.

2. Ask for the invariants they intend to pressure-test. "We review for reentrancy and access control" is not enough. You want sentences like "rewards cannot be inflated by self-registration," "an unproven message can never pass authentication," or "an emergency role cannot mutate accounting state." If the firm cannot state the truths that must survive the release, it is not yet reviewing the protocol at the right level.

3. Ask what forces a re-review before ship. A serious firm should already have a rule for when a parameter change, market listing, signer rotation, upgrade script edit, compiler version bump, or integration tweak moves the system outside the reviewed state. If the answer is vague, you are buying a document, not a release discipline.

4. Ask what evidence survives the engagement. You should leave with an exact commit hash, compiler and deployment context, a privilege map, fix-verification notes, and a plain-language explanation of what remains risky after the release. If the only durable artifact is a polished PDF, then the next fast patch will age that work immediately.

That is the buyer-facing test. Before you hire a firm, ask it what your next upgrade could break. The quality of the answer will usually tell you more than the brand name on the proposal.

ChainShield's angle

ChainShield's view is that security has to follow change, not just code snapshots. The right partner is the one that keeps pulling on the live thread: what changed, what old assumption no longer holds, who can approve the new path, and which invariant now needs a stronger test or runtime check.

That is why we care more about evidence than ceremony. Founders should buy the firm that makes the next board update and the next launch decision more truthful. CTOs should buy the firm that can explain how a release changes the threat model, even where the diff looks small. If a security partner cannot do that before the contract changes go live, it is not really telling you how safe the protocol is. It is telling you how cleanly it can summarize the past.

The best security firms are not the ones that only find today's bug. They are the ones that can tell you, with precision, what tomorrow's upgrade puts at risk before you sign the invoice and before users sign the transaction.