No vulnerability-disclosure channel (no SECURITY.md, blank issues disabled, only public templates) (CR-A16-053) #466

Wave 2 · theme D2-1: Security and integrity: medium/large effort · highest severity Low · 2 finding(s) · effort trivial

Summary

A researcher finds a verify-audit bypass and files a public issue because no private route exists, so the bypass is disclosed before a fix.

Primary finding

CR-A16-053 — No vulnerability-disclosure channel (no SECURITY.md, blank issues disabled, only public templates)

severity Low · reachability default · intent intended-but-harmful · confidence likely · single reviewer · not reproduced (code trace)

What happens. The repository has no SECURITY.md (root or .github/). .github/ISSUE_TEMPLATE/config.yml sets blank_issues_enabled: false and offers only Documentation and Discussions links. docs/standards/release.md:366 assumes 'If a security issue is reported (see SECURITY.md if present)'. For a tool whose stated guarantees include an SSRF guard, tamper-evident audit logs and a trust_remote_code default, a reporter's only route is a public issue or discussion.

Where.

• .github/ISSUE_TEMPLATE/config.yml:1-7
• docs/standards/release.md:364-372

Evidence.

• ls of the snapshot root and .github shows no SECURITY.md.

Recommended fix. Add SECURITY.md pointing to GitHub private vulnerability reporting, and add a contact_links entry for it.

Other findings with the same root cause

These close with the same fix; update them in the same pull request.

TECH-T11-003 — Regulation and standards: GDPR, ISO/IEC 27001, SOC 2, ISO/IEC 42001, EDPB, EU Cyber Resilience Act: EU Cyber Resilience Act (Regulation (EU) 2024/2847): open-source distribution of ForgeLM, Art. 14 r…

severity Next release

Item. EU Cyber Resilience Act (Regulation (EU) 2024/2847): open-source distribution of ForgeLM, Art. 14 reporting from 11 September 2026, SBOM, vulnerability disclosure · verdict: at-risk · urgency: Next release

State in ForgeLM. Apache-2.0 (pyproject.toml:23), distributed on PyPI (version 0.11.1rc1 in the snapshot). A CycloneDX 1.5 SBOM is generated per release (tools/generate_sbom.py:2, :113-116; README.md:122). There is no SECURITY.md and no vulnerability-disclosure contact in the root or .github/; .github/ISSUE_TEMPLATE/config.yml links only docs and Discussions. The CRA is not mentioned anywhere. docs/product_strategy.md:82, :123 and :159-162 plan a Pro CLI 'for paying users', 'enterprise support contracts (Silver/Gold/Platinum tier)' and '$50,000–$150,000 ARR'.

State of the ecosystem on 2026-10-01. Regulation (EU) 2024/2847 (OJ L 2024/2847, 20.11.2024; CELEX 32024R2847) is in force. Art. 71(2): it applies from 11 December 2027, but 'Article 14 shall apply from 11 September 2026 and Chapter IV ... from 11 June 2026'. Art. 69(3): Art. 14 obligations apply to in-scope products placed on the market before 11 December 2027. Recital 15: commercial activity can include 'charging a price for technical support services where this does not serve only the recuperation of actual costs' or 'an intention to monetise'. Recital 18: FOSS 'not monetised by their manufacturers should not be considered to be a commercial activity'. Art. 24 sets light obligations for open-source software stewards. Annex I Part II(1) requires an SBOM 'in a commonly used and machine-readable format covering at the very least the top-level dependencies'. The only amending act in CELLAR is 32025R0327, and the GDPR Omnibus (2025/0360(COD)) does not list 2024/2847 among the acts it amends.

Impact. While ForgeLM is non-monetised Apache-2.0 FOSS, its publisher is probably not a CRA manufacturer. The planned paid support tiers and Pro CLI are recital-15 monetisation signals that could bring the offering into manufacturer scope, with Art. 14 reporting (24 h early warning, already applicable) and the Annex I obligations from December 2027. Whether anything is monetised today cannot be determined from the snapshot. The CycloneDX SBOM meets the Annex I Part II(1) wording. The missing coordinated-vulnerability-disclosure policy and contact is a gap under both the steward and manufacturer regimes.

Recommendation. Add SECURITY.md with a coordinated vulnerability disclosure policy and contact now. Before any paid tier launches, record a CRA role decision (out of scope / steward / manufacturer) and prepare for Art. 14 reporting via the single reporting platform. Keep the SBOM covering at least top-level dependencies and watch for the Commission implementing act on SBOM format (Art. 13(24)).

Sources.

• Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L 2024/2847, 20.11.2024 (2024-11-20)
• CELLAR SPARQL: amending acts of the CRA (32025R0327) (2026-10-01)
• EP Legislative Observatory 2025/0360(COD): list of amended acts (CRA not among them) (2026-07-27)

Acceptance criteria

• A regression test reproduces the failure scenario and asserts the corrected behaviour.
• Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
• Every finding in this issue is resolved or explicitly closed with a reason.

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}