Skip to content

feat: exclude RFC 2606 reserved domains from urlStrings alerts#1127

Open
h13 wants to merge 1 commit intoSocketDev:mainfrom
h13:feat/exclude-rfc2606-from-url-strings
Open

feat: exclude RFC 2606 reserved domains from urlStrings alerts#1127
h13 wants to merge 1 commit intoSocketDev:mainfrom
h13:feat/exclude-rfc2606-from-url-strings

Conversation

@h13
Copy link

@h13 h13 commented Mar 20, 2026

Summary

  • Skip urlStrings alerts where all detected URLs are RFC 2606 reserved domains (example.com, example.net, example.org)
  • These domains are reserved by RFC 2606 for documentation use and cannot pose a supply chain risk

Motivation

Packages that reference RFC 2606 domains — linters, documentation tools, URL validators — receive false-positive urlStrings alerts. For example, textlint-rule-rfc2606-domains has a Supply Chain Security score of 70 solely because it contains example.com, example.net, example.org as comparison constants.

See #1126 for full context.

Changes

In addArtifactToAlertsMap(), added a check after the existing enabledState filter: if the alert type is urlStrings and alert.props.urls contains only RFC 2606 domains, skip the alert.

Note

I was unable to run the test suite locally (requires Node >=25.5.0). The change is minimal and isolated — happy to adjust based on CI results or review feedback.

Test plan

  • Verify urlStrings alerts with only RFC 2606 domains are suppressed
  • Verify urlStrings alerts with non-RFC 2606 domains are still reported
  • Verify mixed alerts (RFC 2606 + other URLs) are still reported

RFC 2606 reserves example.com, example.net, and example.org for
documentation use. These domains cannot be registered, cannot serve
as exfiltration endpoints, and pose zero supply chain risk.

Skip urlStrings alerts where all detected URLs are RFC 2606 domains
to prevent false positives on documentation tools, linters, and
URL validators.

Closes SocketDev#1126
@h13
Copy link
Author

h13 commented Mar 20, 2026

Note on alert.props.urls type assumption:

I inferred the props.urls shape from the alert translation schema ("urls": "URLs") and the Socket.dev web UI display, but I have not verified the actual API response structure. The implementation assumes props.urls is string[].

If the actual shape differs (e.g., {url: string, file: string}[] or another format), the Array.isArray guard will prevent any breakage — the filter simply won't activate. Happy to adjust once the correct type is confirmed.

@h13
Copy link
Author

h13 commented Mar 20, 2026

Update: props.urls type confirmed via OpenAPI spec

Queried GET /v0/openapi and found the urlStrings schema in SocketIssue.anyOf:

{
  "props": {
    "type": "object",
    "properties": {
      "urls": {
        "type": "array",
        "items": { "type": "string" }
      }
    },
    "required": ["urls"]
  }
}

props.urls is string[] (required). The implementation in this PR correctly handles this type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant