feat(enrichment): flag insecure HTTP security-header settings in iac-misconfig

[luciferlive112116]

Summary

The IaC-misconfig analyzer already covers Kubernetes, Dockerfile, Docker Compose, and TLS-bypass
misconfigurations. This adds 5 HTTP security-header rules for insecure header values that appear in the
config files the analyzer already scans (nginx*.conf, .conf, YAML/Helm ingress annotations, .toml, .json):

kind	fires on	risk
csp-unsafe-inline	'unsafe-inline' in a Content-Security-Policy	permits inline scripts/styles (weakens XSS defense)
csp-unsafe-eval	'unsafe-eval' in a Content-Security-Policy	permits eval() (weakens XSS defense)
hsts-disabled	Strict-Transport-Security … max-age=0	disables HSTS (browsers stop enforcing HTTPS)
referrer-policy-leak	Referrer-Policy: unsafe-url	leaks the full URL (path + query) cross-origin
cookie-not-httponly	httpOnly: false	exposes the cookie to JavaScript (XSS can read it)

Why these are false-positive-safe: in every rule the matched value is the weakening itself — there is no
"safe value" form of the same line. unsafe-inline/unsafe-eval are Content-Security-Policy-exclusive keywords
(a unsafe_inline identifier with an underscore does not match). The HSTS and Referrer-Policy rules require
their own header token to be present on the line, so a normal Cache-Control: max-age=0 caching directive is
not matched by the HSTS rule (asserted in the negative test). The secure value of each setting uses a
different token the regex never matches ('self', max-age=31536000, strict-origin-when-cross-origin,
httpOnly: true), which the negative test asserts produces no finding.

No existing rule is modified, and the analyzer's finding schema is {file, line, kind} — the kind union is
not part of the analyzer descriptor, so analyzer-metadata.json and the generated UI mirror are unchanged.
The render-brief switch is TypeScript-exhaustive, so each new kind is compiler-forced to have a public-safe
explanation.

