You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 82fe822
Browse filesBrowse the repository at this point in the historyBrowse files
static-analysis: Scan files over 1 MB, and report the ones still skipped (#343)
semgrep skips any file larger than --max-target-bytes and reports nothing about
it: no paths.skipped entry, no error, and the file simply absent from
paths.scanned. run-scans.sh never set the flag, so semgrep's 1,000,000-byte
default applied and a scan that never opened a file recorded `findings: 0` next
to a plausible filesScanned count.
Reproduced on semgrep 1.178.0 against a 1,050,060-byte bundle carrying a
document.write(location.hash) sink, beside a 36-byte sibling so the scan opened
something and coveredNothing stayed empty:
before findings 0, filesScanned 1, coveredNothing []
after findings 1, filesScanned 2, maxTargetBytes 20000000
The limit is now explicit at 20,000,000 bytes and settable with
--max-target-bytes N, where 0 means no limit as it does in semgrep. Bytes only:
the oversized report below compares the limit against a file size, and semgrep's
'1.5MB' spelling would have to be parsed a second way that could disagree.
A higher default moves the cliff rather than removing it, so the files still
over it are named as `oversized` in scans.json, scoped to the --include globs a
scan actually passed. The report phase of the workflow and the report template
carry it for the reason they carry coveredNothing: a gap only stderr knows about
is a gap the report calls coverage. Cross-language rulesets take no --include and
semgrep decides for itself what it can parse, so their share is not enumerable
here; references/scan-modes.md says so and maxTargetBytes is in the report.
Eleven assertions added to tests/run_scan_tests.sh (104 in total), and one to
the workflow harness with the mutation that proves it load-bearing.
Refs #298
Signed-off-by: Udaya Tejas <[email protected]>
Co-authored-by: kz-tob <[email protected]>
Copy file name to clipboardExpand all lines: plugins/static-analysis/skills/semgrep/workflows/scan-workflow.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -323,6 +323,8 @@ and the severity flags are all its job, not yours. It writes `$OUTPUT_DIR/scans.
323
323
|`unscoped`| Languages with no `--include` globs, which ran against every file |
324
324
|`alsoShared`| Rulesets dropped from a language because the same ruleset is already running unscoped over the whole target. Coverage is unaffected; report them so a per-ruleset accounting adds up |
325
325
|`excludePattern`| Set when the output directory sits inside the target: the pattern passed as `--exclude` to every scan, or `""`. semgrep matches it anywhere in the tree, so `out` also drops `src/out/`. **Must be shown when non-empty.**|
326
+
|`maxTargetBytes`| The `--max-target-bytes` every scan ran with. semgrep opens no file larger than this |
327
+
|`oversized`| Files an `--include` glob selected that are larger than `maxTargetBytes`. semgrep skipped them with no `paths.skipped` entry and no error, so they report 0 findings exactly like a file that was opened and found clean. A scan that did not open a file has not cleared it. **Must be shown.**|
326
328
|`reposPath`| The clone directory Step 5 deletes |
327
329
328
330
**A non-zero exit means no scan succeeded.** The script exits 1 when `scans` is empty, so a run
@@ -439,6 +441,12 @@ one finding flagged by two rulesets is one row in the merge and two in that sum]
439
441
looked at anything. Check the plan against the languages Step 1 detected: this is what a
440
442
ruleset for a language the target does not contain looks like
441
443
444
+
### Too Large To Scan:
445
+
[omit when oversized is empty]
446
+
- <path> — larger than maxTargetBytes, so semgrep never opened it and no ruleset covered it.
447
+
Not a clean result: re-run with a higher --max-target-bytes, or say in the report that the
448
+
file was left unscanned
449
+
442
450
### Missing From The Merge:
443
451
[omit when the merge printed no "unparseable:" line]
444
452
- <file> — the scan succeeded and is counted in scans.json, but its SARIF could not be parsed,
0 commit comments