This past year, we’ve started investigating new approaches to our security audit reports and recently we’re experimenting with structuring the data to be more usable by additional audiences and systems, along with publishing our reports in new ways to make them more accessible.
Reports as Bitcoin Digital Artifacts
We have created Bitcoin digital artifacts to prepare for the publishing of security audit reports in the form of Ordinal inscriptions, aka NFTs – which, to our knowledge, are the first efforts made to facilitate security audit reports to be inscribed on sats on Bitcoin.
These digital artifacts are to prepare for security audit reports for reviews completed by Least Authority to be inscribed as Ordinals on the Bitcoin blockchain.
Ordinal inscription of the Least Authority Security Audit Reports root: https://ord.xverse.app/inscription/48409fb0cc71da0de488298a45a5948a317dba6f94ba3e4d53834ee2837c532ai0
Digital Artifacts
By publishing the security audit reports as digital artifacts, we are making them more accessible and providing further utility. The data in the digital artifact is more machine-readable compared to the PDF file format. Additionally, the data is immutable on the blockchain and therefore more suitable for archival purposes.
These digital artifacts are similar to NFTs (non-fungible tokens) on other blockchains. However, there are some technical properties that differ from other variations of NFTs.
From docs.ordinals.com:
“Inscriptions inscribe sats with arbitrary content, creating bitcoin-native digital artifacts, more commonly known as NFTs. Inscriptions do not require a sidechain or separate token.
These inscribed sats can then be transferred using bitcoin transactions, sent to bitcoin addresses, and held in bitcoin UTXOs. These transactions, addresses, and UTXOs are normal bitcoin transactions, addresses, and UTXOS in all respects, with the exception that in order to send individual sats, transactions must control the order and value of inputs and outputs according to ordinal theory.”
Reaching New Audiences
This transparency allows security audit reports to be more accessible to other stakeholders that are impacted by the security of the tools we use, beyond the developers that are improving the security of their project.
The primary audience of our security audit reports for clients include:
- Product/project development teams or outsourced developers;
- Decision makers within the product/project team; and
- Investors in the product/project.
Beyond these direct beneficiaries of our work, there are other potential stakeholders who are interested in the efforts undertaken and the results of a security review, such as:
- External developers who are building on top of or integrating with the product/project;
- End users that are interested in actively understanding and managing their security risks;
- Potential clients of security audits looking to assess which firm is the right fit for them;
- Security researchers, third party security monitoring companies;
- Governments, regulatory bodies and other organizations interested in compliance; and
- Independent organizations that act as watchdogs for specific communities, including marginalized communities.
Each of these audiences have different interests and uses for the data. Consumption of the data contained in the reports is ad hoc, inconsistent and often varies in the timeliness. As a result, there is information asymmetry outside of the project team and security risks are misunderstood, concerns are misplaced and, in unfortunate cases, value is lost through hacks.
The Unsatisfactory Status Quo
There are multiple ways to increase the effective use of the information in security audit reports by all stakeholders, including enhancing the accessibility of the data to be machine-readable and improving the usability of the data for the different use cases.
For the past decade, we’ve been publishing our reports on our website in an effort to increase transparency of our work and promote our clients’ efforts. These reports are nearly all published as PDFs or within a GitHub repository. These publishing approaches have numerous limitations that challenge the data being consumed beyond the reading of the reports by the client teams. The information is structured for the main audience and is not easily translated to the additional stakeholder audiences, the data is not formatted to be machine-readable, and the data is not easily consumed by other systems for extendable use, including the combination with other data and more user-friendly displays.
Additionally, when reports are published on privately operated websites, it exposes them to issues, such as changing business priorities and other external influences to their longevity. The security research that is detailed in the audit reports is often innovative, and the review targets are products/projects with the intention of being decentralized public goods. If there is a greater public value for this data then the data should be accessible regardless of the outcome of a few businesses that initially produce and host these reports – just like the products/projects that are being reviewed, they should also be public goods.
A Vision for Security Research Results
By publishing our reports in new formats and on new platforms, we can address the issues noted above. For example, by restructuring the content of a report to be more machine-friendly, we can allow it to be accessible to other systems, which can combine it with different data for analysis and display the data in ways that make it more understandable by their particular audiences, thus offering additional value. Further, by utilizing more decentralized platforms for publishing, we can ensure greater accessibility by different communities and increase the potential longevity of the data by utilizing the properties inherent to these platforms.
We list below a few examples that illustrate how the information included in security audit reports can be utilized by the stakeholders noted above, if they are published on a public blockchain or other decentralized system:
- External developers who are building on top of or integrating with the product/project;
- A Layer 2 development team can stay more up to date with the security efforts and reasoning for the resolutions implemented on Layer 1, including monitoring for and addressing vulnerabilities with dependencies.
- An exchange could display security information about tokens on the trading pages of those tokens, allowing investors to make well-informed decisions.
- End users that are interested in actively understanding and managing their security risks;
- A wallet user could see the most recent security profile of the wallet before performing certain transactions and make decisions based on their personal threat model.
- Security researchers and third party security monitoring companies;
- Security experts could ingest data from multiple sources and analyze the information to identify trends in security exploits and compare them to research completed.
- Governments, regulatory bodies and other organizations interested in compliance;
- A compliance organization could receive real-time notifications about audits completed for projects they are responsible for monitoring.
- Independent organizations that act as watchdogs for specific communities, including marginalized communities;
- A consumer protection group could compare the security improvement efforts undertaken by products to the marketing efforts made to their target groups.
These are just some basic examples of how security report data can be more effectively and extensively used by other stakeholders, although not exhaustive. Granted, these examples are already possible today since the reports are published. However, it is not manageable to witness results at an impactful scale without investing significant manual efforts. There is no lack of technology to make this possible, it just requires the innovation of how we deliver the data and the worthwhile goal of further improving the security of the technology we use. We intend to do this through our efforts.
As illustrated by our current, traditional list of published audit reports, we value the transparency and accountability that comes with making our security audit reports available to the public. We encourage our clients to publish their reports, in general, because the visibility of their efforts taken to secure the tools we depend on and the open access to advancing security information is important.
Stay tuned for more work by us in these directions and reach out to consulting@leastauthority.com if you’d like to experiment with us!