Policies

Policies are where you tell Socket how to react when it finds a problem in your dependencies. A policy is an ordered list of rules, applied on a set of repositories. When Socket raises an alert during a scan, it finds the policy that governs the repository, walks that policy's rules from top to bottom, and applies the action from the first rule that matches.

What a Policy Decides

Every alert Socket raises gets exactly one action. The action controls whether developers are blocked, notified, or left alone:

Action	Shows in the dashboard	Developers are notified	Developers are blocked
Block	Yes	Yes	Yes — fails the Socket check
Warn	Yes	Yes	No — passes with a notice
Monitor	Yes	No	No — passes silently
Ignore	No	No	No — allowed without notice

In the API, the Block action is written as error; warn, monitor, and ignore are written as-is.

How Rules Are Evaluated

A policy holds two layers of rules, and they are evaluated as one ordered list:

Custom rules — the rules you write, in the order you arrange them.
Baseline rules — a preset bundle of sensible defaults, underneath your custom rules.

Socket scans that list from the top and stops at the first rule whose conditions match the alert. That rule's action is applied, and no later rule is consulted. Because custom rules sit above the baseline, a custom rule always wins over a baseline rule for the same alert type — which is how you override a default without disabling the preset.

If nothing matches — neither a custom rule nor a baseline rule — the alert is ignored.

Order therefore matters. A broad rule near the top will shadow narrower rules below it. As a rule of thumb, put your most specific rules first and your catch-alls last.

Note: Alert resolutions are evaluated before policy rules. If you have resolved an alert, that resolution wins even if a policy rule would have blocked it. See Resolve Alerts. A repository's socket.yml configuration also takes precedence over policy rules.

Baseline Presets

Rather than starting from an empty policy, each policy is built on a baseline preset — a curated bundle of rules covering the alert types most organizations care about. The baseline sits underneath your custom rules, so it only decides alerts your own rules did not already claim.

Preset	What it covers
Essential	Blocks malware; warns on critical vulnerabilities and monitors lower-severity ones.
Balanced	Adds supply chain risks — typosquatting, packages pulled from git or URLs, and similar — on top of Essential.
Comprehensive	Blocks critical vulnerabilities and risky dependency sources as well; the broadest coverage across all risk types.
None	No baseline rules. Only your custom rules apply.

See Baseline Presets for the exact action every preset applies to every alert type.

The Default policy starts on Balanced, and Balanced is preselected when you create a policy in the dashboard — it is the right starting point for most teams. Choosing None means any alert your custom rules do not match is ignored, which is a deliberate choice worth making explicitly rather than by accident.

You can change a policy's baseline at any time without touching your custom rules.

Policy Scope

Policies are scoped by repository, and each repository is governed by exactly one policy.

The Default policy governs every repository you have not assigned to another policy, and it also governs requests that are not tied to a specific repository.
Every other policy governs the repositories assigned to it.

Behind the scenes, each policy you create is backed by a repository label of the same name, and a repository can carry only one label. That is why a repository belongs to exactly one policy: assigning it to a new policy moves it out of its previous one.

This makes scoping straightforward. If your production services need stricter handling than your internal tooling, create a "Production" policy, assign those repositories to it, and leave everything else on the Default policy.

Where Policies Apply

A policy's decision follows the alert to the places that act on it:

Pull request checks. An alert with the Block action fails the Socket check on the pull request. Warn and Monitor do not.
Developer notifications. Block and Warn alerts are surfaced to developers on the pull request. Monitor alerts are not — they appear only in the dashboard.
The Socket dashboard. Every action except Ignore shows in the alert views, and each alert records which rule decided it.
Socket Firewall. Install-time requests are not tied to a repository, so they are governed by the Default policy, and Firewall acts on the Block and Warn actions.
The Socket API. Endpoints that report alert actions resolve them through the same policy the rest of the product uses.

Managing Policies Through the API

Policies and their rules are fully manageable over the Socket REST API, which is useful if you administer many organizations or keep your security configuration in version control. Rules are written as Vigil selectors — the same fields and operators the rule editor builds for you visually.

See the API reference for the full request and response shapes:

Policy endpoints require an API token with organization-wide repository access. Tokens restricted to specific repositories cannot read or write policies.

Rule Conditions — every field, operator, and exception a rule can use.
Baseline Presets — the exact rules in each preset.
Drafting Rules with AI — describe rules in plain language and review Socket's drafts.
Resolve Alerts — resolving individual alerts, which takes precedence over policy rules.
Migrating to Policies — moving your existing Socket configuration to Policies.
Organization Alerts — where alerts and their actions surface.