Migrating to Policies
Socket's Security Policy and Alert Triage Rules are being replaced by Policies and Resolve Alerts. Socket migrates your existing configuration for you, and shows you the result before anything takes effect.
The migration is rolling out to every organization. It is being enabled organization by organization, so if you do not see it yet, you will — there is nothing to request and nothing to install. When it is enabled for you, a banner on the alerts and policy pages lets you start.
This page explains what changes and how the migration works. If you have scripts or integrations calling the legacy endpoints, see Updating API Integrations.
What Changes
| Legacy | Replacement |
|---|---|
| Security Policy — one organization-wide action per alert type, optionally overridden per repository label | Policies — one policy per group of repositories, each holding an ordered list of rules plus a baseline preset |
| Alert Triage Rules — pattern rules matching on package and alert attributes | Policy rules — conditions across finding, location, and artifact fields |
| Triage entries that ignored a specific finding | Alert resolutions — with a recorded reason, a reviewable scope, and a Resolved tab |
| Per-label policy overrides | Policy scope: each policy is backed by a repository label, and each repository belongs to exactly one policy |
Two differences are worth knowing before you look at your converted policies:
- Rules are ordered, and the first match wins. The legacy systems resolved an alert by looking up its type and applying whichever entry was most recently created. A policy is an ordered list you read top to bottom, so the position of a rule is part of what it means. Your converted rules are arranged to preserve the behavior you have today.
- Nothing is implicit. Where the legacy system applied behavior silently — most notably downgrading unreachable Block and Warn alerts to Monitor — the migration writes that behavior out as an ordinary rule you can see, edit, or delete.
How the Migration Works
- Start from the prompt. When the migration is available for your organization, a "Meet new Policies" banner appears on the alerts and policy surfaces, along with a card in the sidebar.
- Preview. Choosing Preview converts your configuration and opens the Policies page in preview mode, with a banner making clear that nothing here is live yet. The preview is read-only: your existing Security Policy and Alert Triage Rules keep running unchanged, and nothing takes effect until you confirm the switch.
- Review the converted policies. You get a Default policy plus one policy per repository label in your organization. Each is given a baseline preset chosen to match your existing configuration, with your converted rules above it. Read them top to bottom — the order is the behavior.
- Update. Choosing Try new policies and confirming performs the cutover. The confirmation dialog asks you to acknowledge that your rules migrate immediately and that the legacy settings pages are removed. Socket Firewall will use the Default policy for requests that are not tied to a repository.
- After the cutover. Policies become editable, the legacy pages are gone, and Socket asks for feedback on the new experience.
You have a 30-day migration window, starting when the migration is enabled for your organization. Your dashboard shows the exact date your window ends. If you have not migrated yourself by that date, Socket migrates your organization for you — the same conversion, just without the review step.
What the Migration Converts
Your Security Policy becomes policy rules. Each policy is matched to the baseline preset closest to your configuration, and every alert type where you deviated from that preset becomes an explicit rule. Repository-label overrides become their own policies, so a label that had its own Security Policy keeps its own behavior.
Triage rules become policy rules. Entries that changed the action for a class of packages — by ecosystem, package, version, CVE, severity, reachability, fix availability, or CISA KEV membership — are converted into rules with the equivalent conditions, ordered so the entry that would have won before still wins.
Triage entries that ignored a specific finding become alert resolutions. These move to the Resolved tab, where you can review them and restore any of them. They are recorded as migrated from legacy alert triage, so they are easy to find.
Implicit behavior becomes an explicit rule. If your organization downgraded unreachable alerts to Monitor, the migration adds a rule that does exactly that — matching the alert types you were blocking or warning on, with reachability unreachable, action Monitor. Policies have no hidden downgrade of their own, so this rule is what preserves the behavior. Delete it if you no longer want it.
After the Cutover
The legacy Security Policy and Alert Triage Rules pages are removed, and the legacy endpoints stop accepting writes. If you have automation that configures them, update it before you migrate — see Updating API Integrations.
Everything else keeps working. Repository-level socket.yml configuration is unaffected and still takes precedence over policy rules. Alerts you had already suppressed stay suppressed, as resolutions.
Frequently Asked Questions
Does migrating change how my alerts are handled?
The migration is built to preserve your current behavior, and it shows you the converted policies in preview before anything takes effect. Where the legacy system was implicit, that behavior becomes a visible rule rather than changing.
Can I go back?
Preview is fully reversible: nothing changes until you confirm. After you confirm, the legacy pages are removed. If something looks wrong after the cutover, contact Socket support.
What happens to alerts I had already triaged?
Suppressed findings become alert resolutions, which is where suppressed alerts live in the new system. You can review them on the Resolved tab and restore any of them. A resolution matches on the finding's scope — repository, package, version, alert type — rather than on one historical alert, so it keeps working even for a suppressed alert that has not surfaced in a long time: if it reappears, the resolution still catches it.
Do I need to change my socket.yml?
No. Repository-level configuration is unaffected and continues to take precedence over policy rules.
What about Socket Firewall?
Firewall requests are not tied to a repository, so they use the Default policy. Make sure the Default policy reflects the protection you want at install time.
Related Pages
Updated about 20 hours ago