Skip to content
Nemesis
Request an engagement

Code monitoring

A security review on every pull request

Connect your repositories and every commit gets rule-based checks in seconds. An AI review reads pull requests and follows each change through the rest of your codebase. Findings land on the pull request, each with a suggested fix. Only issues the change introduces can hold it, under a policy you set.

Request an engagementSee a sample finding

Included in the annual subscription

Coverage at a glance

  • Every commit Rule-based checks, back in seconds
  • On pull requests An AI review that follows the change across your codebase
  • New issues only Existing debt never blocks a pull request
  • Never stored Your source code is checked, then the workspace is destroyed

What we check

Your code, what it depends on and how it ships

Four kinds of rule-based check run on every commit. Each result says where the issue is, how serious it is and how to fix it.

  • Code weaknesses

    Weaknesses in the code itself, flagged at the line.

    Rule-based checks read every commit for known kinds of weakness, such as user input that reaches a query, a file path or a command. Each result points to the file and line and says what to change.

  • Dependencies

    Known issues, tampered packages and licenses, direct and indirect.

    We check direct and indirect dependencies for known issues and name the upgrade that fixes each one. Malicious or tampered packages are flagged, and license checks and a software bill of materials come with it.

  • Committed secrets

    Keys and passwords in your repository, including its history.

    We find secrets committed to your repositories, in the current code and in its history, and flag the ones that are still active. Values are masked wherever we show them.

  • Infrastructure and containers

    The configuration that ships with your code, checked with it.

    Infrastructure definitions and container configuration are checked for risky settings, such as storage open to the internet or a container running as root. Each result names the setting and suggests a safer one.

Two reviewers

Rules for speed, AI review for judgment

Rule-based checks and the AI review find different things. Each runs when it is most useful, and their results arrive as one check.

  • Rule-based checks

    On every commit, back in seconds.

    Every commit is checked against rules for code weaknesses, dependencies, secrets and configuration. Results come back in seconds, while the change is still fresh.

    Why it matters

    A rule-based finding can block a merge when your policy says so.

  • AI review

    On pull requests, up to your plan’s monthly allowance.

    The AI review reads what a pull request changes, then follows it through the rest of your codebase. It catches what rules cannot: access-control mistakes, business-logic flaws, insecure design, sign-in and session mistakes, and user input reaching a dangerous operation across files.

    Why it matters

    A finding raised only by the AI review warns or holds. It blocks only when it is high-confidence or a rule-based check confirms it, so an uncertain call cannot block a merge by itself.

How it works

From a commit to a fix your team merges

Code monitoring runs on every commit and pull request for as long as your subscription does. Your part is to connect your repositories and set the policy.

  1. 01Connect

    You connect your repositories

    Install our app on GitHub and choose the repositories to cover. It can read code, post checks and comments on pull requests, and open pull requests with suggested fixes. It never merges anything.

  2. 02Check

    Every change is checked

    Rule-based checks run on each commit in seconds, and the AI review reads your pull requests. Scheduled re-checks catch dependencies that become risky after the code shipped.

  3. 03Decide

    Your policy decides what happens

    For each severity you choose: warn, hold or block. A hold waits for a named person to sign off, and the waiver records who, why and when it expires.

  4. 04Fix

    Your team merges the fix

    Every finding carries a suggested fix, and fixable ones arrive as a ready pull request. A developer reviews and merges it. Nothing is merged automatically.

Anatomy of a finding

Everything a developer
needs to fix it

A code finding is more than a line number. It says where the issue is, what it allows, whether it has been proven, what your policy does with it and how to close it.

What each part tells you

  1. Where it is. The repository, file and line, shown on the pull request where the change was made.

  2. What raised it. A rule-based check, the AI review, or both when they agree.

  3. Severity and impact. How serious it is and what it allows, in plain words.

  4. Proof status. Whether it is flagged, or proven on your running application by the engagement.

  5. Policy outcome. Whether it warns, holds or blocks the pull request, and who signed off if it was waived.

  6. Suggested fix. How to fix it, as a ready pull request when one can be prepared.

Sample findingExample Corp

Account lookup does not check who owns the record

Where it is
example-corp/shop-api · api/accounts/get.ts · line 48 · Pull request #482
What raised it
AI reviewAccess control
Severity and impact
HighAny signed-in user can read another customer’s name, address and order history.
Proof status
Proven on the running applicationLinked to: Customer records readable by any signed-in user · api.example.com
Policy outcome
Held · signed off by Engineering lead · waiver expires 18 Oct 2026
Suggested fix
Check that the signed-in user owns the record before returning it, and add a test that covers it.Fix pull request #489 ready

Illustrative sample for Example Corp on example.com. Not a real finding.

Code and running systems

Proven, not just flagged

A code check tells you what might be wrong. Nemesis also runs an engagement against your running application, so a finding in your code can be proven there. Your team knows which code issues are real.

  • One issue, both views

    The code finding shows the file and line. The engagement finding shows what it allowed on the running application, with the evidence.

  • Proven says so

    A code finding the engagement has proven carries the label: proven on the running application.

  • Unproven stays open

    A code finding that has not been proven is not dismissed. It stays open, labeled as flagged.

How engagements run

Handling

Your source code, checked and never stored

Your source code is the most sensitive thing you share with us. These rules apply to every check, and findings follow the same rules as the rest of your client data.

  • Checked, then destroyed

    Each check runs in a temporary workspace that is destroyed when the check ends. Your source code is never stored. We keep the findings only.

  • Secrets masked

    Secrets found in your code are masked wherever we show them. They are never shown in plaintext.

  • Least access

    The app can read code, post checks and comments on pull requests, and open pull requests with suggested fixes. It never merges anything, and you choose which repositories it covers.

How we protect your data

Included in the annual subscription

Catch it in the pull request,
not in production

It comes alongside offensive security across your running systems, daily dark-web monitoring and one written report every week. Tell us which repositories you want covered.

Request an engagement