fix(review): tighten mock placeholder carve-out to avoid secret-scan false negatives - #3866
Conversation
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-06 20:33:40 UTC
⏸️ Suggested Action - Manual Review
Review summary Nits — 5 non-blocking
Concerns raised — review before merging
Review context
Contributor next steps
Signal definitions
🟩 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.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3866 +/- ##
=======================================
Coverage 93.49% 93.49%
=======================================
Files 333 333
Lines 33196 33198 +2
Branches 12140 12141 +1
=======================================
+ Hits 31035 31037 +2
Misses 1530 1530
Partials 631 631
🚀 New features to boost your workflow:
|
…ds (#4604) content-lane/security-scan.ts had drifted from its two siblings (secrets-scan.ts, review-enrichment's secret-scan.ts): it was missing the LOWERCASE_HYPHENATED_MOCK_FIXTURE_PATTERN placeholder carve-out added by #3866, so a fixture value like `token: "mock-response-value"` would auto-close a legitimate content-lane submission with no human queue to catch the false positive. It was also missing the voyage_api_key and firecrawl_api_key patterns added to secrets-scan.ts by #3980, so a real Voyage/Firecrawl key embedded in a content submission produced no finding at all. Ports both fixes verbatim into the content-lane copy and adds both kinds to its HARD_SECRET_KINDS set for auto-close parity with the PR-diff gate. No shared-module extraction here — that is tracked separately in #4608.
…ds (#4604) (#4628) content-lane/security-scan.ts had drifted from its two siblings (secrets-scan.ts, review-enrichment's secret-scan.ts): it was missing the LOWERCASE_HYPHENATED_MOCK_FIXTURE_PATTERN placeholder carve-out added by #3866, so a fixture value like `token: "mock-response-value"` would auto-close a legitimate content-lane submission with no human queue to catch the false positive. It was also missing the voyage_api_key and firecrawl_api_key patterns added to secrets-scan.ts by #3980, so a real Voyage/Firecrawl key embedded in a content submission produced no finding at all. Ports both fixes verbatim into the content-lane copy and adds both kinds to its HARD_SECRET_KINDS set for auto-close parity with the PR-diff gate. No shared-module extraction here — that is tracked separately in #4608.
) PR #5346 (a resubmission of #5341) was auto-closed over two inert test-fixture strings that matched the generic_secret_assignment keyword-plus-quoted-value SHAPE but weren't real credentials -- the same heuristic has now caused at least eight prior false-positive incidents (#2613, #3178, #3673, #3866, #4587, #4733, plus several fixture-rewording commits), each patched by narrowing an allowlist rather than fixing the underlying design. REES's own copy of this rule already rates it "medium confidence" ("catches real keys but also the occasional long opaque non-secret"), and content-lane/security-scan.ts's own header states the design principle this violated: a gate that auto-closes with no human queue may only hard-close on a signal unambiguous enough that a false positive is essentially impossible. Split generic_secret_assignment out of HARD_SECRET_KINDS into a new ADVISORY_ONLY_SECRET_KINDS: it still surfaces (a warning-severity possible_secret_assignment finding / a "manual" content-lane verdict), but never auto-blocks or auto-closes on its own. Concrete credential formats (github_token, aws_access_key, private_key_block, ...) are unaffected and remain unconditional hard blockers. Also add a structural placeholder heuristic (looksLikeDescriptive PlaceholderPhrase, mirrored in REES): a value with 5+ lowercase-only hyphen/underscore segments containing an English function word reads as written prose describing the value, not a credential or a chosen passphrase -- this independently resolves both PR #5346 literals without weakening detection of a genuine human-chosen passphrase like "correct-horse-battery-secret" (no function words, by design).
Motivation
\bmock\bplaceholder term that short-circuitedisPlaceholderSecretValue, causing generic secret assignments containing a separatemocktoken to be suppressed and creating a security-relevant false negative.mock.Description
\bmock\bentry fromPLACEHOLDER_VALUE_PATTERNso values containingmockare no longer universally treated as placeholders.LOWERCASE_HYPHENATED_MOCK_FIXTURE_PATTERNto precisely match lowercase hyphenated mock fixture names and treat only those as placeholders.isPlaceholderSecretValueto consider the newLOWERCASE_HYPHENATED_MOCK_FIXTURE_PATTERNbefore excluding a match.mock-...credential values and a safety-gate regression to ensure such cases produce ageneric_secret_assignmentand asecret_leakfinding (test/unit/secrets-scan.test.tsandtest/unit/safety-wiring.test.ts).Testing
git diff --checkand the focused unit suite vianpm test -- --run test/unit/secrets-scan.test.ts test/unit/safety-wiring.test.ts, and those tests passed.npm run test:coverage, which did not complete due to an unrelated recursion intest/unit/queue.test.tsproducing aRangeError: Maximum call stack size exceeded.npm audit --audit-level=moderate, but the registry audit endpoint returned403 Forbiddenso the audit step could not be completed.Codex Task