Security Consulting FAQs
Get in touch to learn more about our security consulting services.
Or email us at consulting@leastauthority.com
Overview of Services
We provide three main types of security consulting engagements:
- Security Audits: This service is most suited for teams whose implementation is mostly feature complete and are looking to increase security at any time, including prior to an important milestone in their roadmap (e.g. a mainnet launch or a token sale). These audits can take up to 8 weeks.
- Limited Security Evaluations: These security consultations typically take 1-3 days and are most suited to teams who need help assessing the security of smaller, self-contained systems (e.g. authentication flow, encryption scheme, etc.). They can also provide insight into the security risks presented by a third-party solution as part of a due diligence assessment.
- Security by Design Consulting: This involves recommendations on how to better integrate security considerations into the system design, development processes, the roadmap, and the project’s overall mission. We can assist with Security by Design, to mitigate the potential for serious security issues emerging later in the software development life-cycle.
The goals of our security audits are to improve the quality of the systems we review and reduce the security risks. We do so by investigating and analyzing systems in order to identify potential vulnerabilities and assist with remediation or mitigation strategies.
Security audits are important because they:
- Help development teams identify, understand and address security risks;
- Demonstrate due diligence to stakeholders (e.g. users, exchanges, investors, etc.) by providing increased assurance that security is a priority;
- Contribute to increasing the number of secure tools in our ecosystem, which benefits the users; and
- Educate the community and broaden our collective knowledge on common attack vectors and areas of vulnerability within various types of systems.
A list of audits we have completed and published is available here. However, this is not a complete list of the work we have done, since some clients choose not to publish their reports. If you don’t see a project comparable to yours on that list, we may still be able to help you.
We recommend that systems undergo security audits once the coded implementation is feature complete and prior to launching a major release and/or significant feature updates to the code. Regular audits at development milestones are an important step towards having a degree of assurance that a system has reduced security risks.
Regular reviews of the code are particularly important if the system significantly relies on dependencies for core functions or in areas of high impact. Checking that dependencies have been regularly audited and well maintained is critical in assessing whether malicious code has been introduced into the codebase through the use of third-party code.
Security should also be prioritized throughout the design process (i.e. Security by Design) as it will help mitigate the potential for serious security issues emerging later in the software development life-cycle. Addressing fundamental design issues is more costly to remediate once the system has been implemented. Engaging auditing teams in security design reviews prior to implementing the system will help ensure the system fulfills its intended requirements more securely.
All security audits are customized to best fit the subject matter and the specific needs of the client’s team. However, a typical auditing process is detailed in the following table.
Stages | Description | Timeframe (Approximate) | |
1 | Contact Us | Get in touch for a free, no-commitment consultation to learn more about our security consulting services and provide you with information on our process. You can schedule a call or email us consulting@leastauthority.com. | Anytime |
2 | Proposal | If you would like to see a customized project plan and/or cost, we ask that you provide us with more information on the project (code, documentation, etc.). We then provide a security audit proposal. This includes a proposed scope, areas of concern, schedule, and cost for the review. | Within one week of receiving project information |
3 | Code Review | At this stage, we review the code, read design documentation, review other audit results or resources, and generally prepare for where vulnerabilities may be present. We will log our efforts to find vulnerabilities and related potential issues. Throughout the project, we will hold meetings and share notes as appropriate, depending on the process and focus of the investigations. We will also note how any issues that we do find could be mitigated or resolved. | 1 day – 8 weeks |
4 | Initial Audit Report | During this stage, we complete our investigative work, document any unresolved issues or open questions and suggested resolutions in the report. This initial report is intended for internal use only, since it could contain sensitive information about vulnerabilities. A meeting between your development team and our security researchers to discuss the results of the report is recommended at this stage. | According to the agreed upon schedule in the proposal |
5 | Response and Remediation | After delivering the report, we will be available for consultation, as needed. The mitigation and remediation recommendations should be scrutinized by the client’s development team and deployment engineers. Successful mitigation and remediation is an ongoing collaborative process after we deliver our report, and before the details are made public. | TBD by the client’s development team |
6 | Verification | When the client’s development team believes that all issues with sufficient impact have been addressed, we will review the system to confirm that these changes have been made. It may be the case that some resolutions need to be discussed further because of the nature of design, code, operational deployment, and other engineering changes, as well as mistakes or misunderstandings. | ~1 week |
7 | Final Audit Report | We will update our report to reflect the resolved or mitigated status of any issues in the initial report. We will collaborate with the client’s development team to make sure we all can agree that the report is appropriate to share publicly, while remaining transparent about and true to our original findings. Only after we agree with the development team that all vulnerabilities with sufficient impact have been appropriately mitigated do we publish our results, with their consent. | Immediately following the completion of the verification |
Following the initial contact with your development team and once you provide us with the information we need to provide you with a proposal, we will determine the audit schedule and include it in the security audit proposal (usually within one week).
Security audit schedules can range from several hours to several weeks. If we think a project will benefit from shorter review timeframes, we will recommend limiting the scope and splitting the security audit into multiple phases. This allows us to provide audit results within a more reasonable time frame for development teams and limits the amount of time for a code freeze.
Security consulting engagements can vary greatly in cost. Design reviews and other smaller engagements will have a lower cost, whereas multi-phase security audits of large and complex systems will have a much greater cost.
Our proposals for security audits include a fixed price that will not change unless the scope of the project changes. We calculate this cost to include some flexibility for our team to work most successfully at identifying security issues with the system. This cost is not based solely on or limited to a specific number of person-days, although we do include a schedule. We take this approach in order to adequately cover the audit scope and may assign additional team members as needed during the course of the audit. We find that the quality of our work is benefited by having the flexibility to include several team members with a diverse set of skills conducting any given review.
If you have a limited budget, we suggest you mention this in the initial conversations and we can help you to develop an approach that works for all of us by offering the best value for the budget you have.
We realize that sometimes teams do not have their own funding available to cover the cost of a consulting engagement or security audit. In these cases, there are third-party funders for the project. We are usually willing and able to work with such third-party funders. However, if you don’t already have third-party funding, the following is a list of potential organizations to look into:
- Foundations related to specific blockchains, such as the Ethereum Foundation, usually have various grant programs that accept applications for funding security reviews.
- The Open Technology Red Team Lab offers funding for security audits for Internet Freedom projects. (Note, we are not currently a member of this program.)
- Gitcoin offers a crowd-funding mechanism for projects.
We do not endorse or have agreements with these organizations to refer particular projects. As a result, we do not recommend any particular mechanism or third party.
Audit Preparation
Our team has a diverse set of skills, allowing us to work on a broad range of projects. Our language skills include, but are not limited to, C, C++, Python, Haskell, Rust, Node.js, Solidity, Go, Java, JavaScript, Lisp, TypeScript, C#, Swift, Kotlin, Perl, Ruby, OCaml, Michelson, LIGO and SmartPy. In some cases, we are also able to learn new languages to be able to audit systems utilizing new languages and / or technologies.
The types of technologies we are able to audit include (but are not limited to): blockchain protocols, consensus algorithms, decentralized exchanges, Decentralized Finance (DeFi) protocols and platforms, ledger applications, mobile applications, browser extensions, new tokens, P2P networks/components, privacy enhancing technology, smart contracts, wallets, web applications, Zero Knowledge Proofs, and other decentralized systems.
A list of audits we have completed and published is available here. However, this is not a complete list of the work we have done, since some clients choose not to publish their reports.
For code reviews, our team will target a specific commit for the duration of the audit. We encourage the client’s development team to factor this into the planning processes. By getting in touch with us early in the development phase, we can help you anticipate the most suitable time to get a security audit, thereby minimizing any unnecessary interruptions or delays.
Our lead times change regularly and depend on the technology type and size of the project. We provide an audit schedule in our security audit proposal and the proposed schedule is based on our current availability. However, the actual dates will be determined and confirmed once an agreement is signed and we will look for opportunities to bring forward the schedule if the timeline is a priority for your team.
- Define the scope: We will work with you to define the scope of the security audit. The process can be expedited by sharing your priorities with our team along with corresponding code and/or documentation.
- Target a stable release: For the duration of the audit, we agree to an in-scope Git commit. Having a specific release ready as an audit target is critical to the success of a security audit, so our team is not reviewing a moving target, which increases the likelihood for missed security issues.
- Documentation: While documentation is not a requirement, it helps our researchers rapidly gain deep understanding of a system and increases security audit efficiency. Examples of documentation includes inline code comments, high level documentation, and system design documentation.
- Get in touch as early as possible: Contacting us earlier in the development process will better enable us to secure your desired schedule for the security audit, based on your development roadmap and milestones.
Usually we plan for just one verification phase. However, we are happy to discuss the option of conducting subsequent verifications when determining the audit scope during the proposal stage.
An invoice schedule will be presented as part of the cost section in the proposal so that you can plan your finances accordingly.
For security audits, we usually send three invoices. The following invoicing schedule generally applies to our security audits:
- The first invoice is sent once the agreement is signed and reserves our time for the audit, as scheduled.
- The second invoice is for the Initial Audit Report fee which will be sent following the completion of the Initial Audit Report, corresponding to the work that has been completed for it.
- The third invoice is for the Final Audit Report fee which will be sent following the delivery of the Final Audit Report after the verification has been completed, corresponding to the work that has been completed for it.
Yes, besides fiat payments in EUR and USD, we accept payment in BTC, ZEC, ETH, and DAI.
Audit Findings
We recommend that security vulnerabilities are addressed as soon as possible to minimize the risk of the detailed security issues. Also, since code bases typically change over time, the applicability of audit results may also change the longer they are left unaddressed by the client’s development team.
Once the client has addressed the issues documented in the Initial Audit Report, we will conduct the verification prior to delivering the Final Audit Report.
An Issue is considered a security vulnerability that, if unaddressed, could result in a compromise of the system.
A Suggestion is a best practice recommendation that will contribute to the overall security of the system. For example, we might suggest improving system documentation to ensure the system is being used correctly and/or security reviewers understand intended behavior when assessing the code for security vulnerabilities.
We list the Issues and Suggestions found during the review, in the order we reported them. In most cases, remediation of an Issue is preferable, but mitigation is suggested as another option for cases where a trade-off could be required.
The proposed mitigation focuses on what steps can be taken to reduce the risk of the specific security Issue, without removing it completely.
The remediation recommends a development path which will prevent, detect, or otherwise remove the vulnerability in future releases.
There may be multiple possible mitigation and/or remediation strategies, so we try to outline the various options and collaborate with development teams to arrive at the most pragmatic recommendation. It is important that the developers, users, and operators cautiously verify our recommendations before implementing them.
The Initial Audit Report will include information on the security issues, in addition to a sufficient mitigation and / or remediation to address the vulnerabilities. The report will also provide security best practice suggestions.
In the event that your development team decides against resolving an issue or suggestion in the Initial Audit Report, we will discuss the rationale and suggest an alternative solution, where applicable. If the issue remains unresolved, we will note that the issue is unresolved, clearly document the reasoning provided to our team, and provide our final recommendation in the Final Audit Report. If the issue has been somewhat resolved, we will mark it as partially resolved.
We list the Issues and Suggestions found during the review, in the order we reported them. In most cases, remediation of an Issue is preferable, but mitigation is suggested as another option for cases where a trade-off could be required.
The proposed mitigation focuses on what steps can be taken to reduce the risk of the specific security Issue, without removing it completely.
The remediation recommends a development path which will prevent, detect, or otherwise remove the vulnerability in future releases.
There may be multiple possible mitigation and/or remediation strategies, so we try to outline the various options and collaborate with development teams to arrive at the most pragmatic recommendation. It is important that the developers, users, and operators cautiously verify our recommendations before implementing them.
No, Least Authority cannot certify that a system is secure. The Least Authority team offers recommendations to increase the security of a system following our independent investigation and analysis on the efforts undertaken by the development team to secure a system, as reflected in the system’s implementation. The feedback and recommendations from our team will reduce the risk of a system not behaving as intended, resulting in a security vulnerability.
At the conclusion of our review, Least Authority provides an Initial Audit Report, which details any security concerns identified by our team that exist within the system, to the best of our knowledge. The development team then has an opportunity to improve the security of their system by implementing the suggested mitigations or remediations, along with implementing other suggested improvements that further reduce the risk of security vulnerabilities. Once this effort is complete, we conduct a verification review and update the report to reflect the additional efforts taken by the development team prior to delivering a Final Audit Report. This provides the report audience a comprehensive understanding of the efforts undertaken by the development team to reduce the security vulnerabilities in the system. Security audits do not provide a total guarantee of security, however, they are an important step in the process of security due diligence and demonstrate a commitment to security by the development team.
Least Authority does not provide a formal certification of security, and security audit reports should be carefully reviewed to understand the efforts taken towards improving security. In addition, systems that have undergone a security audit should be continuously reviewed and scrutinized for security vulnerabilities as the codebase changes and evolves. Development teams seeking security audits should be wary of companies claiming to provide guarantees or certifications of security.
We are proponents of transparency and open source contributions, and encourage our clients to publish their Final Audit Reports. However, we caution teams to not publish the Initial Audit Report, without a thorough assessment of the contents of the report and whether the details could be used negatively.
We will only publish the Final Audit Report with permission from the client. If the client chooses to publish the report, we will post it on our website. All parties to the agreement will have an opportunity to discuss and agree upon details prior to publication.
There are some exceptions to this according to our policy on responsible disclosure.
After verification is completed and the Final Audit Report is delivered, public release of the report is optional and dependent on agreement from both teams. The process for publication usually includes a short blog post, along with a link to the Final Audit Report on our website. All parties to the agreement will have an opportunity to discuss and agree upon details prior to publication.
We are committed to helping our clients improve the security of their systems and will work to ensure they have the appropriate information and time needed to address threats and vulnerabilities identified during our security audit. In an effort to stay true to our mission of promoting ethical practices as it relates to security and privacy, we also have a responsibility to the developers, users, and broader community utilizing the tools and technologies that we audit. For this reason, we adhere to the principle of responsible disclosure.
In support of this effort, we first provide the client’s development team the opportunity to address any issues prior to publicly disclosing our findings. In the event that our client is a third party (i.e. neither the development team nor related to the team responsible for addressing the issues found during the audit) we reserve the option to disclose any issues discovered during our review to the development team to allow them the opportunity to sufficiently address and respond to the issues prior to sharing our findings with the third-party client. In the event that issues are not addressed by the development team in a timely manner and users are at risk, we also reserve the right to publicly disclose our findings.