Repository navigation
Post findings as inline PR review comments #6
Description
Problem
When Inkog runs in a GitHub Actions workflow, it posts a single summary comment on the PR with aggregate finding counts. Developers have to cross-reference finding locations manually. Inline review comments on the exact lines with vulnerabilities dramatically improve the developer experience — research shows developers prefer feedback within their existing PR workflow rather than switching to a separate Security tab or dashboard.
Current Behavior
The GitHub Action posts a summary comment like:
🔍 Inkog Security Scan Results
Found 3 findings (1 CRITICAL, 2 HIGH)
Findings are also uploaded as SARIF to the GitHub Security tab, but many developers never check it (requires navigating away from the PR).
Proposed Solution
After scanning, use the GitHub API to post a PR review with inline comments on the specific lines where findings were detected:
📍 file: agents/tools.py, line 42
🔴 CRITICAL: SQL Injection via LLM — User-controlled LLM output
interpolated directly into SQL query without parameterization.
→ Use parameterized queries: cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
Implementation approach
- Parse JSON scan output (
-output json) which already includesfileandlinefor each finding - Use
github.rest.pulls.createReview()withcomments[]array to batch all inline comments into a single review (avoids secondary rate limits from individual comment calls) - Set review event to
COMMENT(notREQUEST_CHANGES) to avoid blocking PRs - Limit inline comments to top 5 highest-severity findings to avoid noise — developers will uninstall a tool that spams 50 comments on a PR
- Only comment on lines that are part of the PR diff (findings in unchanged files go to the summary comment only)
- Add configurable threshold for severity and max comments
Expected behavior
# In workflow
- uses: inkog-io/inkog@v1
with:
inline-comments: true # Enable inline PR comments
inline-comment-severity: HIGH # Only comment on HIGH+ findings
max-inline-comments: 5 # Cap to avoid noiseReferences
- GitHub Pull Request Review API — batch comments via
createReview - GitHub secondary rate limits — why batching is required
- Semgrep inline comments — prior art
- Snyk PR decoration — prior art
Notes
- The JSON output already has all needed data (
file,line,severity,description,remediation) - Must use Review Batching (
createReviewwith comments array) — posting individual comments in a loop will hit GitHub's secondary rate limits immediately on large scans - SARIF upload should continue alongside inline comments (defense in depth)
- The action already has
GITHUB_TOKENavailable — no additional auth needed - Map findings to changed lines only using the PR diff — avoid commenting on unchanged files
Activity
cloakmaster commentedon Apr 28, 2026
This is high on our roadmap for v1.3. The current Action already posts a summary PR comment and supports SARIF upload (which populates the GitHub Security tab), but inline annotations on the exact lines where findings occur would be a significant UX improvement.
The approach would be to use the GitHub Checks API to create annotations tied to specific file/line ranges from our scan results. We're planning to implement this alongside the existing SARIF flow.
If anyone wants to take a crack at this, the main work is in
action.yml— mapping the scan result'sfile/linefields to GitHub check run annotations.