PR Review Comments

How Cygent reviews pull requests — inline comments, three-way categorization, and auto-review modes.

Overview

When Cygent reviews a pull request, it doesn't just post a summary somewhere off to the side. It reviews the diff the way a senior security engineer would: inline, at the exact line where the issue lives, with context that a human reviewer would want before they merge.

This page covers what those comments look like, how the three-way categorization works, the auto-review modes, and a worked example of a real PR that Cygent caught as Critical.

Three-way categorization

Cygent doesn't just ask "what's wrong with this diff?" It asks a richer question: "how does this PR change the security posture of the codebase?" The answer splits into three buckets.

That three-way split is the heart of what a PR review should answer: did this PR make things better, worse, or sideways? A tool that only shows "New" misses the payoff of fixes. A tool that shows all findings makes you read through pre-existing noise every time.

What an inline comment looks like

Each inline comment Cygent posts on a GitHub PR includes:

Paraphrased example on a Solidity PR:

Critical: Missing access control on addSupportedToken

The addSupportedToken function has external visibility but no access control modifier. Any address can register arbitrary tokens with arbitrary price feeds.

Root cause: token registration is a privileged administrative action that directly controls which assets the protocol accepts as collateral. Without access control, an attacker can register a malicious token with an attacker-controlled price feed, deposit a trivial amount, and borrow against it at any price.

Recommendation: add the onlyOwner modifier (or the equivalent from your access-control library):

function addSupportedToken(address token, address priceFeed) external onlyOwner {

The comment is anchored to the specific line in the diff. Whoever opens the PR sees it inline in their normal GitHub review flow.

Example — The unrestricted addSupportedToken PR

This is the canonical demo case — a real pattern from the Cygent walkthrough, and the kind of mistake that ends protocols.

The PR: a developer on the GhostLend team opens a PR to add support for additional tokens as collateral. The core addition is:

/// @notice Register a new token for use as collateral.
function addSupportedToken(address token, address priceFeed) external {
    supportedTokens[token] = priceFeed;
    emit TokenAdded(token, priceFeed);
}

What a human might miss: the function looks clean. Good natspec. Clear intent. It compiles. A tired reviewer on a Friday afternoon would approve it.

What Cygent catches: the function is external and has no access control. Anyone on mainnet can call it with any token address and any price feed. The attack is trivial:

1. Deploy a worthless ERC20 and a price feed that returns $1M per token.
2. Call addSupportedToken(myFakeToken, myFakePriceFeed).
3. Deposit 1 wei of the fake token as collateral (valued at effectively zero gas).
4. Borrow the entire protocol's USDC/WETH liquidity against the fake "$1M" collateral.

This is the full drain of a lending protocol, and the only thing standing between that PR and mainnet is the onlyOwner modifier that the developer forgot to add.

Cygent's comment: Critical. Inline on the function. Recommendation is a one-word addition. The fix fits in a single keystroke. The cost of the catch is seconds; the cost of missing it is the protocol.

Auto-review modes

How aggressively Cygent reviews PRs is configurable.

Configure at the agent level in Automation → Behavior, or override per-project. See Behavior & Autonomy for the trade-offs.

Manual triggers

Regardless of auto-review mode, you can trigger a review on any PR manually:

Manual triggers are useful for re-reviewing a PR after substantial changes, for reviewing PRs opened before Cygent was installed, and for cases where auto-review failed silently.

Cross-posting to chat

Every PR review also produces a summary that gets posted to your default review channel. The summary includes:

• PR number, title, author.
• The three-way finding breakdown: X new, Y still present, Z resolved.
• Severity counts.
• A link back to the PR.

So even if you're not watching GitHub notifications, you see review outcomes land in Slack the moment they complete. This is the signal most teams optimize around — it's how a security engineer knows "something just opened that needs attention."

Per-project overrides on the review channel let you route reviews from different repos to different chat destinations.

The /cygent commit comment

A rarely-remembered-but-useful trigger: you can comment /cygent on a commit (not just on the PR itself) to get Cygent to review the changes in that specific commit. Useful for reviewing a single commit in a long PR history without re-reviewing the whole diff.

What's in it for the author

If you're the PR author: you get inline feedback at review time rather than in a follow-up issue two days later. The feedback is anchored to your specific lines, has a severity, and has a concrete recommendation. The loop is tight enough that you can fix the issue, push a new commit, and get a re-review in the same working session.

Related