Resolve Alerts

Resolving an alert is how you tell Socket that you have dealt with it. The alert leaves your open alerts, moves to the Resolved tab, and — this is the important part — any future alert that falls within the same scope is resolved automatically, so the same finding does not come back on the next scan.

Alerts are resolved as patterns, not one-time dismissals. That makes the scope you choose the most consequential part of resolving an alert.

When to Resolve an Alert

Resolve an alert when the finding itself needs no further action. Socket asks for a reason, which is recorded with the resolution:

Reason	Use it when
Remediated	The issue has been fixed or mitigated.
False positive	This is not actually an issue in your context.
Tolerable risk	The risk is acceptable and will not be addressed.
Other	Anything else — describe it in the comment.

You can add a comment alongside the reason. Both the reason and the comment stay attached to the resolution, so whoever revisits it later can see why the decision was made.

If instead you want to change how Socket treats a whole class of alerts going forward — "never block on low-severity CVEs without a fix" — that belongs in a policy rule, not a resolution. See Policies.

How Scope Works

Every resolution carries a scope: a description of which alerts it applies to. When you resolve an alert from the dashboard, Socket builds that scope from the alert you resolved.

Scope is built from the same three families of facts that policy rules use:

Location — the repository, or a repository label.
Artifact — the package ecosystem, namespace, name, and version.
Finding — the alert type, and identifiers such as the CVE or GHSA ID.

Leaving a dimension out of the scope widens the resolution along that dimension. This gives you a spectrum:

Scope	Covers
Repository + package + version + alert type	This exact finding, in this one repository, on this one version. The narrowest useful resolution.
Repository + package + alert type	The finding for that package in that repository, on any version — including versions you upgrade to later.
Package + version + alert type	The finding for that package version, in every repository in the organization.
Alert type only	Every alert of that type, organization-wide. Rarely what you want.

The narrower the scope, the more likely a genuinely new problem still reaches you. A resolution scoped to a single version stops covering the package the moment you upgrade — which is usually the behavior you want, because the new version is a new decision.

Resolving from the dashboard

Resolving from the dashboard is a single dialog: pick a reason, add an optional comment, and confirm. Socket builds the scope from the alert you resolved — the repository, the package, and the finding — so the same finding does not come back on the next scan.

You can also resolve several alerts at once from the alerts table. Bulk resolution is convenient but cannot be undone in bulk, so it is worth reviewing the selection first.

For control over the exact scope — widening a resolution to a whole repository label, or narrowing it to one package version — use the API, which takes an explicit scope selector.

Restoring a Resolved Alert

Resolutions are reversible. Delete the resolution — from the Resolved tab, or through the API — and the alerts it was hiding reappear the next time Socket refreshes your organization's alerts.

How Resolutions Interact with Policies

Alert resolutions are evaluated before policy rules. If an alert falls within the scope of a resolution, that resolution decides the outcome, even if a policy rule would have blocked it.

This ordering is deliberate: a resolution records an explicit human decision about a specific finding, so it should not be overridden by a general rule. It also means a broad resolution can quietly suppress alerts a policy would otherwise block — another reason to keep scopes tight.

Managing Resolutions Through the API

Resolutions can be listed, created, read, and deleted over the Socket REST API. A resolution's scope is written as a Vigil selector:

Listing is paginated with an opaque cursor: pass the previous response's endCursor as startAfterCursor to fetch the next page.

Each resolution returned by the API includes both the full scope and a set of summary fields — alert_type, repo, repo_label, artifact_type, artifact_namespace, artifact_name, artifact_version — that describe it at a glance. A summary field is null when the resolution is not limited to a single value for that dimension. A resolution covering three repositories, for example, reports repo as null, because no single repository describes it.

Repository-restricted API tokens

Socket API tokens can be restricted to specific repositories. Because a resolution can span an entire organization, those tokens are limited in what they can do with resolutions:

Creating and deleting — the resolution must be scoped to exactly one repository, and that repository must be one the token has been granted. A resolution that is organization-wide, or that spans several repositories, requires a token with organization-wide access. Attempts outside those bounds return 403.
Reading — a repository-restricted token can read organization-wide resolutions and resolutions confined to its granted repositories. Resolutions naming other repositories are not returned.

If you need to manage resolutions across an entire organization — as part of an automation or a migration — use a token with organization-wide repository access.

Policies — how Socket decides an alert's action in the first place.
Organization Alerts — the alerts views resolutions act on.
Migrating to Policies — moving your existing Socket configuration to Policies.