slack-fetch-processor — Design (RETARGET — do not build)

Status: DO NOT BUILD. Slack-vendor CVEs are already covered by the existing ghsa-git-processor via per-repo Security Advisories on github.com/slackhq/* (e.g. nebula). Slack does not publish a first-party CVE-numbered advisory feed, and the slack.com/blog/news/* security update posts are sparse incident disclosures (years apart) without CVE refs. Standing up a dedicated processor would duplicate GHSA coverage with no incremental signal.

1. Overview

Tier: Tier-3 SaaS (Phase 5)
Verdict: RETARGET / DO-NOT-BUILD
Reason in one sentence: Slack’s CVE-bearing footprint lives on github.com/slackhq/<repo>/security/advisories (GHSA), already ingested; no Slack-the-SaaS-platform CVE feed exists.

2. Source contract (Phase 0 recon — 2026-05-09)

Recon-protocol grid:

Step	Check	Finding
1	First-party CSAF	None
2	First-party CVRF	None
3	First-party RSS / Atom	None
4	First-party JSON API	`api.slack.com/changelog` is a product changelog, not a security feed
5	First-party HTML listing	`slack.com/trust/compliance/security-bulletin` and `/intl/en-gb/trust/security/security-bulletin` both 404
6	GitHub Security Advisories	Yes — already ingested. `github.com/slackhq/nebula/security/advisories/*` carries Slack-vendor CVEs
7	CVE alias presence	Only via GHSA path; no first-party feed
8	Anti-bot	N/A (we don’t crawl slack.com for security)

URLs checked:

https://slack.com/trust/compliance/security-bulletin — 404
https://slack.com/intl/en-gb/trust/security/security-bulletin — 404
https://api.slack.com/changelog — product changelog, not security
https://github.com/slackhq — 200; per-repo advisories exist
gh api /repos/slackhq/nebula/security-advisories — 200; published GHSAs with CVE refs (e.g. GHSA-69x3-g4r3-p962 / CVE-2026-25793)
gh api /orgs/slackhq/security-advisories — 404 (org-level endpoint not exposed; same pattern as hashicorp / databricks)

11. Deferral rationale + alternatives

Why not build:

Slack-as-vendor CVEs land in GHSA on slackhq/* repos → ghsa-git-processor already ingests them.
Slack-as-SaaS-platform has no public CVE stream. The only security-related public artifacts are slack.com/blog/news/* posts — sparse (years apart), unstructured HTML, no CVE refs, fail the commentary-enricher ROI bar.

What would unblock build:

Slack stands up a CSAF/CVRF endpoint or Discourse-style RSS bulletin board.
Slack adopts a trust.slack.com PSIRT page with CVE-prefixed advisories (analogous to Atlassian / Salesforce).

What to do if a customer asks for Slack CVEs now: Tell them coverage already happens via the existing GHSA ingest for slackhq/* repos. Run psql ... -c "SELECT * FROM \"CVEMetadataReferences\" WHERE \"referenceSource\"='ghsa' AND \"url\" LIKE '%slackhq%' LIMIT 20" to confirm.

Recheck cadence: every 6 months. Next 2026-11-09.

S3 Persistence

Not used. This processor does not currently archive payloads or quarantine failures to S3. Per the S3 Persistence Contract this is non-compliant — see the compliance matrix for the implementation roadmap.

⚠ Not in the compliance matrix — status needs verification.

Expected paths when implemented:

Archive: slack/files/{sha256}/{filename}
Quarantine: failed-feeds/slack-fetch-processor/{YYYY-MM-DD}/{reason}/{filename}
Likely reasons: (none documented)