job_scraper/seen_jobs.json (and notion_sync.json / *.md) were ignored by a repo-rooted pattern, but the job-scraper skill resolves job_scraper/ relative to its own directory, so the state file lands at .claude/skills/job-scraper/job_scraper/ and the rule never matched - publishing every scraped posting with fit scores and skip-reasons on a public fork. Switches to **/-prefixed patterns that match at any depth (the rooted location still matches too, so no regression), and adds documents/interview/** (interview prep names employers, quotes submitted material, and lists the candidate's weak points) - it was never ignored though documents/applications/** was. REQUIRED_IGNORE_RULES updated in lockstep so the security guard stays in sync.
By @LeoWinston-9596 (split from #199). Verified: both nested and root seen_jobs.json now ignored, interview records ignored, guard suite green (17 tests incl. #195's negation checks). Rebased cleanly on current master.
check_gitignore() verified each required personal-data rule was present via set membership, but .gitignore is order-sensitive: a later !pattern re-includes a file an earlier rule excluded, so the required line stays physically present while the file is no longer ignored - the guard failed open on exactly the weakening its docstring claims to catch. Keeps the required-rules-present check and additionally rejects any negation line outside a small reviewed ALLOWED_IGNORE_NEGATIONS allowlist (same explicit-widening pattern as ALLOWED_PERMISSIONS). Fixes#194.
By @thejesh23. Verified: allowlist matches the four negations currently in .gitignore; guard test suite passes locally (17 tests) and in CI.
Closes#194
* ci: add supply-chain guards - permission allowlist, gitignore rules, manifest checks, pinned actions
This template's threat model is unusual: it ships pre-approved Claude Code
permissions (.claude/settings.json) and CLI code that every fork user
executes via those permissions. A plausible-looking PR could therefore
ship risk to every forker: widen a permission to Bash(*), weaken the
personal-data gitignore rules, or smuggle code execution into bun install
via a lifecycle script. Nothing checked for these mechanically.
New job security-guards runs tools/security_guards.py (stdlib only):
- settings.json: every permissions.allow entry must be in an exact,
in-repo allowlist. The guard makes permission changes loud, not
impossible - a PR that intentionally widens permissions must update
the allowlist in the same diff, so the widening is explicit and
reviewable
- .gitignore: the personal-data rules (tracker, documents/**, cv/main_*,
salary data, seen_jobs) must all still be present - the mirror image
of the placeholder-integrity job
- .agents/**/package.json: no lifecycle scripts (preinstall/install/
postinstall/prepare/prepack) and no trustedDependencies, which would
execute arbitrary code during bun install on users' machines
New job dependency-review (PRs only): actions/dependency-review-action
flags newly introduced vulnerable or malicious dependencies,
fail-on-severity high.
Workflow hardening: explicit top-level permissions: contents: read
(least-privilege token), and all actions pinned to commit SHAs resolved
from the same major tags already in use (checkout v4, setup-python v5,
setup-bun v2), with the tag recorded in a comment.
Honest limit, recorded in the workflow header: a PR can edit this
workflow itself, so these guards catch accidents and casual attempts,
not a determined author. Branch protection with required checks and
human review of workflow/settings diffs remain the real backstop.
Verified locally: positive run passes; injecting Bash(*) into
settings.json, deleting the tracker gitignore rule, and adding a
postinstall script each fail the guard with the intended message, and
reverting restores a clean pass.
* ci: scope dependency-review to upstream PRs - forks lack Dependency graph by default
Verified on a fork: the action fails with 'Dependency review is not
supported on this repository' until Dependency graph is manually enabled,
and forks don't inherit it. Guarded with the same
github.repository == upstream condition the other upstream-only jobs use.
With the graph enabled the action passes, so the config itself is sound.
* ci: probe Dependency graph before dependency-review - warn and pass when unavailable
The upstream PR run showed Dependency graph is disabled on the upstream
repo too (the action hard-fails: 'Dependency review is not supported on
this repository'), not just on forks. Only the repo owner can enable it,
so a hard red X here is friction, not signal.
The job now probes the dependency-graph SBOM endpoint with the workflow
token first: HTTP 200 runs the real review; anything else emits a
::warning:: naming the setting to flip (Settings -> Advanced Security ->
Dependency graph) and passes. Same graceful-skip pattern the workflow
uses for optional tools - the check self-activates the moment the graph
is enabled, no workflow change needed.
LeoWinston-9596