3.9.4 During the Audit

The audit has started. The codebase is frozen, the auditors have the threat model and invariants documents, the scope is signed. For the next 2-4 weeks, the engagement is a collaboration between the development team and the security reviewers. How that collaboration goes determines whether the audit's findings are deep and accurate, or shallow and full of false positives.

Most teams have an unhelpful default model of audits: deliver the code, wait for the report. That model leaves substantial value unextracted. Auditors have questions while they work; the team can answer them in minutes that would otherwise take the auditors hours of reverse-engineering. Findings come in throughout the engagement, not just at the end; addressing them in real time often surfaces deeper issues. The relationship dynamics matter — auditors who feel ignored or rushed produce different work than auditors who feel engaged and supported.

This subsection covers the operational dynamics of an active engagement: communication channels and cadence, response time expectations, handling mid-audit findings, dealing with code changes that arise during the engagement, and the human side of working with security reviewers under time pressure. The mechanics are not glamorous, but they're where audit value is gained or lost.

Communication Channels

Most audit engagements run on at least two channels: a high-bandwidth synchronous channel for active discussion, and an asynchronous channel for status updates and document sharing.

Recommended Setup

Slack / Discord channel — a dedicated channel for the engagement with the development team's relevant people and the audit team's reviewers. Used for:

• Auditors' questions about contract behavior or design intent
• Real-time clarification of edge cases
• Notifications when something significant is found
• Casual back-and-forth that doesn't justify a meeting

Weekly video call — typically Tuesday or Wednesday, 30-60 minutes. Used for:

• Status update from auditors (areas covered, areas remaining)
• Significant findings already identified and their initial framing
• Questions that benefit from screen-sharing or whiteboard explanation
• Schedule confirmation for the remainder of the engagement

Email or audit platform — for formal exchanges:

• Signed engagement letters
• Scope changes (when they happen)
• The final report delivery

Shared document repository — Notion, Google Docs, or similar:

• The threat model and invariants documents (linked, not pasted)
• Running list of mid-audit findings (updated by auditors)
• Q&A log (questions and answers accumulated over the engagement)

What Goes Where

A common failure mode is everything ending up in Slack and getting lost. The discipline:

• Questions / answers → Slack, but with the substantial ones also captured in the Q&A log
• Findings → Captured in the shared findings document with severity, description, and proof-of-concept
• Decisions → Captured in the Q&A log (e.g., "Decided X means Y for the purposes of this audit")
• Discussions about scope → Email or formal channel for traceability
• Anything urgent → Direct message + Slack channel + email, in that order

The Q&A log is particularly valuable. By engagement end, it functions as auxiliary documentation — every clarification the auditors asked for that wasn't in the original threat model. After the audit completes, the development team can fold the Q&A log into the codebase's NatSpec or threat model so the next audit doesn't ask the same questions.

Response Time Expectations

How fast the development team responds to auditor questions directly impacts how much code gets reviewed. An auditor blocked on a question for two days is an auditor not finding bugs for two days. For a 3-week engagement, even a single 2-day block can lose significant coverage.

Reasonable targets:

• Trivial clarifications (e.g., "what does this variable name mean?") — same day, ideally within hours
• Substantive design questions (e.g., "why is the flow structured this way?") — within 24 business hours
• Findings requiring confirmation (e.g., "I think this is a bug; can you confirm?") — same day, ideally within hours
• Scope questions (e.g., "is this file in scope?") — within 24 business hours

The development team should designate a primary point of contact who is available throughout the engagement — not the entire team, just one or two people who triage questions and route them to the right expert. The auditor knows who to ping; the rest of the team is shielded from the constant interruption.

The Single-Point-of-Contact Pattern

Auditor question → Primary POC → Triage → Routed to right expert → Answer → POC posts back

This structure prevents both ends of the failure spectrum: the team being constantly distracted by audit questions, and the auditor being unable to reach anyone. The POC's job is to make sure no auditor question waits longer than the SLA above.

For multi-person engagements, the POC may rotate (e.g., weekly) to share the load. The handoff between rotations should be documented so the auditors don't have to re-establish context with each new POC.

