ci: commit security-review path scope to .github/claude-security-paths

[kyle-sexton]

No linked issue

Summary

Commits the repo's security-review path scope as .github/claude-security-paths — the caller's 26-entry inline paths list from .github/workflows/claude-security-review.yml, migrated verbatim (same patterns, same order) with a header comment stating the file's contract.

Sequencing safety, per the ci-workflows reusable's input descriptions (melodic-software/ci-workflows .github/workflows/claude-security-review.yml@main):

• Inert now. The live caller passes the list inline via paths, and a non-empty paths input wins over paths-file, so this file has no effect until the caller changes.
• Load-bearing later. The upcoming fleet-synced caller replaces the hand-written workflow with a component that passes only paths-file: .github/claude-security-paths, read from the PR's BASE branch. An absent file FAILS OPEN — every PR reviewed — so this file must land before that sync to keep the tuned scope.

The caller workflow itself is deliberately untouched; the sync replaces it.

Test plan

• Scripted verbatim proof: parsed the caller's paths input with PyYAML, normalized both lists (comments/blanks stripped), compared — 26 inline entries vs 26 file entries, byte-identical, same order
• File hygiene per .editorconfig/.gitattributes: LF only, single final newline, no trailing whitespace, UTF-8 without BOM
• No workflow or other file changed (single-file diff)

Related

• melodic-software/ci-workflows reusable claude-security-review.yml — owns the paths / paths-file precedence contract and names .github/claude-security-paths as the conventional location
• Upcoming standards fleet sync that replaces this repo's hand-written security caller with the paths-file component

🤖 Generated with Claude Code

[claude]

Claude finished @kyle-sexton's task in 1m 37s —— View job

---

PR Review — ci: commit security-review path scope to .github/claude-security-paths

• Gather context
• Read changed file
• Verify path patterns match inline list
• Check alignment with project conventions
• Post findings

---

Summary

Single-file addition: .github/claude-security-paths — a preparatory scope file for the upcoming paths-file-based fleet-synced caller.

Verdict: looks good, no blocking issues.

---

Findings

Pattern fidelity — confirmed correct.
Manually compared the 26 entries in the new file (lines 6–31) against the 26 inline entries in .github/workflows/claude-security-review.yml (lines 37–62). Order and content are identical byte-for-byte. The PR description's PyYAML-based proof is consistent with the visual diff.

Sequencing safety — sound.
The PR body is accurate: the reusable's paths input takes precedence over paths-file when non-empty, so this file is genuinely inert until the caller is replaced. Committing the scope file first is the correct order; the fail-open note in the header is accurate and important for future maintainers.

Self-coverage — correct.
.github/** (line 6) covers .github/claude-security-paths itself, so any future scope change will trigger a security review. This is the right behavior.

File hygiene.
The .editorconfig [*] rule (LF, final newline, no trailing whitespace, UTF-8) applies to extensionless files. The file terminates cleanly at line 31 with a single trailing newline, no CRLF, no BOM. Compliant.

Dual MCP naming — deliberate and correct.
The two entries **/.mcp.json and **/mcp.json cover both naming conventions in the wild. No concern.

Header comment — accurate and useful.
The contract note (paths-file input, BASE branch read, fail-open behavior, format spec) is exactly what a future maintainer needs before editing this file. Well done.

---

Observations (non-blocking)

• No **/*.py coverage — Python files aren't included, which is consistent with the inline list. If Python scripts are added to the repo later (e.g. in scripts/), scripts/** still catches them, so this isn't a gap for the current layout.
• plugins/*/.claude-plugin/plugin.json is partially redundant with plugins/*/skills/** etc., but the plugin manifest is significant enough to call out explicitly, and redundancy in a path-scope file is harmless.

[claude]

Claude finished @kyle-sexton's task in 1m 30s —— View job

---

Security Review — PR #1701

• Gather context and understand request
• Read changed file
• Analyze for security issues
• Post findings

---

This PR adds a single text data file (.github/claude-security-paths) defining path scope for the Claude security review CI workflow. No code executes; the file is pure configuration consumed by an external reusable workflow.

Trust-boundary assessment

The key security property the PR description claims — that the consuming workflow reads this file from the BASE branch, not the PR head — is the critical invariant. If that holds, a contributor cannot modify this file within a PR to shrink the review scope for that same PR. The PR correctly identifies this as load-bearing: the file only takes effect when the fleet-synced caller switches to paths-file; the current inline paths wins now. That sequencing is sound.

The fail-open absent-file behavior (every PR reviewed when the file is missing) is the correct secure default. Removing the file makes the gate wider, not narrower.

Pattern coverage

plugins/*/hooks/** and the other plugins/*/ globs use a single-level *, which matches exactly one directory level. This correctly reflects the flat plugin layout (plugins/<name>/hooks/...) and is not a gap for the current structure.

.github/** covers this file itself, so any future modification to the review scope will itself be subject to security review. Self-referential — good.

**/*.yml / **/*.yaml are not in the list. Workflow files under .github/ are covered by .github/**, and plugin manifests are covered by plugins/*/.claude-plugin/plugin.json. If this repo ever adds YAML-based plugin configuration outside .github/, those files would be outside the review gate. No current exposure; worth bearing in mind as the plugin format evolves.

Findings

No security vulnerabilities found. The file introduces no executable surface, no secrets, no trust delegation, and no permission widening. The fail-open default and BASE-branch-read semantics are the right architecture for a scope gate of this kind. Nothing here for static analysis to have missed, and nothing I can find through logic or data-flow reasoning.