Policy

A policy turns your supply chain rules into data that SafeDep tools apply to each package. You write a rule once, and the tools apply it the same way on every machine and in every check. SafeDep has two kinds of policy. They differ in where they live, who changes them, and which tools read them.

​

The cloud policy

The cloud policy is one policy for each tenant. It lives in SafeDep Cloud, and an Admin of the tenant changes it with the safedep CLI. A change reaches every endpoint and every pull request check of the tenant with no new MDM package. The cloud policy holds two kinds of content:

• Policy settings are typed values, such as the dependency cooldown or the lowest vulnerability severity that fails a pull request check. Settings come in layers: the SafeDep default policy, the policy base of the tenant, and policy overrides for groups of endpoints and projects. See Policy Resolution.
• Package rules are block entries and trust entries for packages. See Package Rules.

Each publish makes a new policy revision. Each decision that a tool makes with the cloud policy names the revision and the rule or setting that decided. So you can explain a block, roll back a bad change, and show an auditor which policy applied on a date. These tools enforce the cloud policy:

• PMG on developer machines and CI runners applies the package rules and the dependency cooldown.
• The pull request check of the SafeDep GitHub App and the Bitbucket app applies the scan gate settings and the package rules.
• Vet does not read the cloud policy yet.

​

Policy as code

Policy as code is a Vet filter suite: a YAML file of CEL rules that you keep in a repository. Vet evaluates each package of a scan against the rules, including transitive dependencies, and you decide what a match does. During a local scan, Vet can exit with a non-zero code when a package matches a rule. In CI/CD, vet-action takes the policy file in its policy input. See Policy as Code for the syntax and examples.

​

Compare the two kinds

​

Related