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 repository guidance

Aperta
  • Qualcosa non va?
#19,536 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
48/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions
Ambito
ci-cd

Direzione di ricerca

Read .github/workflows/codeql.yml, .github/workflows/security-scan.yml, and .github/workflows/CWI.yml to compare their triggers and pull-request workflow patterns; then check the security targets in Makefile. The issue calls for applicable CodeQL, gosec, and govulncheck results before merge, while retaining scheduled and manual runs and excluding docs-only changes. Done means workflow-contract tests verify those trigger conditions and maintainers have documented finding triage and justified suppressions.

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

Descrizione

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

github/gh-aw has strong scheduled security analysis, dependency controls, secure-development guidance, tests, release SBOMs, and provenance. The highest-confidence gap is timing: CodeQL, gosec, and govulncheck run daily or manually, not on pull requests, so vulnerable changes can merge before these controls report. This repository-only review is advisory and non-binding; it does not prove security, compliance, certification, endorsement, or SSDF conformance.

Action: The github/gh-aw maintainers should make risk-appropriate security analysis a pull-request acceptance control; accept when a representative PR runs the configured CodeQL, gosec, and govulncheck checks before merge, with documented handling for findings and trusted exceptions.

Critical findings:

  • GAP_FOUND — PW.7.2/PW.8.2: .github/workflows/codeql.yml and .github/workflows/security-scan.yml expose only schedule and workflow_dispatch; they do not analyze proposed changes before merge.
  • OBSERVED: .github/workflows/CWI.yml builds pull requests; Makefile defines security regression tests, fuzz seeds, gosec, and govulncheck; release automation generates SPDX/CycloneDX SBOMs and container provenance.
  • LIMIT: repository evidence cannot establish organization-wide roles, training, branch rules, private alert triage, infrastructure controls, or operational conformance. Human review is required.
<b>Agent prompt</b>

Assign this issue to Copilot with the following prompt:

In github/gh-aw, update .github/workflows/codeql.yml and .github/workflows/security-scan.yml so risk-appropriate CodeQL, gosec, and govulncheck analysis runs on pull requests that can change Go, JavaScript, Actions, dependencies, build/release logic, or the scanner workflows. Preserve least-privilege permissions and SHA-pinned actions; handle fork PRs safely; avoid duplicate expensive work where practical; document how maintainers triage findings and approve justified suppressions. Add or update workflow-contract tests that prove relevant PRs trigger the checks and unrelated documentation-only changes do not. Acceptance: a representative PR receives all applicable security results before merge, and existing schedule/manual coverage remains.

<b>Assessment identity, scope, and baseline</b>
  • Target: github/gh-aw
  • Analyzed commit: 79ff755ee3f2b574a1bd716b05fef484238b919d
  • Verification date: 2026-10-22 UTC
  • Baseline: NIST SP 800-218, SSDF Version 1.1 (Final, February 2022)
  • Official project page: https://csrc.nist.gov/projects/ssdf
  • Final publication: https://csrc.nist.gov/pubs/sp/800/218/final
  • DOI: https://doi.org/10.6028/NIST.SP.800-218
  • The NIST project page still defines SSDF 1.1 as the current general framework. SP 800-218A is a separate final generative-AI community profile that augments, rather than revises, SP 800-218; it was not substituted for the requested general-framework baseline. No newer general SSDF final revision or open draft was identified on the official project page.
  • Method: bounded review of the supplied target snapshot and core public repository metadata. SSDF is a risk-based set of high-level practices intended for integration into an organizational SDLC; repository evidence alone cannot establish organization-wide implementation or conformance.
  • Inaccessible / NOT_ASSESSED: private alerts and cases, branch/ruleset configuration, environment protection, personnel and training records, internal infrastructure, incident records, and organization policy. Absence of access is not evidence of failure.
