fix(NO_AUTH): treat auth.type "none"/"disabled" as unauthenticated

[dmchaledev]

Summary

A CRITICAL-severity false negative in the flagship NO_AUTH rule: a server that explicitly declares no authentication via transport.auth.type: "none" passes the gate cleanly. For a tool sold as a CI/CD security gate, this is the worst kind of bug — an unauthenticated server reports PASSED.

Repro (before this PR)

// none-auth.json — auth explicitly disabled
{
  "serverUrl": "https://x.example.com",
  "transport": { "url": "https://x.example.com", "tls": true, "auth": { "type": "none" } },
  "rateLimit": { "enabled": true, "requestsPerMinute": 100 }
}

$ node dist/cli.js none-auth.json --format=table --rule=NO_AUTH
Found 0 finding(s): 0 critical, 0 high, 0 medium, 0 low   →  PASSED   # false negative

Root cause

NO_AUTH in src/rules/auth-rules.ts counted any non-empty auth.type as authentication:

const hasAuth = config.transport?.auth &&
  (config.transport.auth.apiKey ||
   config.transport.auth.token ||
   config.transport.auth.type);   // ← "none" is truthy

So auth: { type: "none" } — the canonical way to declare no auth — made hasAuth truthy and suppressed the finding. The same held for "disabled", "off", "false", "anonymous".

Fix

An auth type now only counts as authentication when it names a real mechanism; a set of placeholder/disabled values (none, disabled, off, false, anonymous, case-insensitive, trimmed) is treated as no auth. A real credential (apiKey/token) still always counts, regardless of type. The finding now also carries evidence distinguishing the "explicitly disabled" case from "auth block absent".

$ node dist/cli.js none-auth.json --format=table --rule=NO_AUTH
CRITICAL | NO_AUTH | No Authentication Configured   →  FAILED   # now caught

Verification

• npx tsc --noEmit — clean · npm run lint (0 warnings) — clean
• npm test — 99 passed (10 new NO_AUTH cases: disabled-type variants, case-insensitivity, meaningful type, and credential-present-with-type-none)
• No regression: examples/secure-config.json → 0 findings / PASSED (no false positive); examples/vulnerable-config.json → still FAILED

This is independent of the open PR backlog — no other open PR touches the NO_AUTH logic (#18 is MISSING_TLS only). CI on this branch is green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QQgkZGTBue6Yo27iS8bPSf

---

Generated by Claude Code