xploitscan 1.3.0 → 1.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -0
- package/dist/{api-AX6R4QAD.js → api-6FD27EJY.js} +2 -2
- package/dist/{chunk-LWX7UPO5.js → chunk-2VDAYFPC.js} +12 -1
- package/dist/{chunk-LWX7UPO5.js.map → chunk-2VDAYFPC.js.map} +1 -1
- package/dist/index.js +94 -36
- package/dist/index.js.map +1 -1
- package/package.json +2 -2
- /package/dist/{api-AX6R4QAD.js.map → api-6FD27EJY.js.map} +0 -0
package/README.md
CHANGED
|
@@ -155,6 +155,14 @@ legacy/** scanner
|
|
|
155
155
|
For a single reviewed-and-accepted finding, prefer an inline
|
|
156
156
|
`// VC<id>-OK: <reason>` comment instead of a file- or path-wide rule.
|
|
157
157
|
|
|
158
|
+
**Where it is looked up.** Every `.xploitscanignore` between your project root
|
|
159
|
+
and the directory being scanned applies, so `xploitscan scan packages/web/src`
|
|
160
|
+
still honours the file at the top of the repo. Patterns are interpreted
|
|
161
|
+
relative to the file that declares them — a root file naming
|
|
162
|
+
`packages/web/src/lib/demo.ts` matches that file whether you scan the repo root
|
|
163
|
+
or `packages/web/src` — and a nested file takes precedence over a broader rule
|
|
164
|
+
above it, the same way `.gitignore` does.
|
|
165
|
+
|
|
158
166
|
### Vendored and generated code
|
|
159
167
|
|
|
160
168
|
Some of what a scanner finds isn't code you wrote. AI app builders copy
|
|
@@ -14,7 +14,7 @@ import {
|
|
|
14
14
|
storeToken,
|
|
15
15
|
syncUser,
|
|
16
16
|
uploadScanResults
|
|
17
|
-
} from "./chunk-
|
|
17
|
+
} from "./chunk-2VDAYFPC.js";
|
|
18
18
|
export {
|
|
19
19
|
checkUsage,
|
|
20
20
|
clearProRulesCache,
|
|
@@ -29,4 +29,4 @@ export {
|
|
|
29
29
|
syncUser,
|
|
30
30
|
uploadScanResults
|
|
31
31
|
};
|
|
32
|
-
//# sourceMappingURL=api-
|
|
32
|
+
//# sourceMappingURL=api-6FD27EJY.js.map
|
|
@@ -45942,6 +45942,17 @@ async function filterFalsePositives(findings, fileContents) {
|
|
|
45942
45942
|
{
|
|
45943
45943
|
model: "claude-haiku-4-5-20251001",
|
|
45944
45944
|
max_tokens: 1024,
|
|
45945
|
+
// Pinned, NOT left to the API default of 1.0. This is a binary
|
|
45946
|
+
// classification (real vs. false positive), not generation — there
|
|
45947
|
+
// is no upside to sampling variety and a real downside to it: a
|
|
45948
|
+
// filtered finding is a finding the user never sees, so drift here
|
|
45949
|
+
// means scanning the same unchanged code twice can yield different
|
|
45950
|
+
// results. Temperature 0 does not make the model bit-deterministic
|
|
45951
|
+
// (Anthropic makes no such guarantee), but it removes the one
|
|
45952
|
+
// variance source that was ours to control. See
|
|
45953
|
+
// scripts/fp-filter-repeatability.cjs for the measured flip rate,
|
|
45954
|
+
// and the assertion in ai-fp-filter.test.ts that keeps it pinned.
|
|
45955
|
+
temperature: 0,
|
|
45945
45956
|
system: REVIEW_SYSTEM_PROMPT,
|
|
45946
45957
|
messages: [{ role: "user", content: prompt }]
|
|
45947
45958
|
},
|
|
@@ -46420,4 +46431,4 @@ export {
|
|
|
46420
46431
|
loadCachedProRules,
|
|
46421
46432
|
clearProRulesCache
|
|
46422
46433
|
};
|
|
46423
|
-
//# sourceMappingURL=chunk-
|
|
46434
|
+
//# sourceMappingURL=chunk-2VDAYFPC.js.map
|