Mid-Audit Findings

Auditors don't find all the bugs at once and present them at the end. Findings emerge throughout the engagement. How those mid-audit findings are handled affects the engagement substantially.

The Right Workflow

When an auditor identifies a potential finding:

1. The auditor documents it in the running findings list (in the shared repository) with: brief description, suspected severity, affected file(s), proof-of-concept (if available), reproduction steps
2. The auditor notifies the team in the Slack channel — not a formal report, just a heads-up
3. The team reviews the finding to verify it's a real issue (and at the suspected severity)
4. The team responds with confirmation, dispute, or request for clarification

For critical findings (something that could cause immediate loss if production), the workflow is faster: the auditor directly messages the team's POC, the team responds within hours, and a decision is made about how to handle it.

Confirming vs. Disputing Findings

When a finding lands, the team has three legitimate responses:

"Yes, this is a real issue." Acknowledge it, decide on remediation approach, communicate timeline for fix. Don't argue about severity unless there's a substantive basis — auditors generally calibrate severity well, and arguing reflexively damages the relationship.

"This isn't a bug because of X." Provide the specific reason. Often the "bug" is a misunderstanding of intended behavior; explaining the design clearly resolves it. Sometimes the auditor will push back and the explanation needs to extend (the auditor's job is to be skeptical). The Q&A log captures the resolution.

"This is a known issue we documented as out-of-scope." Reference the known-issue list from the threat model. If the auditor agrees, the finding gets noted but not formally reported. If they disagree about whether it's actually out-of-scope, escalate to the engagement-level discussion.

The wrong response: silence. Findings without responses pile up and degrade the quality of the engagement. Auditors stop documenting borderline cases if they perceive the team isn't engaging.

Fixing Mid-Audit

A judgment call: should the team fix findings as they come in, or wait for the report and fix at the end?

Arguments for fixing mid-audit:

• Catches related issues earlier (a fix often surfaces adjacent problems)
• The auditor can verify the fix in their remaining review time
• Reduces the post-audit remediation burden

Arguments against fixing mid-audit:

• Changes the audited codebase, complicating the report
• The fix may introduce new bugs the auditor won't have time to review
• Disrupts the auditor's mental model of the code

The compromise that works for most engagements: fix critical and high-severity findings mid-audit; defer medium and low findings to post-audit remediation. The critical fixes happen on a clearly-labeled branch (e.g., audit-critical-fixes) with each commit referencing the finding ID. The auditor knows the fix exists, can spot-check it, and the final report reflects the fix's existence.

For trivial findings (typos, minor optimization suggestions), fixing immediately is usually fine — the changes are small enough not to disrupt the audit.

Code Changes During the Engagement

The codebase was frozen at audit start. What happens when the team genuinely needs to change something during the engagement?

Legitimate Reasons for Mid-Audit Changes

• Critical production bug discovered in deployed code (not the audit code). Often the audit code shares logic; the fix needs to be applied to both.
• Dependency upgrade required by a third-party vulnerability disclosure
• Regulatory or compliance requirements that materialize during the engagement
• Critical-severity audit finding that the team chooses to fix immediately

The Protocol for Changes

1. Pause active review if practical. The auditor stops on the current commit while the change is being made.
2. Notify the auditor in the channel and via email: what's changing, why, and what new commit hash is in scope.
3. Decide on scope. Options:
   • The auditor reviews the delta between old and new commits (most common)
   • The auditor restarts review from the new commit (when the change is extensive)
   • The change is deferred to post-audit (when it can wait)
4. Adjust timeline and cost as appropriate. A mid-engagement scope change is a renegotiation; most audit contracts allow for it.
5. Update the scope document to reflect the new commit hash. Both parties sign.

The discipline is to handle changes formally rather than silently. A "small change" that wasn't communicated produces a report that doesn't reflect the deployed code — exactly the failure mode the codebase freeze was designed to prevent.

The Relationship Dynamics

Audits are technical work, but they're performed by humans. The human dynamics of the engagement affect the quality of the output in ways that aren't always obvious.

What Auditors Value

Conversations with auditors who've done many engagements surface a consistent pattern of what makes clients good to work with:

• Responsive communication. Questions answered promptly, decisions made clearly, no waiting in Slack for days
• Technical sophistication. The team understands what the auditor is asking, doesn't need everything re-explained
• Honest threat modeling. Known risks are disclosed upfront; the team doesn't try to hide what they're uncertain about
• Engagement with findings. The team takes findings seriously, asks substantive questions, and discusses tradeoffs rather than reflexively pushing back
• Realistic timelines. Expectations match the available time; no last-minute scope expansion

What Auditors Don't Value

The patterns that produce friction:

• Time pressure on findings. "Can you finish today?" cuts into review depth
• Reflexive disputing. Pushing back on every finding without substantive basis exhausts goodwill
• Hidden context. Important details that should have been in the threat model emerging late in the engagement
• Frequent scope changes. Each one disrupts the auditor's model of the codebase
• Treatment as a vendor. Auditors who feel like procurement-managed contractors do less proactive work than auditors who feel like collaborators

The most productive engagements treat the auditor as a temporarily-embedded member of the team. The team's questions go to the auditor; the auditor's questions get answered promptly; both parties act like they share a goal — because they do.

When the Audit Goes Sideways

Sometimes engagements don't go well. The auditor may be unresponsive, find few issues, deliver a low-quality report, or push back on scope unreasonably. Less commonly, the development team may be the problem — unresponsive, defensive, or hiding context.

For escalation:

• Document the issue specifically. "Auditor hasn't responded to questions for 4 days" is actionable; "the audit isn't going well" is not.
• Escalate within the audit firm. Most firms have a senior partner or engagement manager who can step in.
• For contest platforms, escalate to platform staff (sponsor support).
• In the worst case, the engagement can be terminated. The cost is the time invested and possibly a partial fee; the alternative is a useless report.

Most engagements don't reach this point. But knowing the escalation path exists, and being willing to use it, is part of running the engagement responsibly.

A Realistic Engagement Timeline

For a typical 3-week audit:

Week 1, Days 1-3 (Onboarding):

• Kickoff call: team walks auditor through the codebase, threat model, deployment script
• Auditor reads documentation and forms initial understanding
• Q&A begins — most questions in this phase are about design intent and trust boundaries
• No findings yet; auditor is building context

Week 1, Days 4-7 (Surface Review):

• Auditor runs automated tools (Slither, custom scripts) and reviews findings
• Begins systematic walk-through of the contracts
• First findings appear — typically low/medium severity, often easy fixes
• Q&A continues actively

Week 2 (Deep Review):

• Auditor focuses on complex business logic, trust boundaries, edge cases
• Highest-value findings appear here — often medium-to-critical severity
• Mid-audit findings doc grows substantially
• Team may begin fixing critical findings on audit-critical-fixes branch
• Communication intensity peaks; multiple Slack threads active

Week 3 (Synthesis and Reporting):

• Auditor verifies remaining hypotheses, looks for additional issues
• Drafts the report — severity classification, recommendations, detailed write-ups
• Team reviews draft findings, contests if appropriate
• Final report draft completed

Week 4 (Delivery and Initial Remediation):

• Final report delivered (usually as PDF + Markdown)
• Team begins systematic remediation against findings
• Fix verification round begins for critical/high findings

These windows compress or expand based on engagement length and complexity. A 6-week engagement has roughly the same structure with longer time in the middle phase. A 1-week engagement is essentially compressed onboarding + surface review + delivery, with deep review limited.

Quick Reference: During-Audit Discipline

Cross-References

• Audit preparation — Section 3.9.2 covers what should be in place before the engagement starts
• Post-audit remediation — Section 3.9.5 covers what to do with the final report
• Communication channels — Section 4.3.4 covers the auditor's perspective on communication during engagements
• Incident response — Section 2.9 covers what to do if a critical finding indicates immediate production risk
• Auditor's view of engagements — Book 4 chapters 3 and 5 cover the auditor's side of the same dynamics