Skip to content

fix(scanner): skip STOR-004 on ERC-20 contract addresses#22

Merged
Markeljan merged 2 commits into
mainfrom
live-version-npm
May 22, 2026
Merged

fix(scanner): skip STOR-004 on ERC-20 contract addresses#22
Markeljan merged 2 commits into
mainfrom
live-version-npm

Conversation

@Markeljan
Copy link
Copy Markdown
Collaborator

Summary

The storage rule's STOR-004 "Hardcoded token detected" pattern was matching any variable named *token* paired with a 16+ char quoted value. That collides with the standard Web3 pattern of fromToken="0x..." / toToken="0x..." / SELL_TOKEN="0x..." carrying ERC-20 contract addresses — those are public on-chain identifiers, not credentials.

What changed

  • packages/scanner/src/rules/storage.ts — added isEvmAddressContext(content, index) and wired it into the scan loop alongside the existing isInComment / isExampleValue skips. Skip when the value is "0x" + 40 hex chars and the identifier portion (before = or :) contains token, addr, address, or contract. Splitting on the assignment operator means a trailing comment can't spoof the hint check.
  • packages/scanner/src/tests/storage.test.ts — two new tests:
    • does not flag ERC-20 contract addresses as auth tokens — covers fromToken=, toToken=, SELL_TOKEN=, BUY_TOKEN=, tokenAddress:
    • still flags JWT-style tokens even when var name contains 'token' — guards against over-broad exclusion (eyJ... JWT still detected)

Impact

Re-running bun run compare:web3:

  • Odos: 51 D → 88 B (past the original ~70+ target)
  • "Hardcoded token detected" findings: 0 across all 11 router fixtures (was producing two false positives per router with fromToken=/toToken= examples)
  • Full storage rule suite: 60/60 tests pass, 100% line coverage on storage.ts

Reviewer notes

  • The exclusion is intentionally narrow: it requires the value to match exactly "0x" + 40 hex (the EVM address shape) and an identifier hint. Auth tokens that happen to start with 0x but aren't 40-hex-char addresses still trigger.
  • Other STOR-* patterns (api_key, client_secret, password, AWS/GitHub/OpenAI/Slack value-pattern detectors) are unaffected — their identifier or value patterns don't collide with EVM addresses.
  • The two pre-existing failures in e2e/web3.test.ts (WEB3_RULES registry rule-count expectations) are present on the clean tree and unrelated to this change.

Test plan

  • bun test packages/scanner/src/__tests__/storage.test.ts — 60 pass, including 2 new
  • bun run compare:web3 — Odos 88 B, zero Hardcoded token detected across all 11 routers
  • Sanity-check that the regenerated comparison artifacts still render correctly in the landing page (not bundled here — pre-existing unrelated changes in this tree)

🤖 Generated with Claude Code

Markeljan and others added 2 commits May 21, 2026 12:14
The Header/Hero/Footer version chips were stamped into source by the bump
script on every release. They now fetch from registry.npmjs.org/agentsec/latest
via a new lib/version.ts helper using Next.js ISR (1h revalidate), with a
fallback to packages/cli/package.json on failure. Page server components
thread the resolved version to <Header>/<Hero>; Footer fetches directly.

scripts/version-stamps.ts drops the three landing entries (7 stamps -> 4)
and AGENTS.md is updated to reflect the new behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The STOR-004 "Hardcoded token detected" rule was matching any variable
named `*token*` paired with a 16+ char value, which collides with the
standard Web3 pattern of `fromToken="0x..."` / `toToken="0x..."` /
`SELL_TOKEN="0x..."` carrying ERC-20 contract addresses. Those are
public on-chain identifiers, not credentials.

Add an exclusion: when the value is `"0x" + 40 hex chars` AND the
identifier (before `=` or `:`) contains `token`, `addr`, `address`, or
`contract`, skip the finding. Splitting on the assignment operator
prevents a trailing comment from spoofing the hint check. JWT-style
auth tokens (eyJ...) still trigger normally — covered by a regression
test.

Impact on `bun run compare:web3`: Odos goes from 51 D to 88 B, and all
11 router fixtures drop their false-positive "Hardcoded token detected"
findings to zero.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Markeljan Markeljan merged commit 8d1952d into main May 22, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant