Security Audit Log and Tracking

1

AppSec and engineering teams have been discussing and working on what pieces of code have been audited (and vice versa) to make it clear for the benefit of the ecosystem. Please find the AppSec team’s proposal below and kindly provide your input.

In the Rust ecosystem, there are some advantages of using cargo-vet and cargo-audit, so the AppSec team has been keeping an eye on it. The idea of having a repository that Rust installations can consume to detect (un)audited packages while installing different pieces of Polkadot, Substrate and more; The logic behind it:

  1. We have often observed a redundancy in company audits, where multiple firms repeatedly scrutinize the same piece of code or software package to ensure its reasonable safety for use. For the sake of transparency, it’s crucial to distinguish between internal and external findings in the tracking and reporting of vulnerabilities. This distinction should be clearly communicated in a public statement from Parity, Ecosystem, or the auditing company, detailing whether the findings were identified by security experts or were part of a quality and performance review. This clarity is essential as both types of audits are important but serve different purposes. In the same vein, some of the findings are under Parity’s disclosure process. On the other hand, other projects such as ink!, have run public audits with OpenZeppelin with public results.

  2. With the monorepo and the introduction of semver for small feature packages, it is possible to implement following two ideas:
    a. Using cargo-vet to keep a track of specific crates of polkadot-sdk code being audited, as audits do not audit (not that we know!) the whole codebase, and probably will not be the case with the monorepo now.
    b. Using GitHub Security Advisories to publicly disclose known vulnerabilities (specially for legacy versions). This can help developers be aware of common issues in the development of polkadot-sdk. An example of this can be seen in the frontier repository. By sharing the vulnerabilities in GitHub, they will be assigned automatically a CVE ID and considering the vulnerabilities are constraints to specific versions of the respectives packages affecting, a developer will be able to use cargo-audit in their runtimes to check if any of the dependencies contains known vulnerabilities.

  3. This initiative might mark the beginning of a wider effort, not limited to Parity, aimed at maintaining and incorporating audit sources for the community, including Parachains and new projects. The goal is to establish a more robust and transparent audit verification process. The concept is to launch an audit repository, which would then be sustained by developers within the ecosystem.

7 Likes