# Using in organizations and businesses
`cargo-crev` is being developed with an explicit goal of supporting teams,
groups, businesses and even very large organizations. It is our belief that
companies developing software using Open Source code, have an important need to
ensure integrity and trustworthiness of Open Source code they include.
Because of that belief, we encourage groups interested in using `crev` to voice
their opinions and needs, so we can address them as fast as possible. We're
hopping that by making `cargo-crev` useful for them, we can quickly bootstrap a
vibrant ecosystem of code review.
This document describes the general vision of how to utilize `cargo-crev` in a
software organization. A general knowledge of `cargo-crev` might be helpful, so
make sure to read [Getting Started Guide](../getting_started/index.html) first.
## Overview
Tho utilize `cargo-crev` in your organization follow the following steps:
First, a Web of Trust for the organization has to be built. A WoT starts and is
defined by a root identity, so this step means securely creating a root
identity, and deciding on how to build and maintain over time its WoT.
Then, a method of storing and circulating *proofs* generated by the members of
the organization has to be established. This typically means preparing one or
more git repositories.
At this point members can start reviewing dependencies and creating review
proofs.
The final step is to enforce code review policies automatically - for example in
the CI pipeline.
## Root identity
It's important to take security into consideration when creating the root
identity. Because of that it's recommended that it is created on a trusted
computer, by a trusted member(s) of the organization (eg. a security officer).
Care must be taken to properly store and secure the private key of this
identity.
The purpose of this ID would is to serve , and it is typically going to be used
only passively.
Root identity is usually used passively as a root of trust for the whole
organization. It will only be actively used to sign new *trust proofs*: adding
(or removing) other identities used inside the organization.
The identities used by the individual contributors can be self-created, and
managed by their respective owners. After creation they can be submitted for
inclusion into the WoT of the organization.
In case of a very large organization, a hierarchy of identities can be
established with intermediate identities managed by particular groups and teams.
This can help distribute the process of signing identities, and help keep the
root identity offline and secure.
## Proof management
A shared git repository can be used for all identities within the organization.
Alternatively each individual can use their own git repository to publish their
reviews.
Depending on the code review policy, proofs created by individual contributors
can be internal, or publicly available. Sharing code reviews with wider
community can be a proof of a conscious approach to security, and a form of
giving back to the community.
## Enforcing code review policy
`cargo-crev` implements dependency trust verification from the perspective of an
arbitrary identity.
``` text
cargo crev crate verify --for-id <rootID>
```
is the basic way to verify review status of all the packages from the
perspective of the `rootID`. This can be used locally by every developer. It can
also be set up as a part of a CI pipeline - the returned exit code will signal
the verification status.
Other configuration options can define the exact details required for passing
the verification: number of reviews required, minimum thoroughness, etc.
## Help us help you
We're very interested in improving `crev` project to be more suitable for
organizations. Please create a github issue, or contact us on the gitter channel
to discuss your needs.