In 2014, we published our first security audit report. Since then, we have completed more than 200 audits and published more than half of those. The primary audience of an audit report is the client’s project development team. However, stakeholders and other interested parties can also find value in reading and understanding a report. Being able to gauge the design, issues, and commitment to security of a particular project can be an invaluable guide in deciding to make use of an application, service, or other web3 product.
We follow a conservative and transparent process for analyzing potential security vulnerabilities and seeing them through successful remediation. After our initial audit review, we document our unresolved issues, open questions, and suggested resolutions in our Initial Audit Report, which is intended for internal use only. Once the findings are comprehensively addressed by the client, we complete a verification review to assess that the issues and suggestions are sufficiently addressed. When this analysis is completed, we update the report and provide a Final Audit Report. We encourage that the Final Audit Report be shared publicly for the transparency of efforts and the advancement of security learnings within the industry.
The goal of this blog is to help readers understand how to read and interpret these reports effectively. We will identify the critical sections of a security audit report, and break down each section in order to explain what readers should focus on and why it matters. For the purposes of this blog, we will be using sections found within a Least Authority audit report, though reports from other auditing firms may have similar formats and headings.
The initial step is to review the Overview section. This part usually starts with a segment called Background, which not only identifies the audited project but also specifies who initiated the audit. Why is this significant? It distinguishes whether the client is auditing their own creation or if a third party is commissioning the work.
The following section, Project Dates, offers more than just a list of dates. Delving into the audit timeline aids readers in assessing the relevance, scope, and consequences of the audit’s findings and recommendations on the security and dependability of the audited system or product. The length of time an audit takes can also be an indicator regarding the complexity of the components of a project. Moreover, if an updated final audit report was delivered, which may sometimes (but not always) happen if it is needed given the circumstances, the delivery date of the updated final audit report would also be included in this section. This amalgamation of details serves as an indicator of the audit’s depth and thoroughness. An example of this can be found in our audit of Plonky2, an implementation of Polygon Zero.
The narrative unfolds further with the Review Team section. The number of auditors engaged in each project is another indicator of the audit’s complexity and breadth.
This is followed by the Coverage section which begins with Target Code and Revision. This section is a list of the code repositories and links that are considered in scope for the review. A code repository, often referred to simply as a ‘repo,’ is a storage location where software developers store and manage their source code files. It serves as a centralized hub for version control, collaboration, and tracking changes made to the codebase. Code repositories typically use version control systems to track revisions, manage branches for parallel development, and facilitate collaboration among team members. Developer teams can push updates, pull changes from other projects, and maintain a history of code modifications within a code repository. Popular platforms for hosting code repositories include GitHub, GitLab, and Bitbucket.
The contents of a code repository can be highly technical and may include programming languages, code structures, comments, and development-related discussions that could be difficult to understand in some circumstances. It does, however, provide some reassurance for stakeholders or interested parties that the organization demonstrates an additional level of transparency and project progress tracking.
The following section, Supporting Documentation, comprises resources utilized by the auditing team, which may encompass client-shared files, websites, and references cited in the report. It encompasses additional documents, websites, or sources used during the review process.
The Areas of Concern section delineates the investigation’s primary focus, as determined collaboratively by the client and audit team. This list encompasses various aspects, including implementation accuracy, component vulnerabilities, secure component interactions, key management, Denial of Service (DoS) and security exploit prevention, data privacy, integrity, and any other issues identified during the initial analysis phase.
The subsequent key section, Findings, encompasses the audit team’s General Comments and assessment of the System Design, Code Quality, Scope, and Specific Issues and Suggestions. It is crucial to focus on the findings section, as it delineates specific risks that could impact the security and functionality of the digital wallet or web3 product. This section aids in understanding the potential consequences of these vulnerabilities on security and privacy.
The General Comments section is a brief description of what the project or implementation is about and how it works. It also summarizes our investigation of the main areas and components that we looked at, along with any findings.
In the next phase, the System Design section encompasses an evaluation of the system’s architecture and structure. This entails assessing the organization and security of the interactions between the system components, as well as the data flow within the system. The goal is to gauge the design’s security robustness by identifying potential vulnerabilities and weaknesses exploitable by attackers. Additionally, the review team may remark on whether the system’s architecture and functionality adhere to security best practices, industry standards, and regulatory mandates.
The Code Quality refers to the review team’s overall impression on the standard of the project’s programming code in terms of readability, maintainability, efficiency, reliability, and adherence to coding standards and best practices. It includes various aspects that contribute to the overall security of software systems.
This is followed by the Documentation and Code Comments section, where the review team discusses the quality of the documentation provided by the client and the code comments found within the codebase. The review team may respond with suggestions or recommendations if improvement is needed.
The Scope of an audit refers to the boundaries and objectives defined for the audit process. It outlines what will be examined, evaluated, and reported on during the audit. The scope sets the parameters for the audit team and ensures that the audit remains focused and aligned with the client’s goals and requirements. If we felt something critical was left out of scope, we may report that and recommend that the client include this in the scope of future audits.
The Findings section begins with a list of the Specific Issues and Suggestions found during the review, in the order of discovery. Following the list, each issue is expanded upon. This can include details such as; location of the discovery within the code; synopsis; impact; preconditions; feasibility or likelihood of an exploitation of the issue; technical details; remediation recommendations; status; and verification to clearly specify whether the issue has been resolved. In most cases, remediation of an issue, as per the audit team’s recommendations, is preferable. However, in some cases, the audit team may suggest mitigating the issue instead, as another option, for cases where a trade-off could be required.
Readers should prioritize the Specific Issues and Suggestions section, as it provides a listing of what problems were discovered as well as the actionable steps for the project to strengthen its security. It helps readers understand what steps are necessary to address the issues highlighted in the findings.
By focusing on these key sections and understanding their significance, any reader can gain valuable insights into security audit reports and make informed decisions.