Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilix.ai/llms.txt

Use this file to discover all available pages before exploring further.

When a PR adds or bumps a dependency, the question “does this version have a known CVE?” should be answered in the review, not in a separate Dependabot alert that lands two days later. Sigilix’s dependency vulnerability scan (ARC-186) does that scan inline.

​
What it scans

ManifestScanned
package.jsonyes
package-lock.jsonyes
pnpm-lock.yamlyes
yarn.lockyes
Cargo.toml / Cargo.locknot yet
go.mod / go.sumnot yet
pyproject.toml / requirements.txtnot yet
The scanner currently ships npm-only. Other ecosystems are tracked in the backlog. When a non-npm manifest changes in a PR, the scanner is a no-op — no warnings, no false alarms.

​
How the scan works

On every review where an npm manifest changed:
  1. Parse the changed lockfile (the lockfile is the source of truth — package.json ranges aren’t enough; you need the resolved versions).
  2. Diff against the previous lockfile state to identify added and bumped packages. Removed packages are skipped.
  3. Match each added/bumped (package, version) against the bundled vulnerability database.
  4. Render the matches as inline findings on the lockfile, tagged by severity.
The database is bundled into the Sigilix Worker — there are no external API calls during a review. Updates ship with each Sigilix release.

​
Range-aware matching

The scanner respects the CVE’s affected-version range. If a CVE is documented as affecting <1.2.3, only packages resolving to < 1.2.3 are flagged. A range like >=4.5.0 <4.5.6 is matched correctly — neither overflow nor under-match. This matters because the alternative (substring match on the version) produces dozens of false positives per scan. Range-aware matching is what makes the channel usable.

​
Transitive-aware

Most vulnerabilities are introduced transitively. You add popular-framework → it pulls tiny-prototype-pollution-lib two layers deep → that’s the vulnerable thing. The scanner walks the resolved dependency tree from the lockfile, not just the top-level dependencies block. Transitive matches are flagged with the resolution chain shown: 
[Warden] Critical: prototype-pollution in lodash <4.17.21
package-lock.json — added via your-app > popular-framework > old-lodash

Fix: bump popular-framework to ≥3.2.0 (resolves lodash 4.17.21 transitively),
or add a manual override to package.json.

​
Severity mapping

CVEs come from the database with a CVSS score. Sigilix maps:
CVSSSigilix severity
9.0–10.0 (Critical)critical — sets verdict to Request changes
7.0–8.9 (High)warning
4.0–6.9 (Medium)info
0.1–3.9 (Low)suppressed (logged in telemetry, not posted)
The Low suppression is intentional — low-severity CVEs in transitive deps are mostly noise. If you want them surfaced, raise the issue with support; we keep the threshold tunable in case repos want different behavior.

​
False positives

The two main false-positive sources:
  1. Version-pin override that fixes the CVE upstream. If your package.json has "resolutions" or "overrides" blocks that force a patched version, the scanner reads the resolved version, not the manifest range — false positives here are rare and indicate the resolution didn’t actually take effect.
  2. CVE database lag. A newly-published CVE may not be in the bundled DB. The scanner can’t flag what it doesn’t know about. Cross-reference with the GitHub advisory database for sensitive PRs.
If you find a false positive, reply to the finding’s thread; the feedback signal feeds review memory.

​
Interaction with Dependabot / Snyk

Sigilix’s scan and Dependabot/Snyk overlap. The right way to think about them:
  • Dependabot / Snyk scan your default branch and open issues / PRs over time.
  • Sigilix scans the PR’s resolved tree at the moment of review and posts inline at the lockfile diff.
Both are useful. Sigilix’s value-add is timing — the CVE shows up in the review you’re already reading, not in a separate alert backlog. If you find the overlap noisy, disable Sigilix’s scan: { "depVulns": { "enabled": false } }. Dependabot keeps running and you’ll still get its alerts.

​
Disabling

{
  "depVulns": { "enabled": false }
}
With this set, Sigilix skips the scan entirely. The LLM specialists still review the rest of the PR.

SARIF Evidence

Push your own scanner output into Sigilix reviews.

Secret Scanning

The companion pre-LLM scanner for credentials.