feat(diagnostics): gitleaks builtin #315
Conversation
Add support for gitleaks SAST tool for detecting hardcoded secrets like passwords, API keys, and tokens in git repos.
WalkthroughA new Gitleaks diagnostic builtin is introduced for null-ls, enabling detection of secrets and sensitive data in code. The implementation parses Gitleaks JSON output and converts findings into LSP-compatible diagnostics, integrated through a stdin-based workflow with on_output callback processing. Changes
Sequence DiagramsequenceDiagram
participant Client as Null-ls Client
participant NullLS as Null-ls Builtin
participant Gitleaks as Gitleaks Tool
participant Parser as Output Parser
participant LSP as LSP Pipeline
Client->>NullLS: Trigger diagnostic
NullLS->>Gitleaks: Invoke with stdin<br/>(--report-format json)
Gitleaks->>Gitleaks: Scan for secrets
Gitleaks-->>NullLS: JSON findings output
NullLS->>Parser: on_output callback<br/>(JSON string)
Parser->>Parser: Parse JSON array<br/>Map fields to diagnostics
Parser-->>LSP: Diagnostic entries<br/>(row, col, message, code)
LSP-->>Client: Display diagnostics
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
lua/null-ls/builtins/diagnostics/gitleaks.lua (1)
6-30: Consider removing the redundantruleIdfield.The
ruleIdfield on line 20 is set but never used by the parser. The parser configuration at line 9 only extracts thecodeattribute. You can simplify by removing line 20.🔎 Proposed simplification
local offenses = {} for _, finding in ipairs(params.output or {}) do table.insert(offenses, { message = finding.Description, - ruleId = finding.RuleID, code = finding.RuleID, line = finding.StartLine, column = finding.StartColumn, endLine = finding.EndLine, endColumn = finding.EndColumn, }) end
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
lua/null-ls/builtins/diagnostics/gitleaks.luatest/spec/builtins/diagnostics/gitleaks_spec.lua
🧰 Additional context used
🪛 Gitleaks (8.30.0)
test/spec/builtins/diagnostics/gitleaks_spec.lua
[high] 16-16: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 17-17: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (3)
lua/null-ls/builtins/diagnostics/gitleaks.lua (2)
1-4: LGTM!Clean imports and setup of the diagnostics method constant.
56-58: LGTM!The exit code handling correctly pairs with the
--exit-code 0argument to ensure gitleaks always exits successfully, preventing null-ls from treating secret findings as command failures.test/spec/builtins/diagnostics/gitleaks_spec.lua (1)
1-107: Excellent test coverage!The test suite thoroughly validates the parser:
- Single and multiple findings
- Correct field mapping (location, message, code, source)
- Edge cases (empty and nil output)
Note: The static analysis warnings on lines 16-17 are false positives—these are test fixtures with fake secrets, not actual sensitive data.
| args = { | ||
| "stdin", | ||
| "--report-format", | ||
| "json", | ||
| "--report-path", | ||
| "-", | ||
| "--exit-code", | ||
| "0", | ||
| "--no-banner", | ||
| }, | ||
| format = "json", | ||
| to_stdin = true, | ||
| from_stderr = true, | ||
| ignore_stderr = true, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Test where gitleaks outputs JSON report with stdin command
# First check if gitleaks is available
if ! command -v gitleaks &> /dev/null; then
echo "gitleaks not found in PATH"
exit 1
fi
# Get gitleaks version
echo "=== Gitleaks version ==="
gitleaks version
# Create a test file with a fake secret
echo 'api_key = "abc123def456"' > /tmp/test_secret.txt
echo -e "\n=== Testing stdout output ==="
cat /tmp/test_secret.txt | gitleaks stdin --report-format json --report-path - --exit-code 0 --no-banner 2>/dev/null | head -c 200
echo -e "\n\n=== Testing stderr output ==="
cat /tmp/test_secret.txt | gitleaks stdin --report-format json --report-path - --exit-code 0 --no-banner 2>&1 >/dev/null | head -c 200
echo -e "\n\n=== Testing both streams combined ==="
cat /tmp/test_secret.txt | gitleaks stdin --report-format json --report-path - --exit-code 0 --no-banner 2>&1 | head -c 200
# Cleanup
rm /tmp/test_secret.txtRepository: nvimtools/none-ls.nvim
Length of output: 678
Fix output stream configuration: from_stderr should be false.
The JSON report is output to stdout, not stderr. Gitleaks outputs only info/warning logs to stderr (e.g., "12:27PM INF scanned ~25 bytes"). With from_stderr = true, null-ls will attempt to parse stderr log messages as JSON, which will fail and prevent diagnostics from being generated.
Change line 54 to from_stderr = false to read the JSON report from stdout.
🤖 Prompt for AI Agents
In lua/null-ls/builtins/diagnostics/gitleaks.lua around lines 42 to 55, the
configuration incorrectly sets from_stderr = true so null-ls tries to parse
gitleaks' stderr logs as JSON; change from_stderr to false so the JSON report
(emitted on stdout) is read correctly (i.e., set from_stderr = false and keep
to_stdin/format as-is).
1 participant
What does this PR do?
Add a new diagnostic builtin - gitleaks
Checklist
understand it should be contributed to
nvimtools/none-ls-extras.nvim
instead
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.