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.

Your CI pipeline probably runs a few security scanners already — Trivy, Semgrep, Bandit, gitleaks, the GitHub CodeQL action. Each of them produces a SARIF report. Each of those reports lives in its own GitHub Code Scanning view, far from the PR review where humans are actually reading. Sigilix’s SARIF evidence channel (ARC-188) bridges the gap. Upload a SARIF v2.1.0 report as a PR artifact and Sigilix pulls it in, parses it, and injects the high-severity findings into the synthesizer as authoritative evidence.

​
What you need to do

Three things, all in your CI workflow:

​
1. Produce a SARIF v2.1.0 report

Most scanners support --format sarif natively. Examples: 
# .github/workflows/security.yml — Trivy example
- name: Run Trivy
  uses: aquasecurity/trivy-action@v0.20.0
  with:
    scan-type: 'fs'
    format: 'sarif'
    output: 'trivy-results.sarif'

# Semgrep example
- name: Run Semgrep
  run: semgrep --config=auto --sarif > semgrep-results.sarif

​
2. Upload the report as a PR artifact

- name: Upload SARIF
  uses: actions/upload-artifact@v4
  with:
    name: sarif-results
    path: '*.sarif'
The artifact name doesn’t matter to Sigilix; it scans all PR artifacts ending in .sarif.

​
3. That’s it

The next review fires after the CI run completes. Sigilix lists the PR’s artifacts via the GitHub Actions API, downloads any SARIF blobs, parses them, and routes their findings into the synthesizer.

​
Supported scanners

Sigilix is tested against:
ScannerStatus
Trivyfirst-class — fields parsed including image-layer attribution
Semgrepfirst-class
gitleaksfirst-class
GitHub CodeQLfirst-class
Bandit (Python)parsed via generic SARIF v2.1.0
ESLint with --format sarifparsed via generic SARIF v2.1.0
Anything else with SARIF v2.1.0 outputparsed via generic SARIF v2.1.0
Anything outside SARIF v2.1.0 isn’t supported. SARIF v2.0 (the predecessor) is rare and not handled; the difference shows up as a “no findings” outcome.

​
Severity mapping

SARIF reports each finding with a level and a rank. Sigilix maps:
SARIF levelRankSigilix severity
erroranycritical
warning≥ 70critical
warning< 70warning
noteanyinfo
noneanysuppressed
Critical-severity SARIF findings set the verdict to Request changes, same as any other critical finding.

​
What “authoritative evidence” means

Findings that come in via SARIF aren’t subject to the LLM specialist’s cross-reference check. They’re treated as ground truth — your scanner ran, your scanner said there was an issue, Sigilix posts it. The synthesizer does still:
  • Deduplicate against overlapping LLM findings (an LLM-flagged SQL injection at the same line as a Semgrep-flagged SQL injection becomes one finding).
  • Provide a unified rendering (the inline comment has the same shape as native Sigilix findings).
  • Set verdict + comment counts based on the merged set.
But it does not down-grade SARIF findings the way it can down-grade an LLM finding whose structural provenance is weak.

​
What it looks like in the review

A finding sourced from SARIF carries a small badge: 
[Trivy via SARIF] Critical: CVE-2025-12345 in libssl 3.0.7
Dockerfile:14 — base image alpine:3.18 ships libssl 3.0.7.
Patched in 3.0.8. Bump the base image or pin libssl explicitly.
The bracketed source (Trivy via SARIF) tells the reader the finding came from external evidence, not from one of Sigilix’s own specialists.

​
Adversarial inputs

SARIF is just JSON, and a malicious or buggy scanner could produce a SARIF report with thousands of findings or with garbage data. Sigilix defends against this:
ThreatMitigation
Huge SARIF (10K+ findings)Capped at 100 findings per report; rest summarized in a footnote
Findings on lines that don’t exist in the diffDropped silently (same as LLM findings that fail the line-validity check)
Findings on files outside the repoDropped silently
Path-traversal in SARIF uri fieldsSanitized before render
Embedded HTML/Markdown in finding textEscaped before render
The 100-finding cap is the most user-visible limit. If your scanner regularly produces more, narrow its config — SARIF reports with thousands of findings are noise, not signal.

​
Disabling

{
  "sarif": { "enabled": false }
}
The channel is on by default. Disable if:
  • You don’t produce SARIF artifacts in CI (the channel is a no-op anyway, but disabling silences any future warning if you do start producing them).
  • You produce SARIF but want it surfaced only in GitHub Code Scanning, not in Sigilix reviews.

Review Provenance

Provenance tracking + stale-marker detection for the whole review.

Dependency Vulnerabilities

Sigilix’s built-in npm vulnerability scan.