What problem are you trying to solve
deepsec exports as md-dir or json, but neither integrates with the standard SAST ecosystem. SARIF 2.1.0 (OASIS) is what GitHub Code Scanning, GitLab SAST reports, Sonar, DefectDojo, and most vulnerability management platforms consume natively.
Without it, every team adopting deepsec alongside an existing SAST stack has to write a custom adapter to push findings into GitHub Code Scanning's Security tab, GitLab's Vulnerability Report, etc. That's the kind of glue every adopter ends up writing.
What would you want deepsec to do
A new export format:
pnpm deepsec export --format sarif --out findings.sarif
Output: a SARIF 2.1.0 log with:
- deepsec matcher slugs mapped to SARIF rules, findings mapped to results
- severities mapped to SARIF level plus the GitHub security-severity extension
- revalidation verdicts mapped to SARIF natives where they exist (false-positive becomes
suppressions[]), and to a namespaced properties.deepsec/* bag for fields without a SARIF equivalent (triage priority, confidence, etc.)
I'd be happy to implement this. Three design questions where I have a preference but want to validate before coding:
- Custom JSON builder vs an existing lib. I'd lean custom: zero new runtime deps, smaller audit surface, the spec subset we need is small. OK?
- Rules array shape. Emit one rule per matcher slug that fired in the run, not all ~110 registered matchers. Keeps SARIF lean, stays well under GitHub's 1000-rules-per-run cap. OK?
partialFingerprints stability. Base on (projectId, filePath, vulnSlug, title), intentionally NOT including line numbers, so GitHub Code Scanning dedupes findings across PRs even when unrelated edits shift line numbers. OK?
Workaround you're using today
Parsing the json export and converting to SARIF on my side for an internal pipeline. Works, but it's the kind of glue every adopter ends up writing. Better contributed once.
What problem are you trying to solve
deepsec exports as
md-dirorjson, but neither integrates with the standard SAST ecosystem. SARIF 2.1.0 (OASIS) is what GitHub Code Scanning, GitLab SAST reports, Sonar, DefectDojo, and most vulnerability management platforms consume natively.Without it, every team adopting deepsec alongside an existing SAST stack has to write a custom adapter to push findings into GitHub Code Scanning's Security tab, GitLab's Vulnerability Report, etc. That's the kind of glue every adopter ends up writing.
What would you want deepsec to do
A new export format:
pnpm deepsec export --format sarif --out findings.sarifOutput: a SARIF 2.1.0 log with:
suppressions[]), and to a namespacedproperties.deepsec/*bag for fields without a SARIF equivalent (triage priority, confidence, etc.)I'd be happy to implement this. Three design questions where I have a preference but want to validate before coding:
partialFingerprintsstability. Base on (projectId,filePath,vulnSlug,title), intentionally NOT including line numbers, so GitHub Code Scanning dedupes findings across PRs even when unrelated edits shift line numbers. OK?Workaround you're using today
Parsing the json export and converting to SARIF on my side for an internal pipeline. Works, but it's the kind of glue every adopter ends up writing. Better contributed once.