Tune policy and enforce

Decide what fails a pull request, make Socket visible to developers, and require the check only on the repositories you pick.

Roll enforcement out in three moves: tune the policy against your baseline, turn silent mode off, then make the Socket check required on pilot repositories only. Everything else keeps getting comments without being blocked.

Before you start: a baseline for your repositories (Connect your repositories) and a passing pull request test.

1. Tune the policy against your baseline

Pull request checks and the Firewall read the same Socket policy. Policy config covers how to change actions. For pull requests, what matters is which alerts are set to Block (fails the check) and Warn (comments only).

The Default policy starts on the Balanced baseline: known malware is blocked, critical vulnerabilities warn, and supply chain risks such as typosquats and git or URL dependencies are added on top. Most POCs keep it.

To see what developers will meet first, open Alerts and filter Severity to Critical and High. If an alert type is noisy and you don't want it in pull requests during the POC, set it to Monitor. It stays in the dashboard and leaves pull requests alone.

🚧

The Default policy also drives the Firewall

Install-time requests aren't tied to a repository, so the Firewall uses the Default policy. If you run the Firewall too, a change to Default changes what installs are blocked. To change pull requests on some repositories only, use a separate policy (step 4).

2. Turn silent mode off

In the dashboard, open Settings → GitHub and turn Silent Mode off.

🚧

This is organization-wide

Every repository the app can see starts getting Socket comments for Block and Warn alerts, and a Socket check. Tell engineering before you flip it. A failing check does not stop a merge until step 3.

3. Require the check on pilot repositories

Branch protection is set per repository, which is what keeps enforcement to the repositories you choose. On each pilot repository:

  1. Open Settings → Branches → Add branch protection rule for main.
  2. Turn on Require status checks to pass before merging.
  3. Search for and add Socket Security: Pull Request Alerts.
  4. Save.

GitHub only lists checks that have run on the repository in the past week, so open any pull request on it first if the check doesn't show up.

🚧

Branch protection depends on your GitHub plan

GitHub enforces branch protection on public repositories on every plan. On private repositories it needs GitHub Pro, Team, Enterprise Cloud or Enterprise Server. On a free account or free organization, GitHub saves the rule for a private repository but doesn't enforce it, and shows a warning at the top of the rule page. The Socket check still fails, but Merge stays enabled. Run the POC in a repository your plan covers, or a public sandbox.

To require the check on many repositories at once, GitHub rulesets can do the same job from one place. See About rulesets.

4. Optional: a stricter policy for pilot repositories

If pilot repositories should block more than the rest, give them their own policy. Each repository is governed by exactly one policy, and the Default policy keeps covering everything else and the Firewall.

  1. Open Policies and create a policy, for example POC pilot.
  2. Pick the Comprehensive baseline, which also blocks critical vulnerabilities and risky dependency sources.
  3. Assign the pilot repositories to it.

This needs the Policies system. If your dashboard shows Settings → Security Policy instead of Policies, ask your Socket team; scoping there works through repository labels.

When a package is wrongly flagged

Resolve the alert from the alert's details. A resolution takes effect ahead of every policy rule, so the package passes on the next scan while the rest of the policy is untouched. Push a new commit (an empty one is fine) to rerun the check:

git commit --allow-empty -m "retest after Socket resolution"
git push

Agree a note format for resolutions (ticket number and approver) before the POC starts, so every exception can be traced.

Verify

  • Pilot repositories list Socket Security: Pull Request Alerts as a required check, with no plan warning on the rule page
  • The lodahs pull request on a pilot repository fails the check and Merge is disabled
  • The same pull request on a non-pilot repository fails the check but can still be merged
  • After the alert is resolved and the check reruns, it passes
  • The resolution, with its note, shows in Settings → Audit Log

What good looks like

MeasureBar teams commonly set
Wrongly flagged package clearedWithin 30 minutes
ExceptionsScoped, with a note, visible in the audit log

Reference


Did this page help you?