Pull Request Workflow

The pull request is where security review actually happens. If a finding doesn't show up where engineers are already working, it doesn't get fixed.

Trace integrates with GitHub at every layer of the PR experience: a check run, inline review comments on the changed lines, and a SARIF upload that feeds GitHub's native Security tab and code scanning alerts.

What developers see

For every pull request, Trace runs all three engines against the diff and posts results into the PR in three forms:

Trace Security Scan check. A GitHub status check that appears next to your CI checks. Reports success, failure, or pending while the scan runs. The "Details" link drops the developer into the Trace dashboard view for that PR, so they can see findings in context.

Inline review comments. New findings that touch lines in the diff post as inline GitHub review comments. The developer sees them in the file view, exactly where they'd see a reviewer's comment. Each comment includes the finding's severity, type, attack vector, and remediation.

GitHub Code Scanning (SARIF). Trace uploads a SARIF report to GitHub's code scanning API after every PR scan. Findings appear in the Security tab, integrate with branch protection rules, and roll up into GitHub's security overview for your organization.

Comment lifecycle

Inline review comments aren't just appended every scan — they reconcile against the previous scan's comments:

• New findings post fresh comments.
• Fixed findings automatically resolve the comment thread. Developers don't see stale comments for issues they've already addressed.
• Persisting findings stay open across pushes to the PR. We don't re-comment on every push.

This is what makes inline feedback feel like a real reviewer instead of a CI bot. The volume stays manageable and the comments stay accurate.

If a finding is wrong for your context, developers can mark it as a false positive directly from the PR review comment — Trace generates a smart suppression rule for your organization so the same pattern doesn't surface again on future scans. See Marking false positives for details.

Blocking policy

By default, Trace's check run is informative, not blocking. The check posts the scan result and surfaces findings as review comments, but doesn't fail the PR. Developers see the findings in their normal review flow and decide what to do.

You can switch to blocking mode at any time. In blocking mode, the check fails on findings at or above a severity threshold you choose — typically CRITICAL and HIGH. With branch protection rules in place, the PR can't merge until the findings are resolved or explicitly waived.

We recommend the following onboarding path:

1. Start informative. During the first few days of automated scanning, you'll be tuning thresholds and suppressing patterns that don't apply to your code. An informative check run lets your team see what Trace finds without blocking real work.
2. Move to blocking on CRITICAL once you trust the output. Critical-severity findings on your default branch are almost always real and almost always urgent. Blocking them costs nothing and prevents real exposures.
3. Expand to HIGH once your baseline is clean. Once you've worked through the existing high-severity findings, blocking new ones from being introduced is the natural next step.

Blocking policy can be configured per organization from your dashboard settings.

SARIF and GitHub Code Scanning

Trace's SARIF upload makes findings appear in GitHub's native Security tab and code scanning alerts. This unlocks:

• GitHub branch protection rules that gate merges on the presence of code scanning alerts.
• The Security overview dashboard at the organization level — useful for security leadership tracking exposure across many repos.
• GitHub's built-in alert lifecycle for dismissal, false positive tracking, and resolution.

We map severity to SARIF levels as follows: CRITICAL and HIGH → error, MEDIUM → warning, LOW → note. Severity rolls forward into the alert's display severity in GitHub's UI.

If a SARIF payload approaches GitHub's size limit, low-severity findings are dropped first to ensure high-severity findings always make it through. Upload is retried with exponential backoff on transient failures.

Manual reruns

If you've pushed a fix and want to confirm a finding clears before requesting review, you can trigger a rescan on demand from the dashboard. The Retest action on a vulnerability fires a targeted re-scan against that specific issue and updates its status when complete.

What a PR scan covers

Trace's engines run against the changed lines in the PR. The check run result and SARIF upload also reflect any previously-detected open vulnerabilities on the default branch — so the status represents the full security state of the branch you're merging into, not just the delta. Inline review comments still only cover lines that the PR actually touches.