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

[eu-cra-compliance:supply-chain-sbom-auditor] github/gh-aw-firewall CRA supply-chain and SBOM audit

Cerrado
  • ¿Algo no está bien?
#19,638 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, javascript
Área
devops, release

Línea de trabajo

Start with .github/workflows/release.yml, docs/releasing.md, docs/image-verification.md, and the listed SBOM generator, then map the npm, Go, Rust, and container manifests to release artifacts. The issue asks for an aggregate version-bound SPDX SBOM, release and OCI attestations, automated cross-checks, and maintainer documentation covering retention, confidential delivery, suppliers, and support. Done means one tagged release verifies coverage for every shipped component and the requested records and checks are in place.

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

Descripción

eu-cra-compliance eu-cra-compliance:supply-chain-sbom-auditor

At the reviewed SHA, release engineering provides strong digest, signature, provenance, and image-SBOM controls, but the evidence set is not yet complete for a repository-wide CRA supply-chain record. The latest release exposes two root-filesystem SPDX SBOMs and provenance-related assets; OCI SBOM attestations are configured but registry state was inaccessible. Priority gaps are a version-bound SBOM for every distributed component, documented confidential authority-supply/retention handling, and explicit supplier/EOL ownership. Regulatory recency verification is INCOMPLETE because the official entry points returned HTTP 403 on 2026-10-23; this is an evidence audit, not a legal determination.

Action: Maintainers should assign this issue to Copilot to implement a complete release-to-component evidence bundle; accept when one tagged release has verified SPDX coverage for every shipped binary, npm artifact, container and rootfs, plus documented retention, confidential authority-supply, supplier/EOL ownership, and automated cross-checks.

  • GAP_FOUND — Latest release v0.28.74 contains rootfs SPDX files, checksums and container digests, but no release-attached whole-product SBOM for the binaries/npm bundle; configured OCI attestations could not be verified. Topic: machine-readable SBOM; source: Regulation (EU) 2024/2847, Annex I Part II(1); official text; verified 2026-10-23.
  • GAP_FOUND — No repository evidence was found for confidential SBOM handling, lawful authority supply, evidence-retention duration, or supplier/EOL disposition. Topic: vulnerability handling and technical evidence; source: Regulation (EU) 2024/2847, Annex I Part II and manufacturer documentation obligations; official text; verified 2026-10-23 with recency limitation.
  • INCOMPLETE — Dependabot alerts, branch protection, secret scanning, GitHub attestations, and GHCR signatures/SBOM attestations were inaccessible to the configured credential; no negative conclusion is drawn. Topic: operational supply-chain evidence; source: CRA implementation evidence (not an independent legal substitute); Commission CRA policy; verified 2026-10-23.
<b>Agent prompt</b>

Implement a release evidence bundle for github/gh-aw-firewall. Generate one version-bound SPDX 2.3 SBOM covering every shipped binary, npm tarball, container image, rootfs and their top-level dependencies; preserve existing deeper package/file/hash data. Bind SBOM subjects to release digests, attach non-confidential SBOMs to the GitHub release, attest OCI SBOMs, and add a verification job that compares manifests, lockfiles, release assets, images and tag/source SHA. Add maintainer-owned documentation for confidential SBOM storage and lawful authority delivery, retention, supplier/upstream/EOL review, exceptions, and supported-version traceability. Add focused tests; do not publish confidential component data or make legal-scope/conformity decisions.

<b>Component surface and SBOM evidence matrix</b>
Surface / independently testable claim Rating Repository or release evidence Requirement/topic; source; official URL; verification
Six npm manifests have six lockfiles; two Go modules have one go.sum; one Rust manifest has no Cargo.lock; 12 Dockerfiles include digest-pinned defaults plus parameterized build stages. HUMAN_REVIEW_REQUIRED Checkout inventory; package-lock.json, go.mod, go.sum, Cargo.toml, containers/**/Dockerfile* Component completeness; Annex I Part II(1); Regulation; 2026-10-23
Release workflow generates SPDX JSON and cosign attestations for production OCI images. Some attestation steps are continue-on-error. EVIDENCE_SUFFICIENT for configured generation; NOT_ASSESSED for registry state .github/workflows/release.yml; docs/image-verification.md SBOM/integrity implementation evidence; Annex I Part II(1); Regulation; 2026-10-23
Rootfs generator records installed packages, files, SHA-256/SHA-1, source image digest and relationships in SPDX 2.3. EVIDENCE_SUFFICIENT for those rootfs artifacts guest/cloud-hypervisor/generate-enclave-rootfs-sbom.mjs SBOM depth beyond express top-level minimum; Annex I Part II(1); Regulation; 2026-10-23
Bundled/generated/runtime surfaces outside released rootfs and OCI attestations lack one demonstrated aggregate SBOM. GAP_FOUND No aggregate SBOM in checkout or v0.28.74 release assets Machine-readable SBOM; Annex I Part II(1); Regulation; 2026-10-23
<b>Release traceability, vulnerability management, and provenance</b>
Claim Rating Evidence / limitation Topic; source; official URL; verification
v0.28.74 publishes checksums, containers.txt, release identity, two large rootfs SPDX SBOMs, manifests, and Sigstore/provenance files. EVIDENCE_SUFFICIENT for asset presence GitHub Releases API, published 2026-10-21 Traceability/integrity; Annex I Part II; Regulation; 2026-10-23
Tag-only release commits, checksums, subject attestations and consumer verification instructions establish a documented source-to-release chain. EVIDENCE_SUFFICIENT for design .github/workflows/release.yml; docs/releasing.md; docs/image-verification.md Provenance implementation evidence; Annex I Part II; Regulation; 2026-10-23
Weekly Dependabot covers npm, Docker, Go and Actions; npm/Syft/Grype checks and SARIF exist; 33 open code-scanning alerts were countable without exposing details. Triage SLA/owner and complete advisory status were not verified. HUMAN_REVIEW_REQUIRED .github/dependabot.yml; dependency/supply-chain workflows; API limitations Vulnerability identification/handling; Annex I Part II; Regulation; 2026-10-23
Supported-version policy, upstream EOL cadence, fork/patch register and release evidence retention are not verified. GAP_FOUND No decisive repository policy found Supplier/support risk; Annex I Parts I-II; Regulation; 2026-10-23

Whats working: digest-pinned base images, signed OCI images, attested release subjects, consumer verification guidance, and final-filesystem SBOMs form a notably strong foundation.

<b>Regulatory provenance, dates, and human questions</b> 
source:
  instrument: "Regulation (EU) 2024/2847"
  provision: "Annex I, Part II, point (1); Article 71 application dates"
  authority: "binding"

Initial dates carried for review: entry into force 10 December 2024; conformity-assessment-body provisions 11 June 2026; Article 14 reporting 11 September 2026; full application 11 December 2027. Commission guidance dated 27 July 2026 is non-binding. Current official pages could not be retrieved, so all date recency is INCOMPLETE; Regulation, Commission, ENISA; attempted 2026-10-23. No harmonised standard or presumption of conformity is asserted.

Human reviewers must decide product scope/operator role, treatment of distributed artifacts, support period, classifications, conformity route, and whether any confidential SBOM must be withheld from public release while remaining lawfully available.

Human Acceptance

A non-bot reviewer should add a thumbs-up reaction only after reviewing the complete component surface, SBOM matrix, release traceability, vulnerability-management, provenance, gap, and human-review record.

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

Generated by 🎯 EU CRA / Supply Chain · pi · gpt56 · ~79 AIC · ⌖ ~14 AIC · ⊞ 13.5K · ◷

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

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.