@clear-capabilities/agentic-security-scanner 0.149.4 → 0.150.2

package/src/llm-validator/providers.js

@@ -31,6 +31,7 @@
 // whose entire promise is that nothing leaves the machine.
 
 import { localEndpointConfig } from './local-endpoint.js';
+import { ollamaEndpointConfig, DEFAULT_OLLAMA_MODEL } from './ollama-provider.js';
 
 // Roles the pipeline dispatches under. Closed set on purpose — see above.
 export const ROLES = Object.freeze([
@@ -113,6 +114,7 @@ const DEFAULT_MODEL = {
   openai: 'gpt-4o-mini',
   gemini: 'gemini-2.0-flash',
   local: 'local-model',
+  ollama: DEFAULT_OLLAMA_MODEL,
 };
 
 function _envKey(role, suffix) {
@@ -156,6 +158,29 @@ export function resolveProvider({ role = 'validate', env = process.env } = {}) {
     };
   }
 
+  // 1b. Ollama — a DISTINCT preset from `local` (agentic-security-ollama-
+  //     offline-prd.md §3.3): `local` keeps its existing generic
+  //     `{prompt, model}` wire shape forever, so an existing BYO/local server
+  //     that expects exactly that shape never breaks. `ollama` speaks the
+  //     real native /api/chat protocol via ollama-provider.js instead of a
+  //     SHAPES entry — see that module's header for why. `config.shape` is
+  //     deliberately absent here; callers must check `provider === 'ollama'`
+  //     and delegate to ollama-provider.js rather than assume every resolved
+  //     config carries a SHAPES-style shape.
+  if (explicit === 'ollama') {
+    const r = ollamaEndpointConfig(env);
+    if (!r.ok) return { ok: false, reason: r.reason, code: r.code };
+    return {
+      ok: true,
+      config: {
+        provider: 'ollama', shape: null, endpoint: r.config.host,
+        apiKey: null, model: model || DEFAULT_OLLAMA_MODEL,
+        egress: r.config.egress, role,
+        ollama: r.config,
+      },
+    };
+  }
+
   // 2. Explicit BYO endpoint — checked BEFORE the vendor presets because that
   //    is the documented precedence: an operator who names an endpoint means
   //    that endpoint, even with a preset also set. Reversing it would silently
@@ -212,6 +237,18 @@ export function buildProviderRequest(config, prompt, maxTokens) {
   };
 }
 
+// Architectural invariant, not a per-scan observation: nothing in this
+// module (or any caller of resolveProvider) ever reacts to a failed/refused
+// resolution by silently trying a DIFFERENT provider — a refusal is refused,
+// full stop (see the local/ollama loopback-refusal branches above, both of
+// which return `{ok:false}` rather than falling through to a vendor preset).
+// Declared once, HERE, so every place in the codebase that asserts "no cloud
+// fallback" (currently only engine.js's AI-Assistance report) reads the same
+// single source of truth instead of each hardcoding its own `false` literal
+// — if this invariant ever needs to become conditional, there is exactly one
+// place to change it and everything downstream updates with it.
+export const NO_CLOUD_FALLBACK = true;
+
 /** Which provider each role would use, for reporting. Never includes keys. */
 export function providerMatrix(env = process.env) {
   const out = {};
@@ -224,4 +261,42 @@ export function providerMatrix(env = process.env) {
   return out;
 }
 
+// `hunt` is deliberately NOT one of `ROLES` above (discovery/hunter.js's own
+// comment: it has no per-role override of its own, always falling back to
+// whatever the GLOBAL preset resolves to) — which means `providerMatrix()`,
+// built by iterating `ROLES`, structurally never sees it. Adversarial-review
+// fix (2026-09, second pass): that made `otherRemoteRoles` blind to hunt by
+// construction, not by an oversight in its filter — and hunt is exactly the
+// role most likely to diverge from `validate` in the scenario this function
+// exists to catch (a global cloud preset with `validate` given its own
+// `ollama` override: hunt then silently follows the global cloud preset).
+// Checked explicitly, alongside the `ROLES`-iterated matrix, rather than
+// added to `ROLES` itself — doing that would wrongly imply hunt supports a
+// `_HUNT`-suffixed per-role override, which it does not and this fix does
+// not add.
+const ROLES_WITH_NO_PER_ROLE_OVERRIDE = Object.freeze(['hunt']);
+
+/**
+ * Which roles OTHER than `excludeRole` resolve to a remote (non-loopback)
+ * provider right now. Exists so a report scoped to one role (the AI
+ * Assistance block's `validate`-only measurement) can disclose when a
+ * DIFFERENT role is genuinely configured for a cloud vendor at the same
+ * time, instead of leaving that role invisible to a reader who reasonably
+ * generalizes a single-role loopback claim onto the whole scan.
+ *
+ * @returns {{role:string, provider:string}[]}
+ */
+export function otherRemoteRoles(excludeRole, env = process.env) {
+  const matrix = providerMatrix(env);
+  const out = Object.entries(matrix)
+    .filter(([role, r]) => role !== excludeRole && r.provider && r.egress === 'remote')
+    .map(([role, r]) => ({ role, provider: r.provider }));
+  for (const role of ROLES_WITH_NO_PER_ROLE_OVERRIDE) {
+    if (role === excludeRole) continue;
+    const r = resolveProvider({ role, env });
+    if (r.ok && r.config.egress === 'remote') out.push({ role, provider: r.config.provider });
+  }
+  return out;
+}
+
 export const _internals = { SHAPES, DEFAULT_MODEL, _forRole };

package/src/llm-validator/redact.js

@@ -21,28 +21,144 @@
 
 const REDACTED_PLACEHOLDER = '[REDACTED-SECRET]';
 
-// Case-insensitive names that, when assigned a quoted string, are treated as
-// carrying a credential. Exact identifiers only (word-boundary matched) —
-// e.g. `password_field` does NOT match `password` because `_` is a word
-// character and blocks the trailing \b.
+// Case-insensitive names that, when assigned a string, are treated as
+// carrying a credential. `[_-]?` between compound words so a real .env/shell
+// naming convention (`DB_PASSWORD`, `STRIPE_API_KEY`) matches — those are
+// two segments joined by `_`, not one identifier, so a plain `\b` (which
+// treats `_` as a word character) would never see a boundary before
+// `PASSWORD` in `DB_PASSWORD` at all. Handled below via lookaround, not \b.
 const SECRET_KEY_NAMES = [
-  'apiKey',
-  'api_key',
+  'api[_-]?key',
   'secret',
   'token',
   'password',
   'passwd',
-  'client_secret',
-  'access_key',
-  'private_key',
+  'client[_-]?secret',
+  'access[_-]?key',
+  'private[_-]?key',
   'authorization',
 ];
 
+// Asymmetric boundary, deliberately not a plain `\b` on either side:
+//   BEFORE the name: anything non-alphanumeric counts as a boundary,
+//     INCLUDING `_`/`-` — this is what lets `DB_PASSWORD`/`stripe-api-key`
+//     match despite `_`/`-` being `\w` characters a real `\b` would treat
+//     as "still inside the same word."
+//   AFTER the name: only a non-alphanumeric, non-underscore char (or
+//     string end) counts — this is a real `\b`-equivalent on the suffix
+//     side, which is what keeps `password_field`/`tokenExpiry` from
+//     matching (a field ABOUT a secret, not a secret itself). Losing this
+//     asymmetry either direction reintroduces one of the two failure
+//     modes this module exists to avoid (see the module header).
+const NAME_BOUNDARY = (name) => `(?<![A-Za-z0-9])(?:${name})(?![A-Za-z0-9_])`;
+const KEY_NAME_ALT = SECRET_KEY_NAMES.map(NAME_BOUNDARY).join('|');
+
+// The optional quote group right after the key name handles a JSON/YAML
+// QUOTED key (`"password": "value"`) — the boundary lookaheads in
+// NAME_BOUNDARY already treat the closing quote as a valid non-alphanumeric
+// "after" boundary, but without this group the operator match immediately
+// following would fail to consume that quote char before `[:=]`.
 const KEY_VALUE_RE = new RegExp(
-  '(\\b(?:' + SECRET_KEY_NAMES.join('|') + ')\\b)(\\s*[:=]\\s*)([\'"`])([^\'"`]+)\\3',
+  '(' + KEY_NAME_ALT + ')([\'"`]?\\s*[:=]\\s*)([\'"`])([^\'"`]+)\\3',
+  'gi'
+);
+
+// Split-string-concatenation (adversarial-review fix, 2026-09, second pass):
+// `const secret = "Super" +\n  "Secret123456";` used to redact only the
+// FIRST segment — KEY_VALUE_RE matches one quoted literal, stops, and the
+// second literal (joined by `+`, possibly on its own line) survives
+// untouched, leaking the tail of the real value. Requires AT LEAST ONE `+`
+// join (`+` one-or-more, not `*`) so this pass targets only the genuinely-
+// concatenated case and never overlaps with — or double-processes — the
+// plain single-literal case KEY_VALUE_RE already owns. The whole matched
+// expression (every segment, every operator) is collapsed to ONE placeholder
+// literal rather than trying to preserve per-segment structure: a
+// concatenation is already an unusual enough shape that this codebase's
+// "value gone, structure survives" ergonomic goal is secondary to just not
+// leaking the tail half of a secret.
+const CONCAT_KEY_VALUE_RE = new RegExp(
+  '(' + KEY_NAME_ALT + ')([\'"`]?\\s*[:=]\\s*)([\'"`][^\'"`]*[\'"`](?:\\s*\\+\\s*[\'"`][^\'"`]*[\'"`])+)',
   'gi'
 );
 
+// camelCase compound identifiers (adversarial-review fix, 2026-09):
+// `authToken`, `apiSecret`, `userPassword` all leaked through the original
+// fix, which only generalized the `_`/`-`-delimited compound case
+// (`DB_PASSWORD`). A plain `i` flag doesn't help here — case-insensitivity
+// makes "Token" and "token" match the same NAME, but the boundary problem is
+// separate: `(?<![A-Za-z0-9])` still fails when "Token" is preceded by the
+// letters "auth", regardless of case. This is a SEPARATE, case-SENSITIVE
+// regex specifically for "a capitalized key-name segment immediately
+// preceded by a lowercase letter or digit" (the actual camelCase join
+// point), run as its own pass — mixing this into the case-insensitive
+// KEY_VALUE_RE would make it fire on the ALL-CAPS compound case too
+// (`DB_PASSWORD`), which is already handled and correctly rejects the
+// suffix-side `password_field` case using the case-insensitive boundary.
+//
+// Deliberately narrower than the full SECRET_KEY_NAMES list: "Key" alone
+// (for `apiKey`/`accessKey`/`privateKey`) is too generic a camelCase suffix
+// on its own (`primaryKey`, `cacheKey`, `sortKey` are not secrets) — those
+// three stay as their full compound word here, matched case-flexibly on the
+// FIRST letter of each segment only (`[Aa]pi[Kk]ey`, not full case-
+// insensitivity, to keep this pass's own boundary logic exact).
+const CAMEL_CASE_NAMES = [
+  'Token', 'Secret', 'Password', 'Passwd', 'Authorization',
+  '[Aa]pi[Kk]ey', '[Aa]ccess[Kk]ey', '[Pp]rivate[Kk]ey', '[Cc]lient[Ss]ecret',
+];
+const CAMEL_NAME_ALT = CAMEL_CASE_NAMES
+  .map((name) => `(?<=[a-z0-9])(?:${name})(?![A-Za-z0-9_])`)
+  .join('|');
+const CAMEL_KEY_VALUE_RE = new RegExp(
+  '(' + CAMEL_NAME_ALT + ')([\'"`]?\\s*[:=]\\s*)([\'"`])([^\'"`]+)\\3',
+  'g' // NOT case-insensitive — the lowercase-then-uppercase transition IS the signal
+);
+// Same split-string-concatenation fix as CONCAT_KEY_VALUE_RE, for the
+// camelCase name set.
+const CONCAT_CAMEL_KEY_VALUE_RE = new RegExp(
+  '(' + CAMEL_NAME_ALT + ')([\'"`]?\\s*[:=]\\s*)([\'"`][^\'"`]*[\'"`](?:\\s*\\+\\s*[\'"`][^\'"`]*[\'"`])+)',
+  'g'
+);
+
+// `.env`/shell-export syntax: `KEY=value` with NO surrounding quotes at all
+// — the shape secret-redaction.test.js already documented as evading
+// KEY_VALUE_RE above (that test's own comment: "Standard .env syntax...
+// evades the... catch-all, which requires a quoted value"). Anchored to
+// the start of a line (optional leading whitespace/`export `) rather than
+// matched anywhere, specifically so an ordinary code expression like
+// `if (password == expected)` or `token = someFn()` embedded mid-statement
+// is never a candidate — only a line whose FIRST token is the secret name
+// itself, exactly the shape a real `.env` file or shell script uses. `(?!=)`
+// after the operator blocks `==`/`===` from being read as `=` plus a
+// leftover comparison; a bare `!=`/`<=`/`>=` already can't match because the
+// operator class only accepts a literal `=`, not the character before it.
+// The optional third group is a non-greedy compound-identifier prefix
+// (`AWS_SECRET_` before `ACCESS_KEY`, `STRIPE_` before `API_KEY`) — the SAME
+// compound-name problem NAME_BOUNDARY solves for a single leading segment,
+// generalized to arbitrarily many, since real .env names commonly stack a
+// vendor/namespace prefix ahead of the sensitive word.
+const ENV_STYLE_RE = new RegExp(
+  '^([ \\t]*(?:export\\s+)?)([A-Za-z0-9_-]*?[_-])?(' + KEY_NAME_ALT + ')(\\s*=(?!=)\\s*)([^\\r\\n]+)$',
+  'gim'
+);
+
+// YAML `key: value` (adversarial-review fix, 2026-09): the SAME unquoted
+// shape as .env, but YAML's operator is `:`, which ENV_STYLE_RE never
+// accepted. Deliberately NOT just added to ENV_STYLE_RE's operator class —
+// `:` collides with two extremely common non-secret shapes this codebase
+// already has a pinned regression test for: a TypeScript type annotation
+// (`password: string;`) and a JS object-literal key
+// (`{ password: getSecret() }`). Neither of those is YAML, so this pattern
+// is applied ONLY when the file extension says so (see redactSecrets'
+// `filePath` option below) rather than unconditionally — the risk of the
+// blanket approach is a regression in exactly the case this module's own
+// header calls out ("redact too aggressively and the validator loses the
+// context it needs").
+const YAML_STYLE_RE = new RegExp(
+  '^([ \\t]*(?:- )?)([A-Za-z0-9_-]*?[_-])?(' + KEY_NAME_ALT + ')(\\s*:\\s*)([^\\r\\n]+)$',
+  'gim'
+);
+const YAML_EXT_RE = /\.ya?ml$/i;
+
 // `Authorization: Bearer <blob>` — the blob only, scheme word survives.
 const BEARER_RE = /\bBearer\s+[A-Za-z0-9._~+/=-]+/gi;
 
@@ -104,7 +220,7 @@ function looksLikeHighEntropySecret(inner) {
 // overlap on an already-redacted span is harmless (the value is still gone
 // exactly once; see KEY_VALUE_RE + BEARER_RE interaction for the one case
 // where both can fire on the same literal).
-export function redactSecrets(text) {
+export function redactSecrets(text, { filePath } = {}) {
   if (typeof text !== 'string' || text.length === 0) {
     return { text: typeof text === 'string' ? text : '', redactions: 0 };
   }
@@ -132,6 +248,16 @@ export function redactSecrets(text) {
     return `Bearer ${REDACTED_PLACEHOLDER}`;
   });
 
+  // 3.5. Split-string-concatenation values — MUST run before pass 4:
+  // KEY_VALUE_RE matches the first quoted segment of a concatenation too
+  // (it's a valid, if incomplete, match on its own), so if pass 4 ran first
+  // it would already have consumed and "fixed" the first segment, leaving
+  // this pass nothing to find and the second segment still exposed.
+  out = out.replace(CONCAT_KEY_VALUE_RE, (_m, keyName, opWs) => {
+    redactions++;
+    return `${keyName}${opWs}"${REDACTED_PLACEHOLDER}"`;
+  });
+
   // 4. `secretName = "value"` / `secretName: "value"` assignments.
   //
   // Special case: `authorization: "Bearer <blob>"` — keep the `Bearer `
@@ -144,6 +270,46 @@ export function redactSecrets(text) {
     return `${keyName}${opWs}${quote}${REDACTED_PLACEHOLDER}${quote}`;
   });
 
+  // 3.6. Split-string-concatenation, camelCase name set — same ordering
+  // requirement as 3.5 (must run before 4a).
+  out = out.replace(CONCAT_CAMEL_KEY_VALUE_RE, (_m, keyName, opWs) => {
+    redactions++;
+    return `${keyName}${opWs}"${REDACTED_PLACEHOLDER}"`;
+  });
+
+  // 4a. camelCase compound identifiers (`authToken = "..."`, `apiSecret: "..."`)
+  // — a case-SENSITIVE pass, separate from pass 4's case-insensitive one for
+  // exactly the reason CAMEL_KEY_VALUE_RE's own comment explains.
+  out = out.replace(CAMEL_KEY_VALUE_RE, (_m, keyName, opWs, quote, value) => {
+    redactions++;
+    const bearer = /^(Bearer\s+)(.+)$/i.exec(value);
+    if (bearer) return `${keyName}${opWs}${quote}${bearer[1]}${REDACTED_PLACEHOLDER}${quote}`;
+    return `${keyName}${opWs}${quote}${REDACTED_PLACEHOLDER}${quote}`;
+  });
+
+  // 4.5. `.env`/shell-export syntax: `KEY=value`, no quotes at all. Must run
+  // AFTER pass 4 (KEY_VALUE_RE): pass 4 already consumed every quoted
+  // occurrence, so anything ENV_STYLE_RE still finds on a candidate line is,
+  // by construction, unquoted — there is no double-redaction risk between
+  // the two passes even though their key-name sets are identical.
+  out = out.replace(ENV_STYLE_RE, (_m, lead, prefix, keyName, opWs, value) => {
+    redactions++;
+    const bearer = /^(Bearer\s+)(.+)$/i.exec(value);
+    if (bearer) return `${lead}${prefix || ''}${keyName}${opWs}${bearer[1]}${REDACTED_PLACEHOLDER}`;
+    return `${lead}${prefix || ''}${keyName}${opWs}${REDACTED_PLACEHOLDER}`;
+  });
+
+  // 4.6. YAML `key: value` — ONLY for a file the caller identifies as YAML
+  // (see YAML_STYLE_RE's own comment for why this isn't unconditional).
+  if (typeof filePath === 'string' && YAML_EXT_RE.test(filePath)) {
+    out = out.replace(YAML_STYLE_RE, (_m, lead, prefix, keyName, opWs, value) => {
+      redactions++;
+      const bearer = /^(Bearer\s+)(.+)$/i.exec(value);
+      if (bearer) return `${lead}${prefix || ''}${keyName}${opWs}${bearer[1]}${REDACTED_PLACEHOLDER}`;
+      return `${lead}${prefix || ''}${keyName}${opWs}${REDACTED_PLACEHOLDER}`;
+    });
+  }
+
   // 5. Long high-entropy string literals not caught by a more specific rule.
   out = out.replace(QUOTED_STRING_RE, (m) => {
     const q = m[0];

package/src/report/index.js

@@ -1598,6 +1598,39 @@ export function toShipVerdict(scan, options = {}) {
     lines.push(c('     /triage --explain <id>             why it fired, the data-flow trace, and the fix', DIM));
     lines.push(c('     scan . --format html -o report.html   shareable browser report (charts + filters)', DIM));
   }
+  // ollama-offline-prd.md §26 — "AI Assistance" summary. Only shown when a
+  // model tier actually ran (scan.aiAssistance is null when nothing is
+  // configured — see engine.js's own guard) so a deterministic-only scan's
+  // output is unchanged. Deliberately says "LLM inference was loopback-only"
+  // rather than "this entire scan was fully offline" (§26's own wording
+  // requirement) — this line describes the model calls, not deterministic
+  // network access elsewhere in the scan (OSV/KEV/EPSS), which is a
+  // different claim this block must not blur.
+  //
+  // Adversarial-review finding (2026-09): the header used to carry no scope
+  // qualifier and "Cloud fallback: disabled" was a hardcoded string, not
+  // read from `_ai` at all — both fixed here. The header now names the ONE
+  // role this block actually measured (`scopeRole`), and a role that
+  // resolves to a remote/cloud provider is called out explicitly rather than
+  // left for the reader to wrongly generalize the loopback claim onto.
+  const _ai = scan.aiAssistance;
+  if (_ai) {
+    lines.push('');
+    lines.push(c(`  AI Assistance (${_ai.scopeRole || 'validate'} role only)`, BOLD));
+    lines.push(c(`    Provider: ${_ai.provider || 'unknown'}   Model: ${_ai.model || 'unknown'}`, DIM));
+    lines.push(c(`    LLM egress: ${_ai.egress || 'unknown'}   Cloud fallback: ${_ai.cloudFallback ? 'enabled' : 'disabled'}`, DIM));
+    for (const [stage, s] of Object.entries(_ai.stages || {})) {
+      const parts = [`${s.calls} call${s.calls === 1 ? '' : 's'}`, `success ${s.success}`];
+      if (s.refused) parts.push(`refused ${s.refused}`);
+      if (s.failed) parts.push(`failed ${s.failed}`);
+      lines.push(c(`    ${stage.padEnd(10)} ${parts.join('   ')}`, DIM));
+    }
+    lines.push(c(`    ${_ai.egress === 'loopback-only' ? `LLM inference for the ${_ai.scopeRole || 'validate'} role was loopback-only.` : `LLM inference for the ${_ai.scopeRole || 'validate'} role used a remote endpoint.`}`, DIM));
+    if (Array.isArray(_ai.otherRolesRemote) && _ai.otherRolesRemote.length > 0) {
+      const named = _ai.otherRolesRemote.map((r) => `${r.role} (${r.provider})`).join(', ');
+      lines.push(c(`    ⚠ other role(s) configured for a remote provider, NOT covered above: ${named}`, DIM));
+    }
+  }
   // Coverage-honesty line (#5/#6): show the scan's blind spots — which
   // languages got flow analysis vs pattern-only, what was skipped, and how
   // many dangerous-looking calls had no finding. One concise line, not bloat.

package/src/sast/java-ast-folding.js

@@ -19,7 +19,23 @@
 //   - Floating-point arithmetic
 //   - long / short / byte coercion edge cases (we treat all as Number)
 
-import { parse } from '#java-parser';
+// Dynamic + try/caught, not a plain static import: java-ast-folding.js is
+// pulled in by engine.js, which every CLI invocation imports regardless of
+// language — a static import made a transient failure to resolve the
+// vendored '#java-parser' subpath (observed under heavy concurrent test
+// load: many processes resolving the same large vendored tree at once) a
+// module-LINK-time crash of the entire CLI, for every user, for every scan,
+// not just Java ones. This file already treats a `parse()` call failure as
+// non-fatal ("On parse error returns []; callers should fall back to
+// non-AST behavior" — see deadBranchRanges below); extending that same
+// degrade-to-empty philosophy to a load-time failure, instead of letting it
+// crash the process, is the fix.
+let parse = null;
+try {
+  ({ parse } = await import('#java-parser'));
+} catch {
+  parse = null;
+}
 
 // ─── CST helpers ──────────────────────────────────────────────────────────
 
@@ -518,7 +534,7 @@ function walkInterfaceDeclaration(id, out) {
 /** Parse a Java source file and return dead-branch line ranges.
  *  On parse error returns []; callers should fall back to non-AST behavior. */
 export function deadBranchRanges(source) {
-  if (!source || source.length === 0 || source.length > 800_000) return [];
+  if (!parse || !source || source.length === 0 || source.length > 800_000) return [];
   let cst;
   try {
     cst = parse(source);