alibaba-cloud-fetch-processor — Design (RETARGETED — commentary enricher)

Status: RETARGETED. Alibaba Cloud publishes per-CVE notice pages and ACK product bulletins, but with no listing endpoint, no RSS, and no CSAF — entries are scattered under /en/notice/ and ACK product overview URLs. This processor — if built — must crawl by sitemap or external search index, not by feed enumeration. Treat as a commentary enricher, not a primary advisory source.

1. Overview

• Tier: Tier-2 IaaS (Phase 4)
• Verdict: RETARGETED to commentary enricher
• Reason in one sentence: Alibaba Cloud has CVE-bearing pages but no programmatic feed; discovery requires sitemap or site:alibabacloud.com Google search, which makes this an enrichment-of-known-CVE flow rather than a CVE-discovery flow.
• Extended dictionary already authored: internal/critutil/dictionaries/extended/alibaba.json (§15.2). Service entries (ECS, OSS, ACK, RDS, etc.) remain valid for any future Implementable processor.
• Implied processor type: fetch (HTML scrape; URL discovery via sitemap)
• Excluded from scope: Alibaba Cloud Linux 2 CVE RSS at alibabacloud.com/help/en/alinux/.../subscribe-to-announcements-for-alibaba-cloud-linux-2-cves — this is a distro-level OS feed, redundant with our existing per-distro processors. Recommended owner: alinux2-rss-processor (already in cmd/ tree) if not already wired.

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

Recon-protocol grid:

URLs checked:

• https://www.alibabacloud.com/help/en/security-and-compliance/ — 200 but JS-only SPA
• https://security.alibaba.com/ — 200 but empty body to non-browser UA
• https://www.alibabacloud.com/help/en/ack/product-overview/vulnerability-cve-2024-21626-bulletin — 200, server-rendered, parseable
• https://www.alibabacloud.com/en/notice/statement_on_the_runc_breakout_vulnerability_cve202421626_in_alibaba_cloud_products_2c7 — 200, server-rendered
• https://www.alibabacloud.com/help/en/alinux/user-guide/subscribe-to-announcements-for-alibaba-cloud-linux-2-cves — distro-level RSS docs (excluded)

3. Architecture (if built)

Discovery problem dominates implementation:

1. Periodic sitemap fetch:
   https://www.alibabacloud.com/sitemap.xml (or per-product sitemap)
   → filter URLs matching:
       /en/notice/.*
       /help/en/{ack,ecs,oss,rds,...}/product-overview/vulnerability-cve-.*-bulletin
2. Per-URL HEAD + ETag check (skip if seen)
3. Per-URL GET → parse server-rendered HTML
   → regex extract CVE-YYYY-NNNN+ from title + body
   → if no CVE match: skip
   → else: insert third-party-analysis reference rows per
           matching (cveId, source) tuple

Sitemap walk is the only viable discovery; full-text search via Google site: is not stable enough for production scheduling.

4. Source → DB field mapping

CVEMetadata: none written.

CVEMetadataReferences: one row per (cveId, source) already in CVEMetadata, type="third-party-analysis", referenceSource="alibaba-cloud".

5. Identifier policy

No Alibaba-issued IDs minted. Regex CVE-\d{4}-\d{4,7} over title + body. Multilingual handling: title may be EN or zh-CN; body may be EN or zh-CN — the regex is language-neutral and the description text can be stored verbatim (downstream translation if needed is out of scope).

6. CRIT / VEX

Optional, off by default. ACK product-overview bulletins are structured enough to support a CRIT envelope:

• provider="alibaba", service="ack", resource_type="cluster"
• vex_status="fixed" when bulletin says “patched in version X”
• shared_responsibility="customer_action_required" for ACK (customer upgrades node pools)

The existing internal/critutil/dictionaries/extended/alibaba.json covers ECS / OSS / ACK / RDS / SLB / VPC. Service-keyword detection must run on bulletin URL path (e.g. /help/en/ack/... → ACK).

7. S3 layout

• Archive: alibaba-cloud/files/{sha256}/{slug}.html
• Quarantine: failed-feeds/alibaba-cloud-fetch-processor/{date}/{reason}/{filename}

8. Error handling

Sitemap-walk discovery is fragile. If sitemap returns <50% of expected URLs, log a warning and skip the run rather than thrashing on quarantine. SPA shell pages must be detected (empty <main> after parse) and quarantined as decode-error so they don’t pollute discovery.

9. Performance

CPU 256, memory 512 MB. Cron: 0 13 * * ? * (daily 13:00 UTC, after the morning batch). Expected duration <15 minutes — sitemap is moderate (~few hundred relevant URLs).

10. Backfill

go-alibaba-cloud-fetch-backfill TARGET FORCE LIMIT EMIT_CRIT. No EXPECTED_DURATION_MINUTES.

11. Defer-or-build decision

Build conditional on a customer requesting Alibaba citations. Volume estimate is unclear — the runc CVE-2024-21626 case had pages across multiple Alibaba products (ACK, ECS, ASK), so a single upstream CVE may yield 3–5 reference rows. Annual reference-row volume estimate: 50–200. The existing cnvd-git-processor already covers some Chinese-domain advisories; cross-check before building to avoid duplicate references for the same CVE.

Unblock conditions for full implementation:

• Customer demand
• OR Alibaba publishing a sitemap-XML index of the security pages

Recheck cadence: every 6 months.

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: alibaba-cloud/files/{sha256}/{filename}
• Quarantine: failed-feeds/alibaba-cloud-fetch-processor/{YYYY-MM-DD}/{reason}/{filename}
• Likely reasons: (none documented)