@clear-capabilities/agentic-security-scanner 0.161.0 → 0.162.0

package/CHANGELOG.md

@@ -9,6 +9,26 @@
 > make the history less accurate, not more.
 
 
+## 0.162.0 - first slice of the differentiation programme: versioned evidence contracts, an enforced trust boundary, one verification record, trusted oracles, patch-negative verification, and a conformance gate
+
+This is the foundation and verification slice of the Agentic Security Differentiation PRD (CORE-001 to 004, CORE-003 trust boundary, LOOP-001, X-201 to X-208). It is **not** the whole programme: the evaluation work (QA-001 to 008, which holds the accuracy gates), the deployment graph, tenant invariants, capability enforcement, model routing and portfolio assurance are unstarted, and no accuracy number is claimed or changed by this release. The new capabilities that execute anything are off by default.
+
+**Evidence contracts (CORE-001, 002).** Versioned schemas, validators, stable identities and legacy migration adapters for verification records, observation bindings, capability decisions, routing labels and release evidence. A model verdict can only ever be an inference: `confirmed` needs trusted runtime proof or independent adjudication, and the six states (not-run, unsupported, inconclusive, error, refuted, confirmed) stay distinct through every round trip. A baseline capture tool (`npm run baseline:capture`) records source and bundle digests, dirty paths and an inventory of 18 existing capabilities, each checked against real paths and symbols; it invalidates only the capabilities whose files changed and never modifies source.
+
+**Trust boundary (CORE-003).** Four trust domains (target, worker, verifier, signer) with a default-deny policy. `runInBoundary` runs a target only after active probes prove the controls it needs, and returns `blocked` (target never run) otherwise; target output is untrusted and never sets a status. Process trees are killed on timeout or cancel, with a descendant sweep and an orphan check. Signed evidence bundles now carry an `issuance` block that labels them `self-issued-local-key`, never independently certified. **Compatibility:** bundles signed before this release still verify and report no declared trust basis, but a verifier older than this release rejects newly signed bundles (strict unknown-key rule).
+
+**One verification record, oracles, replay (X-201 to X-203).** Every verification surface emits the same record. Seven oracle adapters (injection execution, authorization decision, state transition, side-effect reachability, parser/resource behaviour, replay/idempotency, functional regression) each have positive, negative and inconclusive fixtures; an unavailable prerequisite is `unsupported`, never a pass. Replay manifests pin commit, patch, fixture, toolchain, oracle and budgets and reject any that fail validation.
+
+**Patch-negative verification and non-taint classes (X-204, X-205).** A fix reaches `verified-fix` only with an exploit-positive original, an exploit-negative patched revision and a passing functional check; the specific incomplete step is recorded otherwise, and promotion requires receipts bound to the exact diff and revision. Tenant authorization, privileged action, workflow order, replay/idempotency and bounded resource exhaustion have executable oracles; taint absence never refutes them.
+
+**Parity, gating and conformance (X-206 to X-208).** CLI JSON, MCP, reports and the autopilot response now share one projection (`verificationView`, additive; previous output fields are pinned by fixtures; migration notes in `docs/guides/verification-schema-migration.md`). Advisory hunt hypotheses cannot touch authoritative scan state and are promoted only with a verified receipt and an explicit policy, never on confidence or model agreement. A conformance suite over all oracle adapters runs as a new release check (`verification-conformance-gate`).
+
+**Loop registration (LOOP-001).** `assurance-differentiation` profile for the supervised controller: the unmodified importer parses all 70 requirements, 269 weight and 210 criteria. Preflight on the real profile refuses launch, by design, until the other suites have runnable wrappers. Several limits the PRD names (heartbeat setting, subprocess wall time, network limits, provider envelope) are not enforced by the controller and are listed as unenforced.
+
+**Known issue, not fixed here (present since at least 0.161.0).** The taint engine reports a regular expression's `.exec()` called on request data as a high-severity command injection (`child_process.exec`), for example `SEMVER.exec(req.query.v)`. This is a false positive that will appear in ordinary JavaScript. Fixing the sink model touches the corpus and recall gates, so it is left for its own change. The self-scan baseline records the two such findings in this repository as reviewed false positives.
+
+**Not verified here.** Everything that executes targets was exercised on macOS only; Linux enforcement is declared unverified in every manifest, and on a host where the boundary cannot run the conformance gate reports execution as not-run, never passed. Receipts are unsigned and valid only within the verifier's process. The patch-negative ledger and the promotion audit record are returned, not persisted.
+
 ## 0.161.0 - the first honest out-of-sample numbers, a ReDoS in the scanner itself fixed, large Haskell projects now finish, multi-file fixes over MCP, auth-guard order proved structurally, sturdier tests and a sharded CI
 
 **Measured, and not flattering.** The unseen shape set the engine had been tuned against (v2) was retired and a fresh one (v3: 13 Haskell and 12 Nix families, 300 cases, written without reading the engine's rules) was measured exactly once, with nothing tuned afterwards. On it: Haskell SAST precision 75.0% / recall 50.0% / F1 60.0% (24 TP, 8 FP, 24 FN); Haskell taint 84.6% / 73.3% / 78.6%; Nix config-SAST 100% / 87.9% / 93.5%; Nix config-taint precision 60.0% (all four false positives are duplicate findings on scripts the new set's author wrote with two sinks each, an authoring artefact, not an engine fault). The previous set had scored the Haskell rows 91.7% and 93.3% after being tuned against. All four generalization rows are now below target and the published support tables say so. The misses are concrete and listed in `docs/language-support.md` (for example session cookies set without Secure, missing ownership checks in Yesod and Servant handlers, `randomIO` as a CSRF token, `printf` logging a secret, some HDBC, Scotty `file` and `Network.HTTP.Req` shapes). Closing them is a tuning round that consumes this set; it was deliberately not done here, so the numbers stand as measured. The retired set is kept as a development set (`shape-dev-2`), which now scores 96% to 100%: that is a tuned-on set and is not a generalization number.

