Correct package and alert information links

[John-David Dalton (jdalton)]

LLM Description written by Codex:GPT-6

Link security findings to the affected package and the matching alert documentation.

Root Cause

Security comments used package identifiers as links and sent every non-license finding to malware documentation. JSON did not distinguish package links from alert-type documentation.

Fix

• Add nullable package_url and info_url fields to standard JSON alerts.
• Use those destinations in security comments, with accurate labels.
• Preserve existing fields and omit unavailable links.

Builds on #405. Links to individual alerts and triage pages still require an authoritative API value.

Validation

41 focused tests pass, including actual Core/SDK requests against the approved localhost fixture. Scoped Ruff, formatting for touched sections, and diff checks pass. Independent source review found no blockers.

Public Changelog

Correct package and alert documentation links in security reports.

---

Note

Low Risk
Additive JSON fields and PR comment link fixes; no auth or scan logic changes, though strict JSON schema consumers may need to allow new keys.

Overview
Fixes incorrect “Read more” links in PR security comments (they previously used purl for “This package”, mislabeled url, and sent many findings to generic malware/license pages). Comments now use a shared build_alert_links helper: This package → existing alert url, About this alert type → https://socket.dev/alerts/{type} (URL-encoded), omitting either link when missing.

Standard --enable-json alerts gain additive nullable fields package_url (same as url) and info_url (type docs); url, purl, and in-memory models are unchanged. docs/cli-reference.md documents the new JSON fields.

^{Reviewed by Cursor Bugbot for commit 9b1a282. Configure here.}