Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[eu-cra-compliance:vulnerability-handling-auditor] githubnext/gh-cao CRA vulnerability handling audit

Abierto
#19,636 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
24/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, javascript

Línea de trabajo

Start with SECURITY.md and SUPPORT.md, then review the referenced Regulation (EU) 2024/2847, Article 13, Article 14, and Annex I Part II. Draft the vulnerability lifecycle and support period documentation described in the agent prompt, preserving the private intake instructions and leaving legal and reportability decisions to human reviewers. Done means a maintainer runbook or supporting documentation defines the requested controls and an access-controlled sample links intake through communication and escalation timestamps.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

eu-cra-compliance eu-cra-compliance:vulnerability-handling-auditor

The repository has a usable private intake route and strong build/release security controls, but public evidence does not define the complete vulnerability lifecycle or support period. Aggregate GitHub evidence shows 6 open high-severity code-scanning alerts and 4 open dependency alerts (1 critical, 1 high, 2 low); exploitability, age, and remediation decisions were not assessed. Legal role, scope, classification, reportability, and release eligibility remain human decisions.

Action: The security owner should assign the documentation work below to Copilot, then approve the resulting policy and verify that one access-controlled sample links intake, triage, affected versions, decision, fix, release, communication, and Article 14 escalation timestamps.

  • GAP_FOUND — no published acknowledgement target, confidentiality/coordination protocol, triage owner, severity/exploitability method, affected-version/root-cause record, or Article 14 escalation link. Topic: vulnerability handling; source: Regulation (EU) 2024/2847, Article 13 and Annex I Part II; official text; verified 2026-10-23.
  • GAP_FOUND — SUPPORT.md calls the project an active research prototype but gives no support period, supported-version inventory, or end-of-support process. Topic: support-period vulnerability handling; source: Regulation (EU) 2024/2847, Article 13 and Annex I Part II; official text; verified 2026-10-23.
  • GAP_FOUND — open scanner findings require documented ownership and disposition; this record does not infer active exploitation or reportability. Topic: identification and remediation; source: Regulation (EU) 2024/2847, Annex I Part II and Article 14; official text; verified 2026-10-23.
<b>Agent prompt</b>

Draft a focused vulnerability-management documentation change for githubnext/gh-cao. Extend SECURITY.md and SUPPORT.md, and add a maintainer runbook if needed. Define acknowledgement and coordination expectations; confidentiality and withheld-detail handling; named-role triage ownership; severity and exploitability assessment; affected-version and root-cause records; remediation/mitigation/rollback decisions; upstream/downstream and CNA/CVE coordination where applicable; free secure update and customer-communication steps; support periods, supported versions, and end-of-support communication; timestamp retention; scanner-exception ownership and review; and an Article 14 escalation path that requires human reportability decisions. Do not include vulnerability details or decide CRA scope, role, classification, conformity, reportability, or market-release eligibility. Add tests or link checks appropriate to documentation and preserve existing private intake instructions.

<b>Regulatory baseline and limitations</b>
R1:
  topic: application dates
  status: EVIDENCE_SUFFICIENT
  dates: [2024-12-10, 2026-06-11, 2026-09-11, 2027-12-11]
  source:
    instrument: Regulation (EU) 2024/2847
    provision: Article 71
    authority: binding
  url: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
  verified: 2026-10-23
R2:
  topic: manufacturer vulnerability handling and support period
  status: HUMAN_REVIEW_REQUIRED
  source:
    instrument: Regulation (EU) 2024/2847
    provision: Article 13 and Annex I Part II
    authority: binding
  url: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
  verified: 2026-10-23
R3:
  topic: reporting escalation only; no reportability decision made
  status: HUMAN_REVIEW_REQUIRED
  source:
    instrument: Regulation (EU) 2024/2847
    provision: Article 14
    authority: binding
  url: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
  verified: 2026-10-23

INCOMPLETE — the Commission CRA entry point returned access denied during this run, so the stated 27 July 2026 non-binding guidance issue date was not independently verified: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (checked 2026-10-23). NOT_ASSESSED — no conclusion was made on delegated or implementing acts, OJ-referenced harmonised standards, or applicable certification schemes. The ENISA entry point was checked, but no project-specific applicability conclusion was made: https://www.enisa.europa.eu/.

