1. Audit Preparation & Scope Definition
Before formally starting the audit, I align with the client to:
- Confirm the Codebase & Commit Hash: Identify the exact version of the code to audit, avoiding last-minute changes.
- Review Documentation & Architecture: Assess high-level design choices, usage scenarios, and any existing developer docs.
- Discuss Project Goals & Concerns: If needed, hold a “pre-audit call” to clarify any unique business logic or specific issues the client wants examined.
In some cases, I highlight missing tests or documentation, so the client team can resolve these gaps before we start. This helps us focus on deeper security reviews.
2. Kick-Off & Audit Planning
Once everything is set, it’s time to officially begin:
- Kick-Off Call: We meet with the client’s team to confirm final details, timeline, scope, and any nuances discovered from an initial code review.
- Audit Plan: I create an audit plan outlining the structure. This ensures every part of the code is thoroughly reviewed in a systematic, consistent manner.
3. Code Review
At the heart of the process, at least 2x code review is performed. This ensures that each line of code undergoes multiple sets of eyes, catching issues that might slip past a single reviewer.
My core security review consists of two key phases:
3.1 Thorough Manual Analysis
- Line-by-Line Review: I scrutinize every part of the code, looking for logical flaws, edge cases, and business logic errors.
- Access Control Checks: Confirm role and permission configurations are correctly implemented across all functions.
- Custom Logic & Edge Cases: Special attention to project-specific features or assumptions that might introduce unforeseen vulnerabilities.
3.2 Strategic Use of Automated Tools
- Static Analysis: Automated scanners flag common security patterns (e.g., integer overflows) that might otherwise slip through.
This synergy of human expertise and specialized tools helps me identify both high-level design flaws and common coding pitfalls, ensuring a robust audit that leaves no stone unturned.
4. Ongoing Communication & Check-Ins
Throughout the audit, I maintain regular check-ins with the client to:
- Clarify Complex Areas: If any portion of the code raises questions, I discuss with the client’s dev team.
- Flag Critical Findings Early: For critical or high-severity issues, I alert the client right away so they can begin planning fixes.
5. Reporting & Fix Review
Upon completion, I produce an initial private audit report, detailing:
- All Found Issues: Clearly categorized by severity (Critical, High, Medium, Low, Informational). I’m committed to excellence and my mission is to not only spot vulnerabilities but also provide suggestions on the code (Low and Informational issues) to improve the general robustness, quality and readability, ultimately reducing the chance of future bugs.
- Recommendations: Step-by-step guidance on how to remediate each vulnerability.
- Context & Rationale: Why a particular issue matters and how it could be exploited.
- Audit Process Summary (optional): An overview of the thorough, multi-layered approach for teams that require deeper insights into our assessment and risk analysis processes.
The client is entitled to one round of fix reviews provided each fix is in a dedicated pull request. While each fix has to be submitted as a separate PR for focused, isolated analysis, I always consider the entire codebase to prevent new issues. Once the client addresses these issues, I verify the solutions and finalize the report.
6. Retro & Knowledge Sharing
After delivering the initial report, I devote a “Retro Day” to:
- Document Lessons Learned: Summarize any new attack vectors or notable approaches uncovered during the audit.
I also gather feedback from the client to adapt and improve based on these insights, ensuring the processes remain flexible, efficient, and aligned with each team’s unique needs.
7. Final Delivery & Optional Publication
I update the report with verified fixes and provide a final, polished PDF report.