<b>Complete practice-to-evidence matrix</b>
Practice and task provenance Status Repository evidence and limitation Proportionate improvement / reduced risk
PO.1 (PO.1.1–PO.1.3), define and maintain security requirements PARTIAL SECURITY.md, CONTRIBUTING.md, secure coding rules, normative specs, and workflow threat controls are present; no single traced product-security requirement set was verified. Maintain lightweight requirement-to-check traceability for security-critical surfaces; reduce requirement drift.
PO.2 (PO.2.1–PO.2.3), define roles and responsibilities HUMAN_REVIEW_REQUIRED CONTRIBUTING.md identifies a core team and CODEOWNERS names maintainers, but security accountability, training, and executive commitment are organizational evidence. Human reviewer should confirm security owners, escalation, and training.
PO.3 (PO.3.1–PO.3.3), implement supporting toolchains OBSERVED Dev container, Make targets, CI, CodeQL, gosec, govulncheck, dependency automation, and release tooling are versioned. Preserve pinned and repeatable tooling.
PO.4 (PO.4.1–PO.4.2), define criteria for software security checks PARTIAL Scanner rules and justified gosec suppressions are explicit; the snapshot does not establish merge acceptance thresholds or exception governance. Document finding disposition and exception acceptance; reduce inconsistent gates.
PO.5 (PO.5.1–PO.5.2), implement and maintain secure environments NOT_ASSESSED Hosted runner, secret, environment, and administrative controls are not repository-observable enough to assess. Human review only; do not infer a gap.
PS.1 (PS.1.1), protect code from unauthorized access and tampering HUMAN_REVIEW_REQUIRED Read-only checkout settings and ownership hints exist; branch/ruleset and administrator controls were inaccessible. Confirm protected-branch and bypass governance.
PS.2 (PS.2.1), provide a mechanism to verify release integrity OBSERVED Release workflow computes digests, pins actions, requests attestations, and emits container provenance/SBOM metadata. Preserve digest-bound verification and publish consumer verification guidance.
PS.3 (PS.3.1–PS.3.2), archive and protect releases PARTIAL Releases, checksums, SBOM artifacts, tags, and release automation are evidenced; long-term retention and authorized availability are organizational. Confirm retention/recovery policy and immutable source-to-release records.
PW.1 (PW.1.1–PW.1.3), design to meet security requirements and mitigate risk PARTIAL Specs and compiler/runtime safeguards encode many security requirements; project-wide risk models and external security requirements were not fully traceable. Link critical requirements to design and tests.
PW.2 (PW.2.1), review design against security requirements and risk PARTIAL Multiple normative threat-model sections and review workflows exist; consistent human design-review records were not observable. Require a scoped security-design review for boundary-changing work.
PW.4 (PW.4.1–PW.4.4), acquire and reuse well-secured components OBSERVED Dependabot covers Go, npm, Actions, Docker, and pip; .github/vet/policy.yml rejects high/critical vulnerabilities, unmaintained components, and malware signals. Preserve inventory and risk-based dependency decisions.
PW.5 (PW.5.1–PW.5.2), create source adhering to secure coding practices OBSERVED CONTRIBUTING.md specifies validation, path safety, testing, and error-handling patterns; automated linters and security regression tests support them. Keep guidance and executable checks synchronized.
PW.6 (PW.6.1), configure compilation, interpretation, and builds securely OBSERVED Pinned Actions, reproducible tool versions, dependency verification, release checksums, and constrained job permissions are versioned. Preserve least privilege and pin validation.
PW.7 (PW.7.1–PW.7.2), review and analyze human-readable code GAP_FOUND CodeQL and gosec exist, but their workflows trigger only daily or manually; no pre-merge execution is declared there. Code review quality itself needs human confirmation. Run applicable analysis on PRs and define disposition criteria; detect weaknesses before merge.
PW.8 (PW.8.1–PW.8.2), test executable code for vulnerabilities PARTIAL Extensive tests, fuzz targets, security regression tests, govulncheck, and binary Defender scans exist; govulncheck is not a PR trigger in its declared workflow. Add risk-scoped pre-merge security execution while retaining deeper scheduled/release scans.
PW.9 (PW.9.1–PW.9.2), configure software securely by default PARTIAL Safe-output fail-closed controls, validation, least-privilege workflow examples, and secure defaults are prominent; deployed consumer configuration is outside the snapshot. Continue tests for secure defaults and explicit opt-in to elevated capabilities.
RV.1 (RV.1.1–RV.1.3), identify and confirm vulnerabilities continuously PARTIAL Daily CodeQL/gosec/govulncheck, Dependabot, and private reporting via SECURITY.md are present; private triage results were inaccessible. Confirm alert intake, validation owner, and service objective.
RV.2 (RV.2.1–RV.2.2), assess, prioritize, and remediate vulnerabilities HUMAN_REVIEW_REQUIRED Reporting route and dependency policy are visible, but severity decisions, remediation timelines, coordinated disclosure, and customer notification records are not. Human reviewer should verify risk-based triage and remediation records.
RV.3 (RV.3.1–RV.3.4), analyze root causes and feed lessons back HUMAN_REVIEW_REQUIRED Regression tests and changesets suggest feedback into development, but vulnerability root-cause records and recurrence analysis are private or absent from observable evidence. Confirm root-cause review for material vulnerabilities and trace resulting control updates.

Task identifiers and concise practice paraphrases are derived from the final SP 800-218 v1.1 table. GAP_FOUND is limited to the verified trigger contradiction for applicable pre-merge analysis; inaccessible organization-level evidence is not scored as failure.

<b>Prioritized improvement backlog</b>

  1. Add risk-scoped pre-merge security analysis (high confidence, high risk reduction, moderate effort).

    • SSDF: PW.7.2 and PW.8.2; supports PO.4.1.
    • Evidence: codeql.yml and security-scan.yml declare only scheduled/manual triggers, while CWI.yml proves PR validation is supported.
    • Risk: delayed analysis permits a detectable weakness or vulnerable dependency path to merge and potentially release before the daily scan.
    • Owner surface: repository security/CI maintainers.
    • Dependencies: branch/ruleset decision, fork-safe permissions, runtime budget, and finding-disposition policy.
    • Acceptance: representative Go, JavaScript, Actions, dependency, and build/release PR changes receive the applicable CodeQL, gosec, and govulncheck results before merge; docs-only changes are excluded; schedule/manual scans remain; suppressions require a scoped justification and review.

No duplicate open NIST-SSDF or GitHub Well-Architected guidance issue for this target was found in the admitted review repository.

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

Preserve: SHA-pinned Actions; least-privilege job permissions; broad dependency automation; OSS component policy; secure coding guidance; security regression/fuzz tests; daily static and vulnerability analysis; coordinated disclosure route; release digests, SBOMs, and provenance.

Human reviewers should decide:

  1. Which security checks must block merge versus report asynchronously, based on threat and runtime cost?
  2. Who owns security findings, exceptions, and remediation timelines?
  3. Do branch rules require the intended checks and constrain bypasses?
  4. Are material vulnerability root-cause reviews retained and translated into tests or controls?
  5. Should the separate final SP 800-218A generative-AI community profile receive a dedicated product-context assessment?

cao: githubnext/gh-cao, correlation: 39814115942-876

Generated by 🛡️ Dev Practices / NIST SSDF · pi · gpt56 · 78.7 AIC · ⌖ 13.2 AIC · ⊞ 13K · ◷

  • expires on Nov 21, 2026, 4:40 PM UTC
Lingua principale
JavaScript
Stelle
8
Fork
5
Merge medio
2h 28m
PR unite (30g)
849

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.