Introducing Repository Labels and Security Policies

Managing a growing number of repositories across multiple teams can get messy. Whether you’re trying to reduce alert noise from legacy projects or apply stricter controls to your most sensitive codebases, a one-size-fits-all security policy doesn’t cut it.

That’s why we’re excited to introduce two powerful new tools designed to help teams bring order and control to their repo sprawl: repository labels and label-specific security policies.

Organize your repos, your way — with custom labels and policies

A common request from Socket customers has been to have a better way to organize repositories and apply repository-specific security policies.

For example, a customer may have several repositories that are effectively archived or deprecated. For these repositories, customers may prefer a more relaxed security policy that doesn’t surface alerts with the same severity as for more mission-critical projects.

Or more simply, a customer may just have a large number of repositories. This can make it difficult to identify which repositories belong to which teams, or to group repositories based on technical stack or maintenance status.

We’re now releasing two new tools to improve this workflow:

1. Repository labels: apply a label to a repository to help sort, search, and filter by that label.
2. Label security policies: apply a custom security policy to a label, which affects all repositories with that label.

To use this new feature, click “Repositories” in the navigation sidebar and then the “Labels” tab:

The same label can be applied to multiple repositories, and each label can have a security policy which overrides the default organization-wide security policy. Multiple labels per repository are currently not supported.

Labels can then be used to sort, organize, and search repositories:

For customers who prefer to automate this process with scripts, a full public API is available. This API allows for creating, deleting, and modifying repository labels and their security policies, and for applying those policies to different repositories.

All label-level security policies immediately take effect when associated with a repository. The organization-wide security policy will still continue to apply as before for repositories without a label, or for labeled repositories without a security policy.

There is no inheritance between the organization-wide security policy and label-level security policy: if a label-level policy is enforced, then the organization-wide policy has no effect.

In the future, we plan to add additional enhancements to this feature, but we’re excited enough about the use cases that it unlocks that we’re releasing it as a public beta for feedback. Please take the new repositories labels for a spin and tell us what you think!