Audit Methodology
Should Auditors Fix the Code They Audit? Smart Contract Audit Independence and Remediation Guidance
One of the oldest arguments in security consulting has quietly become one of the most important arguments in smart contract auditing: should the auditor stop at identifying vulnerabilities, or should they also tell the client how to fix them? The question sounds operational. It is actually about incentives, assurance, and the boundary between independent review and engineering participation.
In crypto, that boundary matters more than it does in most software domains. An audit finding is not just a ticket in Jira. It may sit between a protocol and a nine-figure loss. Teams want actionable outcomes, not abstract warnings. At the same time, an auditor who writes the patch is no longer a neutral observer in the same sense. They become, at least partially, a co-author of the code they are supposed to assess.
Both sides are right about something important, and we are not going to pretend the tension away. Pépouze has made a deliberate choice: we do both. Every audit identifies the vulnerabilities and proposes concrete fixes — at the vulnerability level and, on the deeper tier, at the architecture level. This article lays out the real arguments for and against that choice honestly, and then explains why we think it is the right one for the teams we serve, and how we structure it so the well-known objections do not quietly become the client's problem.
One thing changes the classic debate in our case: Pépouze is a fully automated audit. Most of the independence objection assumes a human firm that proposes a patch and then defends its own reasoning when asked to re-check it. A deterministic tool does not have that ego or that incentive. It can re-run the exact same analysis against the fixed code and report the delta neutrally — which weakens the "self-review" problem considerably without hand-waving it away.
The Real Distinction
Conceptual guidance
Describe the invariant that must hold and the design direction that restores it.
Low independence risk
Illustrative pseudocode
Show the intended sequencing, checks, or state transitions without presenting deployable code.
Manageable if clearly labeled
Production patch
Provide Solidity that can be copied into the codebase with minimal modification.
High independence and liability risk
The Case For Providing Smart Contract Audit Recommendations
Clients pay for decisions, not just diagnosis
A finding that stops at 'this is dangerous' is often incomplete in practice. Most teams hire a smart contract audit because they want the system to be safer on a deadline. That means they need help translating a vulnerability into a concrete remediation path, not just a severity label.
The auditor has the deepest context on the bug
By the time a finding reaches the report, the auditor has already traced the exploit path, understood the relevant invariants, and ruled out weaker explanations. That context is expensive to rebuild. In many cases, the person best positioned to suggest a fix is the person who found the flaw in the first place.
Smaller teams often do not have in-house security engineering
For a mature protocol with internal reviewers, fix direction may be optional. For a two-person startup shipping its first upgrade, it is essential. Without remediation guidance, the audit can become a handoff to nobody. The result is not independence in a meaningful sense. It is just remediation debt.
No fix recommendation means longer remediation lag
The longer a team spends debating what a finding actually requires, the longer the vulnerability remains live in staging, in code review, or sometimes in production. Good remediation guidance shortens that lag by giving the engineering team a safer starting point and a narrower design space.
Security reviews in web2 usually include remediation guidance
Penetration tests, secure code reviews, and infrastructure assessments almost always ship with recommended mitigations. That is normal because security work is expected to be actionable. Smart contract audits are not identical to web2 testing, but the user expectation is similar: tell us what is wrong, and tell us how to move forward.
There is also a practical point that auditors sometimes understate: the exploit path is usually much clearer than the remediation path from the client's perspective. The auditor has already done the difficult interpretive work. They know which invariant failed, what assumption was violated, and whether the bug is local or systemic. Asking the client to reverse-engineer a safe fix from a finding description can turn a strong audit into a weak handoff.
This is why many teams, especially early-stage teams, experience an audit report without remediation guidance as incomplete. A strong code review security audit should improve the odds that a flaw is removed correctly, not merely documented elegantly. That does not require the auditor to become the implementation team, but it does argue for meaningful smart contract audit recommendations rather than sterile bug descriptions.
The Case Against It: Why Audit vs Remediation Is a Real Boundary
The auditor stops being fully independent
Once an auditor writes the patch they later evaluate, they are no longer just reviewing code. They are partially authoring it. That changes the nature of the engagement from independent assessment toward consulting or co-development, even if everyone still calls it an audit.
A flawed fix creates an obvious conflict of interest
If the auditor's proposed remediation is incomplete, introduces a new bug, or breaks an invariant elsewhere, who is supposed to review that fix objectively? The same firm that suggested it has a natural incentive to defend its own reasoning. That is not a trivial governance problem. It is the core independence problem.
Fix-writing can anchor the audit itself
Auditors can drift toward findings they already know how to solve cleanly. That sounds subtle, but it matters. The mental move from 'is this dangerous?' to 'can I propose a neat patch?' can bias attention toward solvable local defects and away from uglier systemic risks that do not fit neatly into a code diff.
Traditional auditing draws a harder line
Financial auditors do not prepare the books they audit. They review, challenge, and opine. The analogy is imperfect, but the principle is useful: independent assurance weakens when the reviewer begins producing the object being reviewed. Smart contract security is more engineering-heavy, but the independence tradeoff is real.
Recommendations can create false confidence
Even when the recommendation is sound, implementation usually diverges. Variables are renamed, adjacent logic is refactored, tests are weakened, or the fix is merged alongside unrelated changes. Teams then remember that 'the auditor gave us a fix' and conclude the issue is resolved, even though the deployed implementation may no longer match the original guidance.
The independence argument is not ceremonial. It goes to the heart of what an audit is supposed to buy. Clients do not just purchase expertise. They purchase adversarial distance. The auditor is paid to look at the system from outside the decision chain and say whether the code is safe enough to ship. That distance weakens if the same firm is effectively designing the implementation.
The problem gets sharper after remediation. If an auditor proposes a patch and then later marks the issue as resolved, the engagement starts to resemble self-review. Even when everyone acts in good faith, the structure is fragile. The more detailed and deployable the recommendation becomes, the more reasonable it is to ask for a second reviewer, a diff review, or a separate engineering engagement rather than treating the original audit as sufficient.
Where Pépouze Lands
Find the flaw, propose the fix, and re-scan the result automatically
We think the market has been too timid here. A finding that stops at "this is dangerous" leaves the hardest part — actually removing the risk — on the client's desk, right when the deadline is closest. So Pépouze proposes a concrete remediation for every finding: the security property that must hold, the design direction that restores it, and illustrative code that shows the intended shape of the fix. On the deeper tier we go further and flag architecture-level changes, not just line-level patches. What keeps this honest is not refusing to help — it is that the fix is clearly labeled as illustrative, the client owns review and testing, and the same automated pipeline can re-scan the patched code deterministically before anyone calls the issue closed.
The Legal Dimension: Who's Liable When the Fix Fails?
The legal issue is where this debate stops being philosophical. Suppose an auditor provides a specific remediation, the client implements it nearly verbatim, and the patched contract is still exploitable. If funds are later lost, it is not hard to imagine the client alleging negligence, professional liability, or breach of contract. Even if that claim ultimately fails, the auditor has already absorbed the cost of the dispute. The mere fact that the code was suggested in an audit report changes how the engagement may be interpreted after an incident.
The core problem is that the line between remediation guidance and engineering advice is blurry, especially in Solidity. A sentence like "replace external call ordering to restore CEI" is obviously guidance. A code block that can be copied into production is much closer to professional implementation advice. The smart contract audit market still lacks the contractual maturity of traditional software consulting. Liability caps, role definitions, review obligations, and professional indemnity coverage are not yet standardized across firms, even though the assets at risk are often vastly larger than in ordinary software engagements.
Courts and regulators have not cleanly defined the duty of care a smart contract auditor owes once the firm crosses from finding bugs into prescribing solutions. That uncertainty creates asymmetric risk. The client still bears execution risk because they deploy the code, but the auditor may inherit legal exposure without being paid or insured like a true implementation partner. In other words, the market often prices remediation guidance as a small add-on while the downside can look more like engineering liability.
The practical answer is discipline, not wishful thinking. If an audit firm offers fix recommendations, they should be explicitly non-binding, illustrative, and accompanied by a clear statement that the client must independently review, test, and validate any remediation before deployment. Where the recommendation materially shapes production code, the safer path is to require a re-audit or at minimum a focused diff review. Without that structure, the legal posture around audit vs remediation is far less settled than the industry often pretends.
How Pépouze Handles the Boundary
Pépouze proposes a concrete fix for every finding — at the vulnerability level, and at the architecture level on the deeper tier — not just a severity label.
Fixes are delivered as illustrative code and design direction, clearly labeled as such: the client must independently review, test, and integrate them before deployment.
Because the audit is fully automated, the same pipeline can re-scan the patched code deterministically, so verifying a fix does not depend on a human defending their own patch.
Reports carry explicit disclaimers that remediation guidance is not professional engineering or legal advice, and that Pépouze assumes no liability for implementations derived from its suggestions.
After remediation, Pépouze recommends a re-scan of the diff before the issue is treated as resolved.
That approach is opinionated by design. We think clients deserve actionable fixes, especially when a finding is subtle or time-sensitive, and we are not interested in hiding behind "independence" to ship a thinner deliverable. What we are careful about is the labeling: an illustrative fix is not a signed-off production patch, and we say so plainly rather than letting the client assume otherwise.
The reason is simple: clarity protects both sides. It protects the client from treating an illustrative fix as final, and it protects Pépouze from implicitly taking on a role the engagement never priced. Automation is what lets us be generous with fixes without being reckless — the tool that proposed the change can re-run the whole analysis on the patched code and show, deterministically, whether the finding is actually gone.
Conclusion
So, should auditors fix the code they audit? Our answer is yes — propose the fix — provided you are honest about what that fix is and is not. The old industry reflex of stopping at diagnosis protects the auditor more than it protects the client. We would rather hand a team a clear, concrete path out of the problem and be explicit about the boundaries than ship an elegant list of dangers and wish them luck.
The classic objection — that fixing your own findings destroys independence — is real for a human firm defending its reasoning. It is much weaker for a fully automated pipeline. Pépouze does not have a reputation to protect in front of its own patch. It can re-run the identical analysis on the corrected code and report, deterministically, whether the finding survived. That is closer to a build passing or failing than to an auditor grading their own homework.
None of this removes the legal dimension — it disciplines it. We provide fixes with explicit disclaimers, we label them as illustrative and client-owned for review and testing, and we recommend re-scanning the diff before anyone calls the issue resolved. That is how you get the best of both: the actionable remediation clients actually need, delivered without pretending the tradeoffs do not exist.
Pépouze Smart Contract Audit
See how Pépouze handles remediation guidance in practice
Review the Pépouze sample Compound V2 report for an example of how we communicate findings, recommendations, disclaimers, and follow-up review expectations in a real audit deliverable.