<b>Lifecycle control matrix</b>
Control / independently testable claim Status Evidence or limitation Requirement source; verification
Private disclosure intake EVIDENCE_SUFFICIENT SECURITY.md rejects public reports and provides a private security address plus requested reproduction/impact fields. Annex I Part II; official text; 2026-10-23
Acknowledgement, researcher coordination, confidentiality GAP_FOUND No public process found. Internal evidence was not accessible. Annex I Part II; official text; 2026-10-23
Triage, severity/exploitability, affected versions, root cause, decision INCOMPLETE Aggregate alerts were readable; access-controlled case records were not examined. Article 13, Annex I Part II; official text; 2026-10-23
Regular tests, dependency/code scanning, component records EVIDENCE_SUFFICIENT CI has broad tests. The package workflow gates high/critical findings with Trivy and Grype, generates SPDX, seals checksums, and attests SBOM/provenance. One scanner exception documents no upstream fix but has no explicit owner/review date. Annex I Part II; official text; 2026-10-23
Fixes, secure distribution, rollback, release/customer communication INCOMPLETE Immutable releases, digests, attestations, independent promotion approval, and generated notes are evidenced; fix SLA, free-update policy, rollback/mitigation procedure, and security-advisory communication are not. Article 13, Annex I Part II; official text; 2026-10-23
Upstream/downstream, CNA/CVE, withheld details INCOMPLETE No public operating record found; internal evidence not accessible. Annex I Part II; official text; 2026-10-23
Support period and end-of-support GAP_FOUND No duration, supported-version list, or end-of-support notice process. Article 13, Annex I Part II; official text; 2026-10-23
Timestamp chain and Article 14 escalation INCOMPLETE GitHub preserves workflow/release timestamps; awareness, triage, correction, and communication linkage was not verified. Articles 13–14; official text; 2026-10-23
<b>Sampled traceability and what is working</b>
  • EVIDENCE_SUFFICIENT — release v0.1.28 binds source d29ce7b..., publication 2026-10-22T08:42:56Z, 11 immutable assets with SHA-256 digests, and successful release run 39749113405.
  • EVIDENCE_SUFFICIENT — package run 39892121399 on audited SHA 4bba110... completed successfully from 2026-10-23T02:54:29Z to 03:00:47Z.
  • What is working: the release path unusually well binds exact source, scans, checksums, attestations, immutable assets, and independent human promotion approval.
  • INCOMPLETE — these samples establish release integrity, not end-to-end vulnerability case handling. No confidential case was requested or exposed.
<b>Human-review decisions and inaccessible evidence</b>

HUMAN_REVIEW_REQUIRED for CRA scope/exclusion, economic-operator role, commercial versus non-commercial FOSS treatment, substantial modification, Class I/Class II or critical-product classification, conformity route, any harmonised-standard or certification-scheme applicability, presumption of conformity, active exploitation, severe-incident threshold, reportability, declaration readiness, and final market-release eligibility.

INCOMPLETE: private disclosure mailbox records; acknowledgement/coordination history; security advisory content; triage and root-cause records; affected-version inventory; remediation SLA/decisions; customer communications; and support/end-of-support records. Review these only in their access-controlled systems.

Human Acceptance

A non-bot security or compliance reviewer should add a 👍 reaction only after reviewing the complete vulnerability lifecycle controls, process evidence, sampled traceability, prioritized gaps, inaccessible evidence, and the human decisions above. This issue does not claim acceptance.

cao: githubnext/gh-cao, correlation: 39900760283-891

Generated by 🐛 EU CRA / Vulnerabilities · pi · gpt56 · ~75 AIC · ⌖ ~14 AIC · ⊞ 13.3K · ◷

  • expires on Nov 22, 2026, 4:45 AM UTC
Lenguaje dominante
JavaScript
Estrellas
8
Forks
5
Merge medio
2 h 16 min
PR fusionados (30 d)
857

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de githubnext/gh-cao

Todos los issues de githubnext/gh-cao

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.