Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[software-development-practices:nist-ssdf] github/gh-aw-firewall repository guidance

Aperta
  • Qualcosa non va?
#19,481 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, yaml
Ambito
ci-cd, security

Direzione di ricerca

Start with .github/workflows/release.yml at the three cited SBOM attestation steps and trace how their jobs feed the release job. Read the existing signing and attestation conventions, then inspect release workflow tests under scripts/ci/ and the verification guidance in docs/releasing.md. Done means a deterministic test shows terminal SBOM publication failure blocks release completion, and every shipped image has durable, consumer-verifiable SBOM evidence.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

software-development-practices software-development-practices:nist-ssdf

The repository has strong secure-build evidence—threat models, pinned CI actions, CodeQL, dependency and container scanning, extensive security tests, signed images, checksums, and build provenance—but one release-integrity gap is actionable: a release can succeed when SBOM attestation fails for three published images. This repository-only review found 1 verified gap; organization-level conclusions still require human review.

Action: Maintainers should make SBOM evidence for agent-act, build-tools, and gh-aw-node fail closed or preserve an equivalent verifiable release record; accept when a test proves publication cannot complete without durable, consumer-verifiable SBOM evidence for every shipped image.

[!IMPORTANT]
This assessment is advisory and non-binding. It does not prove security, compliance, certification, NIST endorsement, or SSDF conformance. SSDF is risk-based and organization-wide; this review observes one repository snapshot only.

Critical finding
  • PS.3.1 — release records: .github/workflows/release.yml:650-671, :729-748, and :809-828 set continue-on-error: true on SBOM attestation for agent-act, build-tools, and gh-aw-node. The release job at :831-834 depends on those jobs, but tolerated step failures leave the jobs eligible to satisfy that dependency. These images can therefore be published without their SBOM attestations, unlike the fail-closed attestation steps used for other images. This weakens the durable provenance and component record needed to verify and investigate a release.
<b>Agent prompt</b>

Implement a focused fix in github/gh-aw-firewall for the SSDF PS.3.1 release-record gap. In .github/workflows/release.yml, ensure every published image—especially agent-act, build-tools, and gh-aw-node—has durable, consumer-verifiable SBOM evidence before the release job can complete. Prefer existing signing and attestation conventions. Either fail publication after bounded attestation retries or implement a reviewed equivalent that archives and authenticates the SBOM for offline verification; do not silently downgrade to an unauthenticated checksum. Add a deterministic test under scripts/ci/ proving that terminal SBOM-publication failure blocks release completion. Update docs/releasing.md and verification guidance if the consumer contract changes. Run focused release-workflow tests and the root test suite.

Acceptance check: a fixture simulating exhausted retries fails the relevant build/release dependency, successful runs retain verifiable SBOM evidence for all published images, and documentation accurately describes verification.

<b>Assessment scope and baseline</b>

The NIST project and publication pages were fetched for this run and still identify SSDF 1.1 as the final core framework. SP 800-218A is a final community profile augmenting 1.1 for generative-AI and dual-use foundation-model development, not a newer core revision; this repository does not present itself as an SI model developer, so 218A was not the scoring baseline. The publication page lists the September 2021 initial public draft as historical and the February 2022 document as final. Draft and potential-update material was not scored.

Method and limits: snapshot review plus bounded public metadata. Branch-protection and ruleset configuration returned HTTP 403. Private vulnerability alerts, incidents, personnel, training, internal governance, production infrastructure, response SLAs, and confidential remediation records were NOT_ASSESSED. Their absence from the snapshot is not a failure. No matching open NIST-SSDF guidance issue or GitHub Well-Architected issue was found in the admitted review repository.