package/bin/agentic-security.js

@@ -2290,7 +2290,7 @@ async function cmdVerify(args) {
     process.env.AGENTIC_SECURITY_VERIFY_LIVE = '1';
     process.env.AGENTIC_SECURITY_VERIFY_TARGET = targetFlag;
   }
-  const { annotateVerifierVerdicts, verifierCoverageSummary, recordVerifierRun } = await import('../src/posture/verifier.js');
+  const { annotateVerifierVerdicts, verifierCoverageSummary, recordVerifierRun, verifierVerificationRecords } = await import('../src/posture/verifier.js');
   const filter = args.flags.finding ? findings.filter(f => f.id === args.flags.finding || f.stableId === args.flags.finding) : findings;
   if (!filter.length) {
     console.error(`No matching findings (use --finding <id>).`);
@@ -2319,7 +2319,13 @@ async function cmdVerify(args) {
   // Adversarial premortem Q1: a durable record that a security assessment of
   // findings actually happened, so module:verifier has something real to
   // point at (see verifier.js's recordVerifierRun header comment).
-  recordVerifierRun(scanRoot, { findingCount: filter.length, live: liveFlag, target: targetFlag || null, summary: sum });
+  // X-201: one version-1 verification record per verified finding, in the durable run record (never on the findings,
+  // which are written back to last-scan.json below).
+  const { headCommit } = await import('../src/posture/verification/emit.js');
+  recordVerifierRun(scanRoot, {
+    findingCount: filter.length, live: liveFlag, target: targetFlag || null, summary: sum,
+    verificationRecords: verifierVerificationRecords(filter, { commit: headCommit(scanRoot) }),
+  });
   if (args.flags.verbose || args.flags.finding) {
     for (const f of filter) {
       console.log(`  ${f.file}:${f.line}  ${f.vuln}`);
@@ -3289,6 +3295,9 @@ async function cmdVerifyAttestation(args) {
   console.log('');
   console.log(`  proves:        ${bundle.proves}`);
   console.log(`  does NOT prove: ${bundle.doesNotProve}`);
+  // CORE-003.AC03: who vouches. Informational only; the exit code is unchanged.
+  console.log(`  trust basis:   ${r.trustBasis}${r.issuer ? ` (issuer ${r.issuer.id})` : ''}`);
+  console.log(`  ${r.trustNote}`);
   return 0;
 }
 

package/dist/4113.index.js

@@ -531,6 +531,7 @@ __webpack_require__.a(__webpack_module__, async (__webpack_handle_async_dependen
 /* harmony import */ var node_fs__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(73024);
 /* harmony import */ var node_path__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__(76760);
 /* harmony import */ var _fix_verify_js__WEBPACK_IMPORTED_MODULE_3__ = __webpack_require__(27838);
+/* harmony import */ var _verification_emit_js__WEBPACK_IMPORTED_MODULE_4__ = __webpack_require__(85578);
 var __webpack_async_dependencies__ = __webpack_handle_async_dependencies__([_fix_verify_js__WEBPACK_IMPORTED_MODULE_3__]);
 _fix_verify_js__WEBPACK_IMPORTED_MODULE_3__ = (__webpack_async_dependencies__.then ? (await __webpack_async_dependencies__)() : __webpack_async_dependencies__)[0];
 // Closed-loop fix verification (v0.68).
@@ -559,6 +560,7 @@ _fix_verify_js__WEBPACK_IMPORTED_MODULE_3__ = (__webpack_async_dependencies__.th
 
 
 
+
 const DEFAULT_TIMEOUT_MS = 120_000;
 
 // Test-runner discovery. Each entry: a sentinel-file check + a command +
@@ -666,20 +668,32 @@ async function verifyFixWithTests({
   runTests = true,
   testRunnerOverride,
   testTimeoutMs,
+  patchNegative,
+  assuranceConfig,
 } = {}) {
-  const scanLint = await (0,_fix_verify_js__WEBPACK_IMPORTED_MODULE_3__.verifyFix)({ scanRoot, originalFindingStableId, files, depFileContents });
+  const scanLint = await (0,_fix_verify_js__WEBPACK_IMPORTED_MODULE_3__.verifyFix)({ scanRoot, originalFindingStableId, files, depFileContents, patchNegative, assuranceConfig });
   const legs = {
     scan: { ok: scanLint.rescan?.ok ?? scanLint.ok, detail: scanLint.rescan ?? scanLint },
     lint: { ok: scanLint.lint?.ok ?? true, detail: scanLint.lint ?? null },
     tests: { ok: true, detail: null, skipped: true, reason: 'not-run' },
   };
-  if (!legs.scan.ok || !legs.lint.ok) {
-    return {
+  // X-201: the closed loop's own record (additive). It runs the detector, linter and project tests, never an exploit
+  // oracle, so it can say `not-run` or `error` and nothing stronger.
+  const withRecord = (res) => {
+    const e = (0,_verification_emit_js__WEBPACK_IMPORTED_MODULE_4__/* .emitVerification */ .T)('fix-verify-loop', res, { originalFindingStableId, files, scanRoot });
+    return { ...res, verificationRecord: e.ok ? e.record : null };
+  };
+  // X-204: the patch-negative leg is present only when it was requested and its feature is on. A patch the oracle did not verify
+  // is never `verified-clean`, whatever the other legs say.
+  const pn = scanLint.patchNegative && scanLint.patchNegative.status !== 'disabled' ? scanLint.patchNegative : null;
+  if (pn) legs.patchNegative = { ok: pn.verifiedFix === true, detail: { status: pn.status, incompleteStep: pn.incompleteStep, failureCode: pn.failureCode, reason: pn.reason } };
+  if (!legs.scan.ok || !legs.lint.ok || (pn && !legs.patchNegative.ok)) {
+    return withRecord({
       ok: false,
       verdict: 'verification-failed',
       legs,
       summary: _summarize(legs, 'verification-failed'),
-    };
+    });
   }
   if (runTests) {
     const tests = runProjectTests(scanRoot, { runnerOverride: testRunnerOverride, timeoutMs: testTimeoutMs });
@@ -688,8 +702,8 @@ async function verifyFixWithTests({
   const allOk = legs.scan.ok && legs.lint.ok && legs.tests.ok;
   const verdict = !allOk
     ? 'verification-failed'
-    : (legs.tests.skipped ? 'untested-but-passes' : 'verified-clean');
-  return { ok: allOk, verdict, legs, summary: _summarize(legs, verdict) };
+    : pn ? 'verified-fix' : (legs.tests.skipped ? 'untested-but-passes' : 'verified-clean');
+  return withRecord({ ok: allOk, verdict, legs, summary: _summarize(legs, verdict) });
 }
 
 function _summarize(legs, verdict) {
@@ -697,6 +711,7 @@ function _summarize(legs, verdict) {
   bits.push(`scan: ${legs.scan.ok ? 'pass' : 'fail'}`);
   bits.push(`lint: ${legs.lint.skipped ? 'skip' : legs.lint.ok ? 'pass' : 'fail'}`);
   bits.push(`tests: ${legs.tests.skipped ? 'skip' : legs.tests.ok ? 'pass' : 'fail'}`);
+  if (legs.patchNegative) bits.push(`patch-negative: ${legs.patchNegative.ok ? 'pass' : `fail (${legs.patchNegative.detail.incompleteStep})`}`);
   return `${verdict} (${bits.join(' · ')})`;
 }
 
@@ -722,6 +737,7 @@ __webpack_require__.r(__webpack_exports__);
 /* harmony import */ var _fix_honesty_gate_js__WEBPACK_IMPORTED_MODULE_4__ = __webpack_require__(27785);
 /* harmony import */ var _test_runner_js__WEBPACK_IMPORTED_MODULE_5__ = __webpack_require__(35136);
 /* harmony import */ var _fix_metrics_js__WEBPACK_IMPORTED_MODULE_6__ = __webpack_require__(32238);
+/* harmony import */ var _verification_emit_js__WEBPACK_IMPORTED_MODULE_7__ = __webpack_require__(85578);
 var __webpack_async_dependencies__ = __webpack_handle_async_dependencies__([_engine_js__WEBPACK_IMPORTED_MODULE_3__]);
 _engine_js__WEBPACK_IMPORTED_MODULE_3__ = (__webpack_async_dependencies__.then ? (await __webpack_async_dependencies__)() : __webpack_async_dependencies__)[0];
 // Closed-loop /fix verification (Sentinel-parity FR-L4-4, FR-L4-5).
@@ -749,6 +765,7 @@ _engine_js__WEBPACK_IMPORTED_MODULE_3__ = (__webpack_async_dependencies__.then ?
 
 
 
+
 const SEVERITY_RANK = { critical: 0, high: 1, medium: 2, low: 3, info: 4 };
 
 // Run a focused re-scan over just the patched file(s) using the in-memory
@@ -913,6 +930,8 @@ async function verifyFix({
   testTimeoutMs,
   recordMetrics = true,
   poc,
+  patchNegative,
+  assuranceConfig,
 } = {}) {
   // R5 (reporting half) — time each stage as it runs. Measured here rather
   // than inside each stage because only this function knows the boundaries of
@@ -995,7 +1014,26 @@ async function verifyFix({
   }
   _lap('honesty');
 
-  const ok = rescan.ok && (lint.ok || lint.skipped) && testsOk && pocOk && (honesty ? honesty.ok : true);
+  // X-204: patch-negative verification, only when the caller asked for it AND the `patch-negative-verification` feature is
+  // on. `patchNegative` is the requester's exploit scenario and functional cases ({ original, functional, commit?, ... }); the
+  // candidate `files` are the proposed diff. With the flag off, or no request, nothing here runs and every field below is
+  // exactly what it was before.
+  let pn = null;
+  if (patchNegative && typeof patchNegative === 'object') {
+    try {
+      const { verifyPatchNegative } = await Promise.all(/* import() */[__webpack_require__.e(6239), __webpack_require__.e(5613)]).then(__webpack_require__.bind(__webpack_require__, 95613));
+      pn = await verifyPatchNegative({
+        hypothesisId: originalFindingStableId, ...patchNegative, patch: { files },
+        commit: patchNegative.commit ?? (0,_verification_emit_js__WEBPACK_IMPORTED_MODULE_7__.headCommit)(scanRoot),
+      }, { config: assuranceConfig });
+    } catch (e) {
+      pn = { status: 'error', verifiedFix: false, incompleteStep: 'patch-negative', failureCode: 'harness-error', reason: `patch-negative verification failed to run: ${String(e?.message || e).slice(0, 200)}`, summary: '' };
+    }
+  }
+  const pnActive = pn !== null && pn.status !== 'disabled';
+  _lap('patchNegative');
+
+  const ok = rescan.ok && (lint.ok || lint.skipped) && testsOk && pocOk && (honesty ? honesty.ok : true) && (pnActive ? pn.verifiedFix === true : true);
 
   // FR-305 (assurance-hardening PRD): `ok` alone conflates "every leg
   // genuinely ran and passed" with "passed, but a required leg was skipped
@@ -1037,6 +1075,7 @@ async function verifyFix({
       : pocLeg.status === 'no-longer-proven' ? 'poc:     PASS (ran against the patch and no longer demonstrates the vulnerability)'
       : `poc:     inconclusive — not counted either way (${pocLeg.reason || 'no detail reported'})`,
     // FR-305: never let a degraded pass read the same as a full one.
+    pnActive ? `patch-negative: ${pn.verifiedFix ? 'PASS (verified-fix)' : `FAIL - not verified-fix, incomplete step '${pn.incompleteStep}' (${pn.failureCode}): ${pn.reason}`}` : null,
     ok && !verifiedFull ? `NOTE:    PASSED, but NOT fully verified — ${degradedLegs.join('; ')}` : null,
   ].filter(Boolean).join('\n');
   // Persist the attempt so the distribution can be reported from real runs.
@@ -1063,7 +1102,19 @@ async function verifyFix({
     });
   }
 
-  return { ok, verifiedFull, degradedLegs, rescan, lint, tests, testedPrePatch: _testedPrePatch, honesty, poc: pocLeg, durations, summary };
+  // X-201: the one verification record, ADDITIVE. `ok` and every field above stay exactly as they were; the record
+  // says what was actually established (a static re-scan is not an exploit oracle, so without a PoC leg it is
+  // `not-run`, and nothing here can reach `confirmed`/`refuted`: that takes a trusted oracle adapter).
+  const emitted = (0,_verification_emit_js__WEBPACK_IMPORTED_MODULE_7__/* .emitVerification */ .T)('fix-verify', { rescan, lint, tests, poc: pocLeg }, {
+    originalFindingStableId, files, scanRoot, finding: poc?.finding,
+  });
+  const verificationRecord = emitted.ok ? emitted.record : null;
+
+  return {
+    ok, verifiedFull, degradedLegs, rescan, lint, tests, testedPrePatch: _testedPrePatch, honesty, poc: pocLeg, durations, summary, verificationRecord,
+    // additive, present only when patch-negative verification was requested (X-204)
+    ...(pn ? { patchNegative: pn, ...(pnActive ? { fixStatus: pn.verifiedFix ? 'verified-fix' : 'not-verified-fix' } : {}) } : {}),
+  };
 }
 
 __webpack_async_result__();