batch 2 of 6: CI safe-patterns + supply-chain absorption

[AceHack]

Summary

Batch 2 of the 6-batch speculative-branch drain plan (`docs/research/speculative-branch-landing-plan-2026-04-22.md`). Security-adjacent CI surfaces.

New files (4):

• `.github/workflows/resume-diff.yml` — PR comment with claim-level diff on FACTORY-RESUME.md + SHIPPED-VERIFICATION-CAPABILITIES.md. Not a gate.
• `.github/workflows/scorecard.yml` — OpenSSF Scorecard weekly run, SARIF upload to Security tab.
• `docs/security/GITHUB-ACTIONS-SAFE-PATTERNS.md` — workflow-injection checklist + threat model + context table.
• `docs/security/SUPPLY-CHAIN-SAFE-PATTERNS.md` — SLSA guidance + CVE-2025-30066 + Trivy TeamPCP (2026-03-19) case studies + content-review-is-load-bearing rule.

Modified files (3):

• `.semgrep.yml` — rule 17 `gha-untrusted-in-run-line` (regex catch for workflow-injection on `run:` lines).
• `docs/security/INCIDENT-PLAYBOOK.md` — expanded A-block references to the two canonical incidents.
• `.github/dependabot.yml` — +11 lines for scorecard-action path / interval tightening.

Verification