No linked issue: additive detection-coverage that extends an existing multi-domain analyzer along its own
established lines; each rule is a self-evident, named HTTP-hardening check (OWASP Secure Headers) with no public
API/schema/deploy surface change — fits the repo's preferred (not required) linked-issue policy.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run typecheck
• npm run rees:test — the review-enrichment build + analyzer suite (see note below)
• npm run test:coverage (N/A — this analyzer is in review-enrichment/, outside the root src/** Codecov scope)
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• Ran locally: git diff --check (clean), the review-enrichment TypeScript build (exit 0 — which proves the
  render switch is exhaustive over the 5 new kinds), and the analyzer suite via node --test. The
  iac-misconfig file passes 21/21: a table test asserting each of the 5 settings produces exactly one finding
  of its own kind, and a negative test asserting the secure counterpart of each — including a normal
  Cache-Control: max-age=0 (which must NOT fire the HSTS rule) — produces none. The full node --test run's
  only failures are the two upload-sourcemaps tests (they shell out to the Sentry CLI, absent on this dev
  box), which fail identically on unmodified main.
• Not run locally: the UI, root typecheck, and the metadata:check step of rees:test. This change adds only
  finding kinds and rules, not any analyzer descriptor field, so the committed analyzer-metadata.json / UI
  mirror are unchanged (a local regeneration produces a zero-content diff) and metadata:check passes on CI
  (Linux). On this Windows dev box metadata:check reports a spurious line-ending difference; it fails
  identically on unmodified main. analyzer-metadata.json was NOT modified.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

Notes

• Detection-only additions: 5 new stateless rules following the existing single-line pattern; no existing rule,
  threshold, or descriptor changed, so current findings and analyzer-metadata.json are unaffected. Each new
  kind reports only file:line + the public-safe kind, never the matched line content.
• The HSTS and Referrer-Policy rules are anchored to their own header token so an unrelated line carrying the
  same value (e.g. Cache-Control: max-age=0) is never flagged.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[gittensory-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-05 05:20:29 UTC}

4 files · 1 AI reviewer · 1 blocker · readiness 80/100 · CI green · clean

🛑 Suggested Action - Reject/Close

• AI reviewers agree on a likely critical defect: review-enrichment/src/analyzers/iac-misconfig.ts:132 and review-enrichment/src/analyzers/iac-misconfig.ts:529 flag `unsafe-inline`/`unsafe-eval` anywhere in an admitted config file, so an added non-CSP line such as `+ unsafe-inline = false` or a documented allowlist value produces a `csp-*` finding even though no `Content-Security-Policy` is being configured
• change the regex/check to require the CSP header token on the same parsed line, or give me a concrete reason this analyzer intentionally treats the token alone as CSP context, e.g. `const CSP_UNSAFE_INLINE_RE = /\bContent-Security-Policy\b[^\n]*\bunsafe-inline\b/i
• ` and add the matching negative test. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
This adds HTTP security-header findings to the existing IaC patch scanner and wires the new kinds through rendering and the finding type union. The render/type wiring is complete, and the direct positive/negative tests cover the newly added happy paths. I do see one reachable analyzer correctness issue: the CSP rules do not actually require a CSP header/context despite the PR claiming they do, so they can emit CSP findings for any config line that merely mentions those tokens.

Blockers

• review-enrichment/src/analyzers/iac-misconfig.ts:132 and review-enrichment/src/analyzers/iac-misconfig.ts:529 flag `unsafe-inline`/`unsafe-eval` anywhere in an admitted config file, so an added non-CSP line such as `+ unsafe-inline = false` or a documented allowlist value produces a `csp-*` finding even though no `Content-Security-Policy` is being configured; change the regex/check to require the CSP header token on the same parsed line, or give me a concrete reason this analyzer intentionally treats the token alone as CSP context, e.g. `const CSP_UNSAFE_INLINE_RE = /\bContent-Security-Policy\b[^\n]*\bunsafe-inline\b/i;` and add the matching negative test.

Nits — 5 non-blocking

• nit: review-enrichment/src/analyzers/iac-misconfig.ts:136 does not match the common underscore-prefixed setting shape `cookie_http_only = false` because `\bhttp` will not start after `_`; consider covering `(?:cookie[_-]?)?http[_-]?only` if that spelling is in scope.
• nit: review-enrichment/test/iac-misconfig.test.ts:447 only tests CSP tokens on CSP lines, so it misses the false-positive path introduced by the token-only regex; add a negative case for `unsafe-inline`/`unsafe-eval` outside a CSP header.
• At review-enrichment/src/analyzers/iac-misconfig.ts:132, make the CSP detection match the same-source requirement the HSTS and Referrer-Policy rules already use: require `Content-Security-Policy` plus the weakening token on the line, or split multiline CSP support into an explicit stateful parser with tests.
• At review-enrichment/test/iac-misconfig.test.ts:467, extend the secure HTTP-header test with non-CSP uses of `unsafe-inline` and `unsafe-eval` so future regex drift cannot reintroduce broad token matching.
• At review-enrichment/src/analyzers/iac-misconfig.ts:136, decide whether underscore cookie settings are intended coverage and either broaden the regex or add a negative test documenting that only `httpOnly`/`http-only` keys are supported.

Why this is blocked

• review-enrichment/src/analyzers/iac-misconfig.ts:132 and review-enrichment/src/analyzers/iac-misconfig.ts:529 flag `unsafe-inline`/`unsafe-eval` anywhere in an admitted config file, so an added non-CSP line such as `+ unsafe-inline = false` or a documented allowlist value produces a `csp-*` finding even though no `Content-Security-Policy` is being configured; change the regex/check to require the CSP header token on the same parsed line, or give me a concrete reason this analyzer intentionally treats the token alone as CSP context, e.g. `const CSP_UNSAFE_INLINE_RE = /\bContent-Security-Policy\b[^\n]*\bunsafe-inline\b/i;` and add the matching negative test.

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 142 registered-repo PR(s), 79 merged, 21 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	luciferlive112116; Gittensor profile; 142 PR(s), 21 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: luciferlive112116
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 142 PR(s), 21 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[gittensory-orb]

Gittensory is closing this pull request on the maintainer's behalf (AI reviewers agree on a likely critical defect: review-enrichment/src/analyzers/iac-misconfig.ts:132 and review-enrichment/src/analyzers/iac-misconfig.ts:529 flag `unsafe-inline`/`unsafe-eval` anywhere in an admitted config file, so an added non-CSP line such as `+ unsafe-inline = false` or a documented allowlist value produces a `csp-*` finding even though no `Content-Security-Policy` is being configured; change the regex/check to require the CSP header token on the same parsed line, or give me a concrete reason this analyzer intentionally treats the token alone as CSP context, e.g. `const CSP_UNSAFE_INLINE_RE = /\bContent-Security-Policy\b[^\n]*\bunsafe-inline\b/i;` and add the matching negative test.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.