Normalize Slack issue severity and bump SDK to v3.6.0

[lelia]

Summary

Every severity lookup in the Slack reachability formatter is keyed on medium, but middle is what the API sends — it is the value in the OpenAPI spec's SocketIssueSeverity and in the SDK enum. A mid-severity finding therefore missed all of them at once:

• Not counted. severity_counts has no middle key and the increment is guarded by if ... in severity_counts, so the summary always read Medium: 0.
• Excluded from total_findings. Since omitted_count = total_findings - len(selected_vulnerabilities), a batch of mid-severity findings can drive the "and N more" line negative.
• Sorted below low. SEVERITY_ORDER.get(severity, 4) returned the default of 4 against low's 3, so mid-severity findings sank to the bottom and were the first truncated at the block limit.
• Wrong emoji, which is the least of it.

The findings themselves were always listed — purl_groups drives that, not the counts — so this is a wrong summary and wrong ordering rather than a missing finding or a false all-clear.

Fixed by normalizing to one spelling where the alert is read, rather than adding a parallel middle key to four dicts. Messages.map_socket_severity_to_gitlab and the GitLab severity map already accept both forms with a comment calling middle the older format; this formatter never got the same treatment. Worth noting the live spec still lists middle, so it is the current value rather than a legacy one.

Seven regression tests; five of them fail without the one-line change.

---

Note

Low Risk
Small, localized formatter change with regression tests; no auth, API, or scan-blocking behavior.

Overview
Release 2.6.13 fixes how mid-severity alerts appear in Slack reachability notifications when the API sends severity as middle (OpenAPI/SDK spelling) while the Slack formatter only keyed lookups on medium.

In _extract_alert_info, middle is now mapped to medium at read time (same idea as Messages.map_socket_severity_to_gitlab), so Medium counts, total_findings, sort order, emoji, and block-limit truncation behave correctly instead of treating mid findings as unknown/low-priority. Findings were still listed; the bug was summary math and ordering.

Adds unit tests in test_slack_severity_normalization.py and updates the changelog and package version (2.6.12 → 2.6.13).

^{Reviewed by Cursor Bugbot for commit 794ce00. Configure here.}

[Eric Hibbs (flowstate)]

[agent] Verified the bug mechanically rather than just trusting the description: on main, SEVERITY_ORDER/SEVERITY_EMOJI/severity_counts all key on 'medium' with no 'middle' entry, so a mid-severity finding (which is what the API actually sends, matching the SDK's SocketIssueSeverity) misses the count, defaults to sort order 4 (below 'low' at 3), and gets the fallback emoji -- exactly the three symptoms described. The one-line normalization at the read site matches the pattern already used in Messages.map_socket_severity_to_gitlab. All 7 new regression tests pass.

Approving the fix itself. The socketdev 3.6.0 version-bump checklist in the description is correctly left undone and unchecked pending that release, so this stays unmerged until then -- nothing for me to act on there.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​socketdev@​3.5.0 ⏵ 3.6.0	+1

View full report

[socket-security-staging]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​socketdev@​3.5.0 ⏵ 3.6.0	+1

View full report