Skip to main content
In this tutorial you publish the first policy of your tenant with the safedep CLI. The policy holds back package versions that are younger than 7 days, and fails pull request checks on vulnerabilities of medium severity or higher. Then you see PMG and a pull request check apply it.
The cloud policy needs the SafeDep Cloud Team or Enterprise plan. See pricing.

​
Before you start

1

Log in

The command opens a login page in your browser. If you have access to more than one tenant, it asks you to pick one. Run safedep auth status to see the tenant of the session.
2

Show the policy

The output shows the head revision of the policy, the open policy changes, the number of package rules, the SafeDep default policy and the policy overrides. A new tenant has no revision yet. Its policy is the SafeDep default policy alone.
3

Edit the policy

The command opens the policy settings document in your editor. The comments at the top show the layers of the policy. The document lists each field that you can set as a commented line, with its allowed values and its value now. To set a field, remove the # at the start of its line and of the lines of its parents. Make the base section of the document hold these values:
The policy base applies to every endpoint and project of the tenant. Save the file and close the editor. The command saves a policy change on the server and prints its number. Nothing applies yet. This tutorial uses change 1. Use the number that the command printed.
4

Preview the change

The preview lists each field that changes, its old and new value, and its change direction:
  • scan_gate.fail_on changes from high, the value of the SafeDep default policy, to medium. A lower severity fails more checks, so this field tightens.
  • package_admission.cooldown.min_age had no value before. A field with no value on one side counts as a change that loosens, because SafeDep Cloud cannot know what each tool did without it.
So the change loosens as a whole. The preview also counts the projects that the change reaches, and how many of them can enforce each value.
5

Publish the change

The change loosens the policy, so the command asks you to confirm. Every Owner and Admin of the tenant gets an email about the publish. The publish makes a new policy revision. To see it, run:
6

See the policy in PMG

On a machine with PMG, connect PMG to your tenant and turn on the cloud policy:
pmg cloud login asks for the tenant ID and the API key. pmg cloud sync fetches the policy at once.If pmg config set prints key not found, your config file has no cloud section. Run pmg setup install to add the missing keys of the PMG template to your config file, then run the pmg config set command again. You can also add the key by hand with pmg config edit.Then run:
The cloud policy check names your tenant and the revision that PMG applied. PMG now holds back each package version that is younger than 7 days. To see the revision that each endpoint applied, run safedep endpoint list.
7

See the policy in a pull request check

Open a pull request that adds a package with a vulnerability of medium severity, in a repository that the app scans. The check fails. The comment of the SafeDep app starts with a block titled SafeDep policy: failed. The block names your tenant revision, the scan_gate.fail_on setting with the value MEDIUM, and the vulnerability that failed the check.
You published a policy, and two tools apply it. The policy base applies to every endpoint and project. To set other values for a group, see Target a Group.

​
Next steps

Block a Package

Block a package for the whole tenant.

Target a Group

Set other values for a group of endpoints or projects.

Policy Revisions and Changes

What happens between an edit and a publish.

Apply the cloud policy in PMG

Settings, cache and offline behavior of PMG.