[ci] Add static defensive validation workflow - #2
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 061a5850ed
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| run: | | ||
| set -euo pipefail | ||
|
|
||
| pattern='innerHTML|outerHTML|insertAdjacentHTML|eval\(|new Function' |
There was a problem hiding this comment.
In this workflow, the dynamic-execution guard only matches the exact tokens eval( and new Function. If a future runtime change uses valid JavaScript such as eval (value) or Function("..."), node --check still passes and this grep does not report it, so the CI gate can approve code that reintroduces dynamic execution despite the step name claiming to block it. Please broaden the expression to cover whitespace and the Function constructor forms you intend to forbid.
Useful? React with 👍 / 👎.
|
|
||
| pattern='innerHTML|outerHTML|insertAdjacentHTML|eval\(|new Function' | ||
|
|
||
| if grep -RInE "$pattern" app.js index.html; then |
There was a problem hiding this comment.
With this grep target list, a PR can add and load a new script such as helper.js from index.html while leaving app.js unchanged; the workflow still only scans app.js and index.html, so helper.js could contain innerHTML/outerHTML and pass the gate. Since the required-file check does not forbid additional runtime files, scan all tracked HTML/JS assets or resolve scripts from index.html before declaring the unsafe-pattern check passed.
Useful? React with 👍 / 👎.
| run: | | ||
| set -euo pipefail | ||
|
|
||
| pattern='SECRET|TOKEN|API[_-]?KEY|PASSWORD|PRIVATE KEY|OPENAI_API_KEY|client_secret|sk-[A-Za-z0-9]|ghp_|github_pat_' |
There was a problem hiding this comment.
This grep is case-sensitive, so runtime secrets named with common lowercase identifiers such as password or api_key are not reported even though the policy and checklist treat those as forbidden secrets. In a future change to the scanned runtime files, const password = ... or api_key = ... would pass CI, leaving the secret-pattern gate ineffective for common naming conventions; use a case-insensitive match or include lowercase variants.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,134 @@ | |||
| name: Static Defensive Validation | |||
There was a problem hiding this comment.
Adding this workflow makes the repository evidence stale: docs/evidence/02_security_triage.md still says “No automated CI workflow exists,” docs/remediation/remediation_plan.md still defers “add GitHub Actions CI,” and docs/validation/validation_report.md still lists CI as a pending later PR. Because this lab treats audit-ready evidence as part of the deliverable, the new CI file should be reflected in those required docs before merging.
Useful? React with 👍 / 👎.
| for claim in "${required_claims[@]}"; do | ||
| if ! grep -RInF "$claim" README.md docs SECURITY.md >/dev/null; then |
There was a problem hiding this comment.
This loop only checks that the bounded-claim strings exist somewhere, so a future README or evidence file can keep the required disclaimer while also adding a contradictory claim such as OpenAI acceptance or authorization, and the workflow will still pass. Since the documented risk is public overclaiming, add a forbidden-claim scan rather than only requiring the disclaimer text to be present.
Useful? React with 👍 / 👎.
1 participant
Summary
Adds a GitHub Actions workflow for static defensive validation of the Daybreak Defensive Remediation Lab.
What the workflow checks
app.jspasses JavaScript syntax validation withnode --check app.js.innerHTMLouterHTMLinsertAdjacentHTMLeval(new Function.netlify/.zip.tar.tar.gz.7z.logDefensive scope
This workflow performs static repository validation only. It does not scan external targets, install project dependencies, run offensive tests, or interact with third-party systems.
Why this matters
This turns the previous manual PowerShell validation into a repeatable PR gate. The next remediation cycle becomes more audit-ready because GitHub records validation evidence automatically on pull requests.