Rule Conditions
A policy rule matches on facts about the alert, grouped into three families:
- Location — where the dependency was found: which repository, which manifest file.
- Artifact — the package itself: ecosystem, name, namespace, version, publication date, and Socket's health scores.
- Finding — what the alert itself says: its type, severity, CVE identifier, reachability, and so on.
A rule can combine as many conditions as you like. All conditions in a rule must hold for the rule to match.
Location fields
| Field | Description | Values |
|---|---|---|
| Repository | Repository full name. Available on exceptions only — a rule's repositories come from the policy it belongs to | e.g. my-org/payments-api |
| Manifest file | Repository-relative path of the manifest or lockfile that declared the dependency | e.g. services/api/package.json |
Some dependencies cannot be attributed to a manifest file — this varies by ecosystem. A rule that conditions on the manifest file will not match a dependency Socket could not attribute, so use manifest conditions for narrowing rather than for catch-alls.
Artifact fields
| Field | Description | Values |
|---|---|---|
| Ecosystem | Package ecosystem | npm, pypi, maven, gem, golang, nuget, cargo, composer, github, vscode, huggingface |
| Name | Package name, without the namespace | e.g. express |
| Namespace | Package namespace or scope; empty for unscoped packages | e.g. @angular |
| Version | Package version | e.g. 4.17.1 |
| Date published | When the version was published | An absolute date, or a relative window such as the last 7 days |
| Overall score | Socket overall health score | 0–100 |
| License score | Socket license score | 0–100 |
| Maintenance score | Socket maintenance score | 0–100 |
| Quality score | Socket quality score | 0–100 |
| Vulnerability score | Socket vulnerability score | 0–100 |
| Supply chain score | Socket supply chain score | 0–100 |
Finding fields
| Field | Description | Values |
|---|---|---|
| Alert type | The specific Socket alert | Any alert type, e.g. criticalCVE, malware, installScripts |
| Category | The risk family the alert belongs to | supplyChainRisk, vulnerability, quality, maintenance, license, other |
| Severity | The alert's severity | critical, high, medium, low |
| Priority | Socket's composite priority for the finding | critical, high, medium, low |
| CVSS | CVSS base score | 0.0–10.0 |
| CVE ID | CVE identifier | e.g. CVE-2024-29041 |
| GHSA ID | GitHub Security Advisory identifier | e.g. GHSA-xvch-5gv4-984h |
| Reachability | Whether the vulnerable code is reachable | reachable, maybe_reachable, unreachable, pending, missing_support, direct_dependency, undeterminable_reachability, unknown, error |
| Fix available | Whether an upstream fixed version exists | true / false |
| CISA KEV | Whether the CVE is in the CISA Known Exploited Vulnerabilities catalog | true / false |
| Patch status | Socket patch availability, distinct from an upstream fix | patch_unavailable, patch_available, patch_applied |
Operators
Each condition uses an operator appropriate to its field:
| Operator | Applies to | Meaning |
|---|---|---|
| is / is not | All fields | Exact match, or its negation. Also accepts a list of values, matching if any of them do. |
| at least / at most | Numbers | Inclusive comparison |
| greater than / less than | Numbers | Exclusive comparison |
| starts with / ends with / includes | Text | Substring matching |
| before / after | Dates | Date comparison |
Fields that carry a fixed set of values — severity, category, reachability, ecosystem — offer those values as a picker rather than free text.
Version matching is exact, prefix, suffix, or substring. There are no version ranges, so express "the 4.x line" as a version that starts with 4..
Exceptions
An exception carves a case out of a rule that would otherwise match it. Exceptions are how you express "block critical CVEs everywhere except the sandbox repository" as one rule instead of two.
A rule with exceptions matches when its conditions hold and none of its exceptions do. Exceptions offer the same fields and operators as conditions, plus one extra: Repository — because a rule's repositories already come from the policy it belongs to, repository only makes sense as an opt-out, so the editor offers it there and not in conditions.
The Rule Editor
Rules are created and edited from Policies in the Socket dashboard.
Opening a policy shows its rules in evaluation order, with custom rules above the baseline rules. From there you can:
- Add a rule — give it a name, choose the action, then build its conditions and any exceptions field by field.
- Reorder rules — move a rule up or down, or send it to the first or last position. Because the first match wins, this directly changes behavior.
- Edit or delete a rule — changes take effect on subsequent scans.
The editor builds the rule visually, so you do not need to write the underlying selector by hand. Rules created through the API can be edited in the dashboard as long as their conditions map onto the visual editor's fields; anything more intricate is shown read-only, and you can replace it with a new rule if you need to change it.
Related Pages
- Policies — how rules are evaluated and what their actions do.
- Vigil Selectors — the same conditions written as JSON, for the API.
- Baseline Presets — the default rules underneath your custom ones.
Updated 3 days ago