• `actionlint` clean on both new workflow files (verified locally)
• `markdownlint-cli2` clean on all three docs/security/*.md (MD007 ul-indent fix applied)
• No new .sh files — shellcheck NA
• SHA-pinning discipline enforced on new workflows (no mutable tags)

Test plan

• CI: build-and-test matrix + lint gates pass
• scorecard.yml is weekly cron (`workflow_dispatch` also enabled for manual fire)
• resume-diff.yml triggers only on PRs touching FACTORY-RESUME.md or SHIPPED-VERIFICATION-CAPABILITIES.md

References

• FACTORY-HYGIENE row 24 (CI safe-patterns, H-risk)
• Aaron 2026-04-22 directive — absorb GitHub Security Lab workflow-injection guide
• Batch 1 = PR research backfill (batch 1 of 6): land 12 net-new research docs from speculative branch #49 (research backfill); batch 3 = hygiene audit automation (next)

[Copilot]

Pull request overview

This PR lands “batch 2 of 6” from the speculative-branch plan, focused on hardening CI and documenting security-safe patterns for GitHub Actions and dependency/supply-chain hygiene.

Changes:

• Add two new security guidance docs covering GitHub Actions workflow-injection prevention and supply-chain safe patterns.
• Add two new GitHub Actions workflows: OpenSSF Scorecard (SARIF upload) and a PR-helper that posts a resume-claim diff comment.
• Extend Semgrep with a new rule to catch inline untrusted ${{ github.* }} expansions on single-line run: steps, plus small CI hygiene/doc updates.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 12 comments.

Show a summary per file

File	Description
docs/security/SUPPLY-CHAIN-SAFE-PATTERNS.md	New in-repo checklist and threat model for dependency/supply-chain hygiene.
docs/security/INCIDENT-PLAYBOOK.md	Expand Playbook A canonical-incident references (mutable-tag class).
docs/security/GITHUB-ACTIONS-SAFE-PATTERNS.md	New workflow-injection safe-patterns checklist and enforcement overview.
.semgrep.yml	Add rule to flag untrusted GitHub context interpolation in run: lines.
.github/workflows/scorecard.yml	New weekly OpenSSF Scorecard workflow with SARIF upload.
.github/workflows/resume-diff.yml	New PR helper workflow that comments a claim-level diff for resume-related docs.
.github/dependabot.yml	Add clarifying comments about uv-managed Python tooling vs Dependabot support.

[Copilot]

On fork PRs, workflows triggered by pull_request commonly receive a read-only GITHUB_TOKEN, so gh pr comment can fail even if pull-requests: write is declared. To avoid noisy red runs, consider gating the comment step/job to same-repo PRs (or handling the failure explicitly), or document the required repo setting if write tokens for fork PRs are enabled intentionally.

[Copilot]

grep -E doesn’t support \s (whitespace) or \b (word boundary), so this claim-line filter won’t match what it intends on ubuntu-22.04 (GNU grep treats these as literal characters). Use POSIX character classes like [[:space:]] and a word-boundary alternative (or switch to grep -P / perl) so the detection is actually effective under set -euo pipefail.

Suggested change

	| grep -E '^[+-]\s*(- \*\*|\| |#{2,4} |.*\b(ships?|shipped|verified|proven|complete[ds]?|honest|already absorbed|implement(ed|s)?|in[- ]repo evidence)\b)' \
	| grep -E '^[+-][[:space:]]*(- \*\*|\| |#{2,4} |.*(^|[^[:alnum:]_])(ships?|shipped|verified|proven|complete[ds]?|honest|already absorbed|implement(ed|s)?|in[- ]repo evidence)([^[:alnum:]_]|$))' \

[Copilot]

This cadence pointer says “FACTORY-HYGIENE row 41” but docs/FACTORY-HYGIENE.md row 41 is “Orthogonal-axes audit”, not a supply-chain or dependency-ingress re-read. Please either add the intended hygiene row or update this reference to the correct row so the doc doesn’t send readers to the wrong audit.

Suggested change

	rounds (FACTORY-HYGIENE row 41, same cadence as GHA safe-patterns).
	rounds (same cadence as GHA safe-patterns; FACTORY-HYGIENE
	dependency-ingress re-read cadence).

[Copilot]

This section (a) endorses curl | bash as “safe” if hand-verified, which conflicts with the doc’s own later protocol to download-to-disk first, and (b) includes a direct individual name attribution. Reword to consistently recommend “download → review → execute” (no pipe-to-shell phrasing) and replace personal-name attribution with a role reference (e.g., “human maintainer policy” / “factory policy”).

[Copilot]

The referenced script path looks incorrect: the repo path is tools/setup/common/python-tools.sh, but this comment refers to common/python-tools.sh without the tools/setup/ prefix. Please fix the path so readers can find the script and pointer-integrity audits don’t flag it.

Suggested change

	# `common/python-tools.sh`. Dependabot does not support the
	# `tools/setup/common/python-tools.sh`. Dependabot does not support the

[Copilot]

The “Trusted context” list includes secrets.*, but later the checklist correctly states secrets should never be interpolated into run: strings. This is contradictory guidance in the same doc; either remove secrets.* from the trusted-to-inline list or add an explicit note that secrets are injection-safe but still must not be inlined due to log exposure.

Suggested change

	set from a trusted literal), `secrets.*`
	"Trusted" here means GitHub sets the value, not a user.
	set from a trusted literal)
	"Trusted" here means GitHub sets the value, not a user. `secrets.*`
	are not attacker-controlled for workflow-injection purposes, but
	they must still never be interpolated directly into a `run:` string;
	pass them via `env:` or an action input instead.

[Copilot]

This references “FACTORY-HYGIENE row 40” as the cadence for re-auditing the GitHub Security Lab guidance, but docs/FACTORY-HYGIENE.md row 40 is “GitHub-settings drift detector”. Either add the intended hygiene row (if this is meant to be tracked there) or update the reference to the correct existing row so the cadence pointer is accurate.

[Copilot]

The referenced file path is split across lines (...-2026- then 04-22.md), which breaks copy/paste and makes the cross-reference ambiguous. Keep paths unbroken (no hyphenation) so pointer-integrity audits and readers can reliably follow the link.

Suggested change

	Incident Playbook A, and the scanner-landscape research
	doc (`docs/research/vuln-and-dep-scanner-landscape-2026-
	04-22.md`) — which defers Trivy adoption pending
	rebuild-trust signals.
	Incident Playbook A, and the scanner-landscape research doc
	(`docs/research/vuln-and-dep-scanner-landscape-2026-04-22.md`) —
	which defers Trivy adoption pending rebuild-trust signals.

[Copilot]

The file path in backticks is broken across lines (SUPPLY-CHAIN-SAFE- + PATTERNS.md), which makes the reference incorrect if copied. Avoid hard-wrapping/hyphenating file paths; keep the full path on one line.

Suggested change

	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-
	PATTERNS.md` §"Content review is the load-bearing step"
	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-PATTERNS.md` §"Content review is the load-bearing step"

[Copilot]

This comment hard-wraps the referenced doc path across lines (docs/research/vuln-and-dep-scanner- + landscape-...), which breaks copy/paste and makes pointer-integrity checking harder. Keep repository paths unbroken on a single line.

Suggested change

	# not advisories. See `docs/research/vuln-and-dep-scanner-
	# landscape-2026-04-22.md` adopt-now item #3 for the rationale.
	# not advisories. See `docs/research/vuln-and-dep-scanner-landscape-2026-04-22.md`
	# adopt-now item #3 for the rationale.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

[Copilot]

This comment uses a direct contributor name (“Aaron”), but repo guidance is to avoid name attribution in code/docs and use role references (e.g., “human maintainer”) except in explicitly exempt surfaces. Please rewrite this to use the role reference here.

Suggested change

	# judgment stays with the reviewer and with Aaron (honesty-
	# floor owner).
	# judgment stays with the reviewer and with the human
	# maintainer (honesty-floor owner).

[Copilot]

This section both (1) frames curl | bash as “safe” if reviewed and (2) attributes policy to a named individual. In this repo, guidance is to avoid pipe-to-shell recommendations (prefer download-to-disk then execute) and to avoid name attribution in docs (use role refs like “human maintainer” outside exempt surfaces). Please reword to discourage pipe-to-shell even after review, and replace the named attribution with a role reference (or move the quote to an exempt/historical surface).

Suggested change

	points at malicious code is still malicious; a hand-verified
	script run `curl | bash`-style after a careful read is safe.
	In this factory, Aaron's standing policy (2026-04-22) is: *"never
	run a script you download without checking it for vulnerability,
	trojans and things of that nature even like gist and stuff, it's
	fine to download and run bash and things like that just validate
	them first."* So the actual author-time protocol is:
	1. **Download to disk**, do not execute.
	2. **Read the script in full** — check for sudo / privilege
	escalation, data exfiltration (`curl -X POST`, `nc`, `scp` to
	non-project hosts), shell-metacharacter injection, opaque
	base64 blobs, cryptominers, calls to suspicious domains,
	trojans masquerading as legitimate installers.
	3. **Execute if clean**; record the validation decision in the
	commit message or manifest comment.
	4. **SHA-256-pin the validated content** — the pin is then a
	cache of your review. Any bump invalidates the cache and
	forces a re-read.
	The delivery mechanism (`curl | bash` vs `curl -o path && bash
	path`) is not the risk. The risk is unvalidated content.
	points at malicious code is still malicious; even after review,
	do not execute a freshly downloaded script via `curl | bash`.
	Download it to disk first, inspect the exact bytes you plan to
	run, and only then execute the local file if it passes review.
	In this factory, the human maintainer's standing policy
	(2026-04-22) is: *"never run a script you download without
	checking it for vulnerability, trojans and things of that nature
	even like gist and stuff"* — applied here as a download-review-
	execute workflow, not a pipe-to-shell exception. So the actual
	author-time protocol is:
	1. **Download to disk**, do not execute from the network stream.
	2. **Read the script in full** — check for sudo / privilege
	escalation, data exfiltration (`curl -X POST`, `nc`, `scp` to
	non-project hosts), shell-metacharacter injection, opaque
	base64 blobs, cryptominers, calls to suspicious domains,
	trojans masquerading as legitimate installers.
	3. **Execute the reviewed local file if clean**; record the
	validation decision in the commit message or manifest comment.
	4. **SHA-256-pin the validated content** — the pin is then a
	cache of your review. Any bump invalidates the cache and
	forces a re-read.
	The key risk is unvalidated content, and pipe-to-shell removes a
	safety boundary during validation. Prefer download-to-disk, then
	review, then execute.

[Copilot]

This header comment includes an individual’s email address (ss...@google.com). Beyond name-attribution guidance, embedding personal identifiers in workflow comments tends to age badly and can be unnecessary PII in-repo. Consider replacing it with an organization/role reference (e.g., “OpenSSF maintainer”) and/or a link to the tagged release/verification evidence instead of a specific email.

Suggested change

	# 2025-09-30 by sschrock@google.com (OpenSSF maintainer),
	# 2025-09-30 by an OpenSSF maintainer,

[Copilot]

The referenced memory file memory/feedback_factory_resume_job_interview_honesty_only_direct_experience.md does not appear to exist in the repo (no matching file under memory/). Either add the missing memory entry or update this reference to the correct existing path so the workflow header doesn’t point at a dead link.

Suggested change

	# that form the factory's "job-interview honesty" surface per
	# `memory/feedback_factory_resume_job_interview_honesty_only_direct_experience.md`.
	# that form the factory's "job-interview honesty" surface.

[Copilot]

The file path in backticks is split across lines (SUPPLY-CHAIN-SAFE- then PATTERNS.md), which breaks copy/paste and makes the reference ambiguous. Keep the full path on one line (or use a markdown link) so the citation stays mechanically usable during an incident.

Suggested change

	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-
	PATTERNS.md` §"Content review is the load-bearing step"
	matters: a SHA-256 of a compromised release is still a
	valid SHA-256. We do not currently consume `trivy-action`;
	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-PATTERNS.md`
	§"Content review is the load-bearing step" matters: a
	SHA-256 of a compromised release is still a valid
	SHA-256. We do not currently consume `trivy-action`;

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

[Copilot]

Direct contributor name attribution was introduced here (and similarly in the new resume-diff workflow header). Repo convention is to avoid direct contributor names in docs/code/skills and use role references instead (e.g., “human maintainer”); names should live under memory/persona/** (docs/AGENT-BEST-PRACTICES.md:284-290). Please replace the name with a role reference and move any attribution/quote provenance to an allowed location.

Suggested change

	In this factory, Aaron's standing policy (2026-04-22) is: *"never
	run a script you download without checking it for vulnerability,
	trojans and things of that nature even like gist and stuff, it's
	fine to download and run bash and things like that just validate
	them first."* So the actual author-time protocol is:
	In this factory, the standing policy is: never run a script you
	download without checking it for vulnerabilities, trojans, or
	other hostile behaviour first. Downloading and running a script
	can be acceptable only after that validation. So the actual
	author-time protocol is:

[Copilot]

gh pr comment will fail on fork PRs when the workflow is triggered via pull_request, because GITHUB_TOKEN is read-only for forks and cannot write PR comments. Since this step runs under set -euo pipefail, the whole workflow will go red for forked contributions. Make comment posting conditional on same-repo PRs, or switch to a hardened pull_request_target design (while ensuring you never execute PR-provided code) so the workflow behaves reliably.

[Copilot]

Inline code spans can’t contain newlines; the backticked file path is split across lines (docs/security/SUPPLY-CHAIN-SAFE- / PATTERNS.md), which breaks Markdown rendering (and may confuse the reference). Keep the full path inside a single pair of backticks (or turn it into a normal link) without a hard line break.

Suggested change

	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-
	PATTERNS.md` §"Content review is the load-bearing step"
	matters: a SHA-256 of a compromised release is still a
	valid SHA-256. We do not currently consume `trivy-action`;
	scanner-adoption decisions are tracked in
	which underscores why `docs/security/SUPPLY-CHAIN-SAFE-PATTERNS.md`
	§"Content review is the load-bearing step" matters: a
	SHA-256 of a compromised release is still a valid SHA-256.
	We do not currently consume `trivy-action`; scanner-adoption
	decisions are tracked in