@clear-capabilities/agentic-security-scanner 0.144.0 → 0.145.0

package/dist/970.index.js

@@ -11,6 +11,7 @@ export const modules = {
 /* harmony export */   evaluateAssuranceMode: () => (/* binding */ evaluateAssuranceMode)
 /* harmony export */ });
 /* unused harmony export _internals */
+/* harmony import */ var _posture_provenance_schema_js__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(4594);
 // Assurance modes (assurance-hardening PRD FR-204).
 //
 // "Add assurance modes: advisory, standard, and strict | Strict mode fails
@@ -55,6 +56,8 @@ export const modules = {
 // mode to behave differently from advisory, that is a deliberate, separate
 // decision -- not something to guess at here.
 
+
+
 const ASSURANCE_MODES = Object.freeze(['advisory', 'standard', 'strict']);
 const DEFAULT_ASSURANCE_MODE = 'standard';
 
@@ -69,7 +72,7 @@ function _isValidMode(mode) {
  *   ok:false only ever happens in strict mode; advisory/standard always ok:true
  *   (they report, they do not gate).
  */
-function evaluateAssuranceMode(mode, scanHealth) {
+function evaluateAssuranceMode(mode, scanHealth, findings = []) {
   const effectiveMode = _isValidMode(mode) ? mode : DEFAULT_ASSURANCE_MODE;
   const conditions = Array.isArray(scanHealth?.conditions) ? scanHealth.conditions : [];
 
@@ -98,6 +101,67 @@ function evaluateAssuranceMode(mode, scanHealth) {
       conditions,
     };
   }
+
+  // M2 §2.5: strict cares about overall scan completeness, which now
+  // explicitly includes PROVENANCE completeness, not just detector/analyzer
+  // completeness. A finding whose findingProvenance status is outside
+  // ['complete','uncommitted'] — including a finding with NO
+  // findingProvenance at all, e.g. --no-provenance was used — means strict
+  // cannot vouch for this scan's provenance the same way it already refuses
+  // to vouch for a scan with a failed analyzer.
+  //
+  // KNOWN INTERACTION: scan.secrets/scan.logicVulns are unconditionally
+  // stamped not_available today (M0+M1 deliberately deferred real origin
+  // resolution for those two channels — see the M2/M3/M4 design spec's
+  // §2.6). Any real secret or logic finding therefore fails strict mode
+  // until that resolution work lands. This is the literal, intended
+  // consequence of "never false certainty" applied to strict's own
+  // definition, not an oversight — a strict-mode operator with secrets
+  // findings should expect this until M3+ closes that gap.
+  //
+  // This list is INCOMPLETE without scan.supplyChain, and the omission
+  // matters more than the secrets/logic one above because it hits nearly
+  // every real project. engine.js stamps every supplyChain entry
+  // not_available too (see the loop over `supplyChain` right after the
+  // `annotateGitProvenance` calls), and that bucket covers three distinct
+  // populations, not one:
+  //
+  //  - transitive `vulnerable_dep` findings: a genuine, if currently
+  //    unresolved, DEFERRAL — same shape as secrets/logicVulns above. The
+  //    vulnerable version was never declared in this repo's own manifests,
+  //    so there is no local commit to walk yet, but one could exist to
+  //    resolve in a later phase.
+  //  - `unpinned_dep` / `no_lockfile` findings: a CATEGORY ERROR, not a
+  //    deferral. These describe an ABSENT state (a version range with no
+  //    pin, a manifest with no lockfile) — there is no "commit that
+  //    introduced a missing lockfile" for any future resolver to find,
+  //    because the finding is about the absence of an event, not an event
+  //    itself. No amount of future engineering work makes these resolvable.
+  //
+  // Direct `vulnerable_dep` findings DO go through real origin resolution
+  // (`resolveDirectSCAOrigin`, gated on `isDirect`) and are not part of this
+  // limitation.
+  //
+  // Net effect: because `unpinned_dep`/`no_lockfile` findings are a category
+  // error rather than a deferral, `--assurance strict` will fail on nearly
+  // any real project that has a `package.json` (or equivalent manifest)
+  // today — an unpinned or unlocked dependency is common, and this check has
+  // no way to ever resolve one. This is a known, disclosed limitation of the
+  // current implementation, not a bug, and it is not something this check
+  // should route around: exempting these finding types from the strict-mode
+  // gate was considered and deliberately deferred to a future milestone
+  // rather than done here, so strict mode keeps refusing to vouch for
+  // provenance it cannot actually speak to.
+  const badProvenance = (Array.isArray(findings) ? findings : []).filter((f) => !(0,_posture_provenance_schema_js__WEBPACK_IMPORTED_MODULE_0__/* .isProvenanceHealthy */ .lL)(f?.findingProvenance));
+  if (badProvenance.length > 0) {
+    return {
+      ok: false,
+      mode: 'strict',
+      reason: `strict mode requires complete finding provenance; ${badProvenance.length} finding(s) have status outside [complete, uncommitted]`,
+      conditions,
+    };
+  }
+
   return { ok: true, mode: 'strict', reason: null, conditions };
 }