Curating Your Audit Set

Each entry in your audits.toml represents your organization's seal of approval. What that means is ultimately up to you, but you should be mindful of the trust that others may be placing in you and the consequences for your brand if that trust is broken.

This section outlines some norms and best-practices for responsible participation in the cargo-vet ecosystem.

Oversight and Enforcement

The most essential step is to ensure that you have adequate access controls on your supply-chain directory (specifically audits.toml). For small projects where a handful of maintainers review every change, the repository's ordinary controls may be sufficient. But as the set of maintainers grows, there is an increasing risk that someone unfamiliar with the significance of audits.toml will approve an audit without appropriate scrutiny.

For projects where more than five individuals can approve changes, we recommend designating a small group of individuals to oversee the audit set and ensure that all submissions meet the organization's standards (example). GitHub-hosted projects can use the CODEOWNERS file to ensure that all submissions are approved by a member of that group.

Evaluating Submissions

When someone submits an audit, there is no real way to check their work. So while code submissions from anonymous contributors can often be quite valuable, audits need to come from a known individual who you trust to represent your organization. Such a person should have the technical proficiency to reliably identify problems, the professionalism to do a good job, and the integrity to be truthful about their findings.

A good litmus test is whether you would permit this individual to single-handedly review and accept a patch from an anonymous contributor. The simplest approach is just to restrict audit submissions to that set of people. However, there may be situations where you find it reasonable to widen the set — such as former maintainers who depart on good terms, or individuals at other organizations with whom you have extensive relationships and wouldn't hesitate to bring on board if the opportunity arose.

Self-Certification

A natural consequence of the above is that there is no general prohibition against organizations certifying crates that they themselves published. The purpose of auditing is to extend an organization's seal of approval to code they didn't write. The purpose is not to add additional layers of review to code that they did write, which carries that seal by default.

Self-certified crates should meet an organization's own standards for first-party code, which generally involves every line having undergone proper code review. This "second set of eyes" principle is important, it's just not one that cargo-vet can mechanically enforce in this context. In the future, cargo-vet may add support for requiring that crates have been audited by N organizations, which would provide stronger guarantees about independent review.

For crates with frequent updates, self-certifying each individual release can be a chore. The wildcard audit feature is designed to address this by allowing organizations to self-certify any release of a crate published by a given account within a specified time interval.