<b>PO / PS / PW / RV practice-to-evidence matrix</b>
Practice and task identifiers Status Evidence, limitation, and proportionate improvement
PO.1 requirements (PO.1.1-.3) PARTIAL docs/security.md, docs/nvx-security-design.md, docs/enclaves-architecture.md, and docs/releasing.md define product/release requirements. Organization-wide ownership and review cadence need human confirmation.
PO.2 roles (PO.2.1-.3) PARTIAL .github/CODEOWNERS assigns maintainers; docs/security.md gives a coordinated-disclosure route. Capacity and training are NOT_ASSESSED.
PO.3 toolchains (PO.3.1-.3) OBSERVED Pinned CodeQL, Syft, Grype, Grant, npm audit, Dependabot, CI, and attestation tools are versioned in workflows. Preserve pinning and tool review.
PO.4 security-check criteria (PO.4.1-.2) PARTIAL Dependency audit blocks high/critical findings; supply-chain scanning documents blocking/report-only behavior. Required-check enforcement is HUMAN_REVIEW_REQUIRED because rulesets were inaccessible.
PO.5 secure environments (PO.5.1-.2) NOT_ASSESSED Workflow least privilege is visible; workstation, identity, network, and organization environment controls are not.
PS.1 protect code (PS.1.1) HUMAN_REVIEW_REQUIRED CODEOWNERS and persist-credentials: false are positive evidence. Branch, review, and tag protection were inaccessible; confirm them.
PS.2 release integrity (PS.2.1) PARTIAL Release workflow signs image digests and emits checksums/provenance; docs/releasing.md documents verification. Optional SBOM attestations weaken completeness.
PS.3 archive releases (PS.3.1) GAP_FOUND Three image SBOM-attestation steps tolerate terminal failure and release can proceed. Require success or an authenticated archived equivalent.
PW.1 secure design (PW.1.1-.2) OBSERVED Multiple security design documents define threats, boundaries, and fail-closed controls. Preserve updates with boundary changes.
PW.2 design review (PW.2.1) PARTIAL Security designs, CODEOWNERS, and scheduled security-review.md exist. Qualified human approval for each sensitive design is not verifiable.
PW.3 third-party software (PW.3.1-.2) PARTIAL Lockfiles, Dependabot, npm audit, digest pins, Grype, and Grant provide strong checks. Supplier evaluation beyond automation is NOT_ASSESSED.
PW.4 reuse secure components (PW.4.1-.3) PARTIAL Dependencies are locked/refreshed and images/actions pinned. Organization-wide selection and EOL criteria need human review.
PW.5 secure coding (PW.5.1) PARTIAL CONTRIBUTING.md requires tests/linting; security-sensitive code has adjacent tests. A complete secure-coding standard/training record is not observable.
PW.6 secure build/runtime configuration (PW.6.1-.2) OBSERVED Seccomp, non-root operation, explicit permissions, hardened images, digest pins, and fail-closed runtime contracts are documented/tested.
PW.7 code review/analysis (PW.7.1-.2) OBSERVED CodeQL analyzes JS/TS, Actions, and Python with extended queries; CODEOWNERS supports review. Consider removing the release.yml-only PR exclusion from CodeQL.
PW.8 executable testing (PW.8.1-.2) OBSERVED Extensive unit, integration, adversarial, network-isolation, image-scan, and security tests exist. Test results were not rerun here.
PW.9 secure defaults (PW.9.1-.2) OBSERVED Documentation and code emphasize deny-by-default networking, credential isolation, bounded execution, and no silent fallback.
RV.1 identify/confirm vulnerabilities (RV.1.1-.3) PARTIAL Private reporting, CodeQL, dependency audit, supply-chain scans, and scheduled reviews exist. Private intake records are NOT_ASSESSED.
RV.2 assess/remediate (RV.2.1-.2) NOT_ASSESSED Scanner thresholds show intent, but alerts, risk decisions, timelines, and SLAs were intentionally not accessed.
RV.3 root-cause analysis (RV.3.1-.3) PARTIAL Diagnostic/failure-mode documents preserve root-cause analysis and tests accompany fixes. A vulnerability-specific recurrence process requires human confirmation.
<b>Prioritized improvement backlog</b>

  1. Make SBOM evidence mandatory or durably equivalent for every release image — high priority; high confidence; small/medium effort.

    • SSDF: PS.3.1, supporting PS.2.1.
    • Risk: responders and consumers may lack authenticated component evidence for a published image when the transparency service is degraded. Image signatures prove publisher/digest identity but do not replace a component inventory.
    • Owner: release engineering/security maintainers for .github/workflows/release.yml, scripts/ci/, and docs/releasing.md.
    • Dependency: decide whether online Rekor publication is mandatory or an authenticated offline bundle is supported; retain bounded retries and avoid unauthenticated fallback.
    • Acceptance: deterministic failure-path test; release cannot complete without authenticated, retrievable SBOM evidence for every image; consumer documentation matches behavior.

No other verified repository-level gap met the backlog threshold. Items depending on rulesets, private alerts, personnel, or organization policy remain human-review questions.

<b>Strengths and human-review questions</b>

Preserve: fail-closed bootstrap/provenance verification; digest-pinned actions/scanners; coordinated disclosure; broad CodeQL/dependency/container checks; explicit threat models; negative tests; non-root, least-privilege, deny-by-default contracts.

Human review: Are supply-chain and release checks required by active branch/tag rules? Do release-workflow changes require independent security approval? Where are private triage SLAs, training, root-cause reviews, and recurrence decisions retained? Should Rekor unavailability block release, or should consumers receive an authenticated offline SBOM bundle?

cao: githubnext/gh-cao, correlation: 39769937507-871

Generated by 🛡️ Dev Practices / NIST SSDF · pi · gpt56 · 112 AIC · ⌖ 13.1 AIC · ⊞ 12.9K · ◷

  • expires on Nov 21, 2026, 11:33 AM UTC
Lingua principale
JavaScript
Stelle
8
Fork
5
Merge medio
2h 1m
PR unite (30g)
851

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di githubnext/gh-cao

Tutte le issue di githubnext/gh-cao

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.