# Table of Contents - [Anatomy of a Spearbit Review | Spearbook](#anatomy-of-a-spearbit-review-spearbook) - [Scoping and Information Gathering | Spearbook](#scoping-and-information-gathering-spearbook) - [Form Submission | Spearbook](#form-submission-spearbook) - [Communication Channels and Access | Spearbook](#communication-channels-and-access-spearbook) - [Final Report Delivery | Spearbook](#final-report-delivery-spearbook) - [Kickoff | Spearbook](#kickoff-spearbook) - [SOW & Rates | Spearbook](#sow-rates-spearbook) - [Close-out Call and Walkthrough | Spearbook](#close-out-call-and-walkthrough-spearbook) - [Security Review Period | Spearbook](#security-review-period-spearbook) - [Fix Period | Spearbook](#fix-period-spearbook) - [Anatomy of a Spearbit Review | Spearbook](#anatomy-of-a-spearbit-review-spearbook) --- # Anatomy of a Spearbit Review | Spearbook ![Page cover](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2F7EkzIbYOeWIIHmDfTSqy%2FConcept.jpg&width=1248&dpr=3&quality=100&sign=f4392560&sv=2) [hashtag](https://docs.spearbit.com/#to-our-community) To Our Community ---------------------------------------------------------------------------- Spearbit’s methodology for performing reviews has delivered **consistent industry-leading quality of results at scale** for web3 security reviews. As a result, the intention of this outline is to provide web3 security researchers and firms alike with a strong and standardized methodology for success in the coordination of engagements. [hashtag](https://docs.spearbit.com/#to-our-clients) To Our Clients ------------------------------------------------------------------------ This breakdown serves to inspire confidence in the depth of the Spearbit review process and to provide insights into how to best prepare for your own Spearbit review in order to maximize the benefit to your project. circle-info During the review process it's crucial for all parties to be aware of requirements, next steps, and the current status of the engagement to prevent scope creep or misalignments on objectives. [hashtag](https://docs.spearbit.com/#engagement-flow) **Engagement Flow** ------------------------------------------------------------------------------ Below is an overview of the Spearbit engagement lifecycle: 1. Form Submission 2. Scoping and Information Gathering 3. Communication Channels and Access 4. SOW & Rates 5. Kickoff 6. Security Review Period 7. Close-out Call and Walkthrough 8. Fix-Period 9. Final Report Delivery [NextForm Submissionchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/form-submission) Last updated 2 months ago --- # Scoping and Information Gathering | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#initial-scoping) Initial Scoping -------------------------------------------------------------------------------------------------------------------------------------------------- While it is common for the scope of the security review to occur during the initial phases of the review itself - we highly recommend provisioning the full scope of your security review elucidating the relevant areas of the system within scope as well as the location of the code repository and it's **most recent commit hash** for review. The client and Spearbit core team will have a scoping call in order to determine scope, estimate a start date, and familiarize the client with the Spearbit process as well as answer any further questions. circle-info **Note:** Access to the target repository is needed to generate realistic estimates and continue the process. These access rights should be squared away for core members during this phase of the engagement and for the review team after formation during the phase. In the event there is a lack of clarity Spearbit will request access for Lead Security Researchers to pre-evaluate the code base prior to moving onto the next phase. Upon completion and confirmation of the full scope required of the security review, the client will be provided with the following: * Total Amount Due * Review Start Date * Review Completion Date For full details regarding the engagement after the scoping process - the client will be provided a Statement of Work (SOW) as shown here which will include the items listed above. ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#team-formation) Team Formation Upon the confirmation of scope, the client will be given their own personal communication channels with the core team inside of the Spearbit discord as discussed in the section. To estimate workload and determine the relevant researchers with the required skillset for a client's scope, the client must **authorize core members to access the target repository if it is private.** Access to the target repository is necessary to generate realistic estimates and continue the engagement process. Depending on codebase complexity, the core team may request the client provide access to Lead Security Researchers to pre-evaluate the code base. **After the estimates have been set**, the core team will make the security review offer public to the internal Spearbit network and reach out to you once researcher responses have been evaluated. **In order to maintain a high-level of quality assurance** for our reviews, a security review is typically comprised of: * 2 Lead Security Researchers * 1 Security Researcher * 1 Associate Security Researcher * 1-2 Junior Security Researchers Depending on the target scope however, this may be subject to change dependant on the needs of the client. circle-info **Note**: If a client would like a **private review** or **a specific researcher(s)' services explicitly**, please inform us in advance. It's also worthy to mention should that specific researcher not have availability there could be modifications to the estimated start time for the review. [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#documentation-and-information-gathering) Documentation and Information Gathering -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- It is essential that the security researchers are provided any relevant documentation that may assist them in understanding the full landscape of the protocol or project's code that is under review. The documentation provided should be clear, concise, and updated and should elucidate the following: ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#proper-code-specification) Proper Code Specification #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-1.-clear-context) 1\. Clear Context It is imperative for development teams to properly scope out the system and detail in writing - the key aspects of the system, their intended use cases and any other information deemed relevant in plain english regarding the purpose of the project itself. We recommend documenting the following in detail: **• Definitions**: Key terms used that are internal to the development team **• Participants**: Any actor that interacts with the system **• Access Controls**: Participants' allowed actions within the system **• Functionality**: Public system entry points, their state interactions, and subsequent return values #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-2.-definitions-of-state) 2\. Definitions of State If at any point your system persists state, it should be classified as a state machine and documented accordingly. Clear definitions enable simplifying state transitions so that the system can become less complex. Spearbit recommends provisioning the following: 1. **Identify States**: Enumerate all possible states 2. **Define Transitions**: Detail state changes and conditions 3. **Specify Events**: Pinpoint triggers per transition 4. **Describe Actions**: Note outputs produced during transitions 5. **Detail Exception Handling**: Plan for unexpected events 6. **Narrate Use Cases**: Illustrate state machine operations with examples #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-3.-diagrams-and-visuals) 3\. Diagrams and Visuals Well-constructed diagrams that detail the system or system components in depth are pivotal during scoping as well as during the review process itself. Examples include but are not limited to: * System and Components Diagrams * State Diagrams * ERDs * Flow of Funds Diagrams * Sequence Diagrams * Network Architecture Diagrams #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-4.-interfaces-and-dependencies) 4\. Interfaces and Dependencies Information regarding auxiliary items should be provided in detail such as interfaces, dependencies, or any external services / third parties that affect the system. **Interfaces** We recommend drafting system interfaces with precision so that the security research team with a full understanding of their relevant context in the scope of the review. The Ethereum Improvement Proposals (EIP) repository exemplifies this practice excellently as shown [**here**arrow-up-right](https://eips.ethereum.org/interface) **.** **Dependencies** Spearbit takes a very robust and comprehensive approach during its review process making it a point to analyze even the dependencies your code relies on for potential security issues. This has been demonstrated multiple times such as in the following examples: 1. [**Aera Finance - Balancer Dependency**arrow-up-right](https://twitter.com/SpearbitDAO/status/1664726990618869762?s=20) 2. [**MorphoLabs - Aave v3 Dependency**arrow-up-right](https://twitter.com/SpearbitDAO/status/1658556015762190340?s=20) #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-5.-clearly-defined-natspec) 5\. Clearly Defined Natspec Spearbit recommends that development teams ensure that they are following best practices for leveraging NatSpec when creating effective documentation to communicate the functionalities and constraints of your smart contracts more effectively. 1. **Understanding NatSpec Tags** - Natspec offers different tags to help guide the specificity of your descriptions. Two such tags are `@dev` and `@notice`. Understanding when to use these tags is crucial in crafting targeted documentation. 2. **Defining Ranges** - In instances where a function accepts a range as an argument, it's crucial to clearly define whether the boundaries are inclusive or exclusive. This clarity will guide users in providing appropriate values and prevent potential transaction failures. 3. **Contextual Descriptions** - Natspec descriptions should provide additional context where possible. For instance, if a function requires a precision input scaled to `1e18` or in the token's decimals, it should be explicitly stated in the description. 4. **Parameter Order Consistency -** For better readability and understanding, ensure parameter order in your Natspec comments match function parameter order. Inconsistent ordering between the documentation and the function could lead to confusion for both developers and end-users. 5. **Preconditions and Checks** - Documenting preconditions and checks are essential so that a contract behaves securely and as intended. Additionally, providing these caveats can help users understand the contract's constraints and avoid transaction errors such as in this example: #### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering#id-6.-test-cases) 6\. Test Cases It's essential that that there is a strong degree of test coverage amounting to at least 90% of the code provided so that the security researchers can have a basis upon which to validate and cross-reference their assumptions or findings. In an ideal world we would seek for clients to provide 100% test coverage and also to cover edge-cases or unforeseen scenarios. In complex protocols, comprehensive testing becomes even more critical, as the interconnectedness of various components increases the risk of vulnerabilities. For an overview of the various types of test cases Spearbit recommends that clients provide, please see the following documentation on [**Smart Contract Testing**arrow-up-right](https://ethereum.org/en/developers/docs/smart-contracts/testing/#unit-testing-for-smart-contracts) by the Ethereum Foundation. [PreviousForm Submissionchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/form-submission) [NextCommunication Channels and Accesschevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/communication-channels-and-access) --- # Form Submission | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/form-submission#inbound-leads) Inbound Leads ---------------------------------------------------------------------------------------------------------------------------- Clients that are looking for a security review **by industry-leading web3 security professionals** across the Spearbit network can reach out to Spearbit in a multitude of different ways. The primary means of requesting a security review is via the [**Spearbit website**arrow-up-right](https://spearbit.com/) **.** ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2FQ2iTGz2bEdTTH1Ymplhe%2Fimage.png&width=768&dpr=3&quality=100&sign=6c39d921&sv=2) Upon requesting a security review - clients are taken to a form in which they are prompted to provide the following for the Spearbit team to review: * _Project Name_ * _Project Details_ * _Contact Information_ * _Source of Knowledge about Spearbit_ * _Relevant Code Repositories_ * _Extent of Services Requested_ * _Budget_ * _Timeline_ Additionally, clients can also reach out to us on [**Spearbit Twitter**arrow-up-right](https://twitter.com/SpearbitDAO) via a direct message, however, we highly encourage the submission of a formal request for review via our website so the team can begin to assess the needs and requirements of your project. ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2FOJIskm2svUqLimJqqsXB%2Fimage.png&width=768&dpr=3&quality=100&sign=1fa0a7f4&sv=2) To schedule a direct call with our COO (Mike Leffer) regarding your potential security review from Spearbit - you can schedule time directly on his calendar [**here**arrow-up-right](https://calendar.app.google/P3WHa3pxBtTygP439) **.** Prior to reaching out through other mediums - the Spearbit team highly recommends clients reach out via our request form as mentioned above so we may cater to the needs that suit a particular project or protocol as best as possible. ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/form-submission#time-to-response) Time to Response Spearbit prides itself in being timely in all forms of the engagement process and we strive to set that precedent from the very beginning. All inbound form submissions can expect a response within **24 hours** of receipt by the Spearbit team. circle-info **Note:** For quality assurance and security reasons - the core team will perform due diligence on the client request prior to proceeding with any subsequent steps of the security review process. [PreviousAnatomy of a Spearbit Reviewchevron-left](https://docs.spearbit.com/) [NextScoping and Information Gatheringchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering) --- # Communication Channels and Access | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/communication-channels-and-access#discord) Discord ---------------------------------------------------------------------------------------------------------------------------------- Discord is used as the primary source of communication during the entirety of the engagement. The channels of communication within discord can be broken into the following: **Client <> Spearbit Core** This is a client's direct communication line with the core team at Spearbit in order to preserve and maintain a high level of transparency and operational support throughout the entire engagement. The core team will create a channel with the client in order to discuss and coordinate any items pertaining to operational overhead of the security review or to provide support in any phase of the engagement process. **Client <> Review Team + Spearbit Core** Another channel will be created for coordination with the researchers conducting the security review itself formed by Spearbit to meet the tailored needs of your unique scope. These researchers will be active in this channel and asking your developers for clarity **Researcher Team <> Spearbit Core** Lastly, the Spearbit team has it's own private channel with the security researchers conducting the review in order to maintain quality control and a high-level purview in order to facilitate efficiency from the operations front of the engagement and to ensure the core needs of the client are being met beyond expectations. circle-info **Note:** These communication channels are flexible and fluid enough to accomodate for clients needs should anything be requested outside of these core mediums. [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/communication-channels-and-access#github) Github -------------------------------------------------------------------------------------------------------------------------------- Github is another primary channel through which the security researchers on the review team will interact, comment, and create issues within your repository regarding the security posture of your code. Our review teams are very active and communicative with client development teams throughout the engagement and we highly recommend that clients utilize this availability to the fullest extent when providing any necessary context during the review period. This section is covered in more detail regarding the usage of Github by the review teams in the section. [PreviousScoping and Information Gatheringchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/scoping-and-information-gathering) [NextSOW & Rateschevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/sow-and-rates) --- # Final Report Delivery | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/final-report-delivery#final-report) Final Report -------------------------------------------------------------------------------------------------------------------------------- Upon the addition and confirmation of any requested adjustments of the draft report provided at the end of the security review period and fix period (within 2 weeks), the report will be considered final and delivered via the client's private discord channel with the core team. [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/final-report-delivery#what-does-a-spearbit-report-look-like) What does a Spearbit report look like? ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To better understand how a Spearbit report is constructed, we highly recommend viewing our [**portfolio**arrow-up-right](https://github.com/spearbit/portfolio) where many of our client reports are public and viewable. The structure of our security review reports typically follow the format as shown below: * Spearbit Overview * Client Overview * Risk Classifications * Executive Summary * Detailed Findings Breakdown [PreviousFix Periodchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period) --- # Kickoff | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/kickoff#kickoff-call) Kickoff Call ------------------------------------------------------------------------------------------------------------------ The kickoff call will have all relevant stakeholders including the security review team, core team, and key members from the client. From this kickoff all parties should come away with clear actionable items and goals to be communicated over the duration of the security review period. Additionally the kickoff will serve for any parties to clarify and confirm alignment with one another prior to the review team beginning their work. [PreviousSOW & Rateschevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/sow-and-rates) [NextSecurity Review Periodchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period) --- # SOW & Rates | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/sow-and-rates#sow) SOW ------------------------------------------------------------------------------------------------------ The SOW will contain the following for the client to confirm and agree prior to the start of the engagement. This includes but is not limited to: * Scope of Work (Final Commit Hash) * Price and Payments * Client Responsibilities * Legal Frameworks * Key Deliverables * Timelines * Engagement Work Flow * Researcher Team Breakdown After both parties have signed the SOW, a private channel with the security review team and the client's team will be created in the Spearbit Discord to optimize communication. [PreviousCommunication Channels and Accesschevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/communication-channels-and-access) [NextKickoffchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/kickoff) Last updated 2 months ago --- # Close-out Call and Walkthrough | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/close-out-call-and-walkthrough#close-out-call) Close-out Call --------------------------------------------------------------------------------------------------------------------------------------------- The Close-out call will have all relevant stakeholders including the security review team, core team, and key members from the client. From this close-out call, all parties should come away with a clear understanding of what occurred during the security review period and the vulnerabilities identified by the security researchers. All expectations and deliverables initially communicated during the kick-off should now be met and closed out. Additionally, clear and actionable next steps should be established moving into the remediation of the vulnerabilities identified as the engagement moves into the [Fix Period](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period) stage of the review process. A draft report will be provided for internal usage of the security review containing all valid issues as well prior to the close-out call and after completion of the security review period. circle-info **Note:** If after 1 week of receiving the report the client does not provide any comments or concerns raised, the client acknowledges the report is complete and the report will be considered final. [PreviousSecurity Review Periodchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period) [NextFix Periodchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period) Last updated 2 years ago --- # Security Review Period | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period#security-review-period) Security Review Period ----------------------------------------------------------------------------------------------------------------------------------------------------- The security review period can be considered an interactive process between clients' and their review teams as communication is often abundant when contextualizing the target scope in light of attack vectors. Regarding the security review process itself, the workflow is detailed in the following components below within the context of Github: 1. **Review Repository** 2. **Pull Requests (PRs)** 3. **Comments** 4. **Issues** ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period#review-repository) Review Repository Within the security review repository, researchers will leave comments that the client can view and interact with asynchronously. The repository is organized into various branches, reflecting the quantity of files under review. **Structure**: * Different branches are proportional to the number of files in scope. * If a file has more than 500 lines of code, it is often divided to minimize latency in Github API requests during the retrieval of issues for copywriting. ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period#pull-requests-prs) Pull Requests (PRs) Under the client's PRs, they can see the files under review and instantly get a glance at what is currently being worked on by the security review team. This is to serve as oversight for both the core team and client team to be aware of the security review's progress. ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2FqGmvc5NIKx0gYbtcbq2w%2Fimage.png&width=768&dpr=3&quality=100&sign=2b433a99&sv=2) ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period#comments) Comments Within the respective PRs - the client and core team can track comments which will serve as the main medium by which the core team will be addressing code-related matters, raising questions, and initiating technical discussions. ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2Fd0cm5BE6atSBTpjbQoBc%2Fimage.png&width=768&dpr=3&quality=100&sign=9f95f98&sv=2) Comments will serve effectively to facilitate the bulk of interactions between the review team and client regarding to the security posture of the code itself: * The client is encouraged to actively participate in discussions, capturing valuable insights from the auditors. * The incremental approach of commenting on code as discoveries are made facilitates the client's team in addressing and clarifying issues early in the process. * Once a conversation concludes, a formal issue is created with the client's commit fix (or a comment explaining a decision not to fix), and any relevant discussion between the client and the auditors. * Regular monitoring of the security review repository for notifications is highly suggested. ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/security-review-period#issues) Issues Once a finding from a pull request's comments is confirmed and finalized by the client, it is turned into a Github issue. The review team will then attach an accompanying severity and/or status label as shown below: ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2Fxo9zDiIgOfCRfJ9GOPjy%2Fimage.png&width=768&dpr=3&quality=100&sign=5e415ebc&sv=2) **Severity** Severity is determined as follows: Severity level Impact: High Impact: Medium Impact: low **Likelihood:high** Critical High Medium **Likelihood:medium** High Medium Low **Likelihood:low** Medium Low Low Severity will fall under the following labels: * Critical Risk * High Risk * Medium Risk * Low Risk * Gas Optimization - opportunity for reduction of gas costs * Informational - room for optimization not impacting security directly **Status** * Acknowledged * Fixed * ReadyForReport Upon reviewing an issue, they are reviewed and labeled as Fixed or Acknowledged, contingent on the client's response. These issues will eventually become part of the final report. ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2FB7vsdf76jTEi1TPdjS4O%2Fimage.png&width=768&dpr=3&quality=100&sign=794541a1&sv=2) [PreviousKickoffchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/kickoff) [NextClose-out Call and Walkthroughchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/close-out-call-and-walkthrough) --- # Fix Period | Spearbook [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period#fix-review-period) Fix Review Period ------------------------------------------------------------------------------------------------------------------------------- A 2-week fix review courtesy period is initiated to allow the client to implement fixes and have them reviewed by the security review team. This process is consultative and collaborative in nature and we urge clients to take full advantage of this courtesy period. ### [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period#extensions-and-conditions) Extensions and Conditions In the event that fixes are not fully reviewed after 2 weeks, the client can request an extension period by signing a fix-extension Statement of Work (SOW). circle-info **Note**: One Pull Request (PR) should be created per issue to facilitate reviewing the fixes. The researchers on the review team will work on a stand-by basis and won't be engaged full time. Should the fixes alter the protocol's behavior or aren't related to the issue, a new SOW must be signed. [hashtag](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/fix-period#labeling-fixes) Labeling Fixes ------------------------------------------------------------------------------------------------------------------------- The client is advised to follow a specific labeling methodology as issues progress through different statuses. **Status Labels** * **Changes Requested**: Spearbit team uses this label for issues with the fix applied but requiring alterations. Once the client applies the changes to the PR, this label can be removed and replaced with Status: Changes Applied. * **Changes Applied**: Informs the Spearbit team that a change has been approved, requiring an updated label of Status: Verified by USERNAME. * **Verified by USERNAME**: Tagged if validated by a Spearbit security researcher or re-add Status: Changes Requested if new alterations are necessary. * **Fixed**: Applied if the project has fixed the issue. * **Acknowledged**: Applied if the project has acknowledged the issue without further action. * **ReadyForReport**: Used to confirm the issue is ready for the client report. circle-info **Note:**In either case (verification or more changes), **Changes Applied** can be removed by the Spearbit team. The label swapping may continue for several rounds until the Spearbit team approves/verifies the PR changes. **Labeling Example** ![](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2FjOs2PFdjxRTVFFaPgRD9%2Fimage.png&width=768&dpr=3&quality=100&sign=aea7230a&sv=2) [PreviousClose-out Call and Walkthroughchevron-left](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/close-out-call-and-walkthrough) [NextFinal Report Deliverychevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/final-report-delivery) --- # Anatomy of a Spearbit Review | Spearbook ![Page cover](https://docs.spearbit.com/~gitbook/image?url=https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2FYpEUMjDBr2rrH1FdF73w%2Fblobs%2F7EkzIbYOeWIIHmDfTSqy%2FConcept.jpg&width=1248&dpr=3&quality=100&sign=f4392560&sv=2) [hashtag](https://docs.spearbit.com/spearbook#to-our-community) To Our Community ------------------------------------------------------------------------------------- Spearbit’s methodology for performing reviews has delivered **consistent industry-leading quality of results at scale** for web3 security reviews. As a result, the intention of this outline is to provide web3 security researchers and firms alike with a strong and standardized methodology for success in the coordination of engagements. [hashtag](https://docs.spearbit.com/spearbook#to-our-clients) To Our Clients --------------------------------------------------------------------------------- This breakdown serves to inspire confidence in the depth of the Spearbit review process and to provide insights into how to best prepare for your own Spearbit review in order to maximize the benefit to your project. circle-info During the review process it's crucial for all parties to be aware of requirements, next steps, and the current status of the engagement to prevent scope creep or misalignments on objectives. [hashtag](https://docs.spearbit.com/spearbook#engagement-flow) **Engagement Flow** --------------------------------------------------------------------------------------- Below is an overview of the Spearbit engagement lifecycle: 1. Form Submission 2. Scoping and Information Gathering 3. Communication Channels and Access 4. SOW & Rates 5. Kickoff 6. Security Review Period 7. Close-out Call and Walkthrough 8. Fix-Period 9. Final Report Delivery [NextForm Submissionchevron-right](https://docs.spearbit.com/spearbook/anatomy-of-a-spearbit-review/form-submission) Last updated 2 months ago ---