A security review on every pull request, in the pull request.

Developers should not have to leave the review to learn what a change does to security. Aribot scans the pull request, ties each finding to the lines that cause it, and says which modelled threats the code mitigates.

PR commentSTRIDE, PASTA, MITREVerified against codeTickets to your trackerMCP tools

See it Book a call Free AI readiness assessment

Findings arrive as a comment on the pull request

Each scanned pull request gets a review comment with what was found and why it matters. When the code changes, the same comment is updated.

Threats named in the language your team already uses

Findings are classified with STRIDE, PASTA and MITRE and pointed at the lines that cause them, so the fix starts at the right place.

Know which threats the code mitigates

Threats from your threat model are checked against the code. A threat is marked mitigated only when the code shows it, and an unverified threat stays visible.

Fewer findings that turn out not to apply
The same verification can gate the pipeline (see pipeline security)

Tickets in the tracker you already run

File findings to Jira, GitHub, GitLab, Azure DevOps or ServiceNow, one ticket per threat. Owner, due date and status stay in step with the ticket.

Security review happens too late, somewhere else, in someone else's words

A pull request is the one moment when a change is small, its author is paying attention and a reviewer is already looking. It is the cheapest place to fix a security problem. Yet in most teams the security view of a change arrives later and elsewhere: a scanner report in a separate tool, a weekly digest, a ticket raised by a security engineer days after the code merged. By then the author has moved on and the fix costs a context switch.

When security feedback does reach the pull request, it often reads like noise. A scanner lists dozens of generic findings, most of which do not apply to how the system is built. Developers learn to scroll past. The findings that matter, the ones that undo a decision the architects made in the threat model, look the same as the ones that do not.

Security teams have the opposite problem. They spend real effort on threat models: which components exist, how data flows, what could go wrong, what mitigations are expected. Then the model sits in a document while the code moves on. Nobody can say with confidence whether the mitigation agreed for the payments webhook is in the code today.

Aribot's code review closes that gap where it is cheapest to close. It scans the pull request, ties each finding to the lines that cause it, names it in the threat language your teams use, and checks your modelled threats against the code. The result is one comment on the pull request, a clear pass or fail, and a ticket in your tracker for anything that must be fixed later. The pipeline security page covers the other half: the pipeline that ships the change.

Developers get a useful comment. Everyone else gets the record

Feedback developers will read

One comment per pull request, updated on each push, pointing at lines in the change and at the threats it affects. No second tool to open, no inbox of reports.

The threat model, enforced in code

Each modelled threat is checked against the code on every change. You can say which agreed mitigations are implemented, and stop a change that removes one.

A review record for every change

What was found on each pull request, whether the check passed, which ticket tracks the fix, who owns it and when it is due. Evidence for secure development controls, kept as work happens.

Review that keeps pace with AI-written code

Code from assistants arrives faster than people can review it. The same check runs on every change regardless of who or what wrote it, and assistants can use the review tools through MCP within your permissions.

A finding pinned to the line, and one comment that keeps up

Pull request, head commit, one comment

Illustrative. A new webhook handler applies an event without checking its signature. The finding pins to line 14 and the Aribot comment fails the check. After the next push adds a signature check, the same comment updates to a pass.

The review scans the head commit of the pull request: the code as it will be merged. When it finishes, it comments on the pull request. With the GitHub Action, that comment is a single summary that is updated on each run, so a pull request that takes eight pushes to get right still has one Aribot comment, and it always describes the latest code.

Each finding points at the file and lines that cause it and is classified with STRIDE, PASTA and MITRE, so “tampering: an unsigned event reaches the ledger” arrives with the place to start. The comment states the result plainly: pass or fail, why, how many files were analysed and which threat model the change was checked against.

Developers fix the problem in the same pull request, push again and watch the comment change. Reviewers see the security picture without asking for it. Nobody has to open another tool unless they want the detail, which is a click away in the code security screens.

From threat model node to the line that mitigates it

This is what separates a threat-aware review from a scanner. Your threat model lists the components of the system and the threats against each one, with the mitigation you expect. On each review, Aribot checks those threats against the code in the scan. A threat is marked mitigated only when the code shows it. Anything else stays unverified and visible, never quietly closed.

The aribot check GitHub Action turns that into a gate. It creates a scan for the working tree, uploads the source, verifies every modelled threat against it and fails the check when there are unverified or critical threats. You choose the failure level: critical, high, unverified or any. A scan that analysed zero files fails whatever the setting, and so does a verification that was expected and returned nothing, because silence is not a pass.

Without a linked threat model, verification is skipped and the check falls back to code issues at critical and high severity. That is a reasonable start. Link the model and the comment begins to talk about your system: the bookings API, the carrier webhook, the ledger, and whether the protections the architects agreed are still in place after this change.

Threat model linked to code

Illustrative. Two threats on the bookings API are traced to the code. The signature check is found, so the tampering threat is verified. No redaction is found for card data in logs, so that threat stays unverified, and a check set to fail on unverified threats fails.

One ticket per threat, with owner, due date and status in step

Filed, assigned, synced

Illustrative. An unverified threat is filed as one ticket on the route to Jira. The owner and due date set in Aribot follow to the ticket. As the ticket moves to in progress and then done, its status syncs back to the threat.

Not every finding is fixed in the pull request that found it. Some need design work or a change in another team's service. Those belong in the tracker your teams already run. Aribot files threats to Jira, GitHub, GitLab, Azure DevOps or ServiceNow, on routes you set up per destination, as one ticket per threat.

Filing is careful by design. A dry run shows the exact tickets before anything is sent. Filing the same threat again returns “already filed” and creates no duplicate. When a tracker cannot be reached or the outcome is unclear, the result says the ticket may already exist, so nobody files it twice in a panic.

Ownership travels with the ticket. Set the owner and due date on a threat and the linked ticket follows. Pull the current state and assignee of open tickets and the threat shows where its fix stands. The threat model, the review and the backlog stop disagreeing with one another.

The same review, available to the assistant your company connected

The assistant signs in to Aribot's MCP server with OAuth. Every call stays inside your company and is limited to what the signed-in person may do. These are the review tools it can call, by their published names:

comment_threat_on_change

For a completed pipeline scan of a pull request, posts or updates one comment per threat whose linked code the pull request changes. A re-run with nothing changed makes no calls. Public repositories are skipped, with the reason given.

verify_threats_in_code

Checks whether modelled threats are mitigated in a scan's uploaded code: one threat with an immediate verdict, or every threat on the diagram as a batch.

code_review_scan

Starts or re-runs a code security scan for a repository in your scope, with results covering static analysis, secrets, dependencies, pipeline review and the traceability matrix.

file_threat_tickets

Sends up to fifty threat entries to the tracker their route points at, one ticket per threat. Supports a dry run that returns the exact tickets without sending.

sync_threat_tickets and get_threat_tickets

Pull the current state and assignee of open tickets, and read the tickets for given threats or for a whole diagram.

assign_threat and list_ticket_destinations

Set a threat's owner and due date, with the linked ticket following, and list the trackers and routes the caller may send to, without credentials.

Add the check to a repository in four steps

1
Add the workflow
Copy the Aribot check workflow into the repository's GitHub Actions workflows folder. It runs when a pull request is opened, updated or reopened.
2
Add two secrets
Store an Aribot API token and your Aribot API address as repository secrets. Use a dedicated service account scoped to your company, and keep personal tokens out of it.
3
Choose the threat model and failure level
Optionally set which threat model to verify against and the failure level: critical by default, or high, unverified or any. Without a threat model the check covers code issues only.
4
Open a pull request
The check runs, posts one summary comment and passes or fails. Every later push updates the same comment. Book a call if you want help rolling it out across many repositories.

One pull request at Osterly Rail Booking, a fictional travel firm

Fictional company, illustrative

Osterly Rail Booking is invented for this page. Its bookings API takes reservations from a website and two partner apps, charges cards through a payment provider and receives status updates from rail carriers by webhook. The security architect built a threat model for it last quarter. It lists, among others, a tampering threat on the carrier webhook, with the agreed mitigation that every event's signature is verified, and an information disclosure threat on payment handling, with the agreed mitigation that card data is never logged.

1
Monday morning, the change
A developer adds a handler for a new carrier's webhook. It is a small change and the deadline is Friday. The signature check is left as a comment to come back to. The pull request goes up before lunch.
2
Four minutes later, the comment
The Aribot check fails. The comment names a critical tampering finding at line 14, where the event reaches the ledger unsigned, and says the webhook tampering threat is no longer verified in code. The developer has not yet switched to another task.
3
Monday afternoon, the fix
The developer adds the signature check and pushes. The same comment updates: pass, tampering threat verified, signature checked at line 13. The human reviewer approves with the security picture already in front of them.
4
Tuesday, the older problem
With the threat model linked, the review also reports that the card-data threat is unverified: a log line in the charge path writes the request body. It is not in this change and belongs to the payments team, so it is filed to Jira as one ticket, owned by the payments lead and due in ten days.
5
The following week, the sync
The payments team fixes the logging and closes the ticket. The ticket's status syncs back, the next review verifies the threat in code, and the architect's model now shows both agreed mitigations as implemented.
6
Quarter end, the audit
The compliance lead answers the secure development questions in the annual assessment with the review record: every pull request checked, what was found, what was fixed and which tickets tracked the rest.

Names, timings and code in this walk-through are illustrative and do not describe any real organisation.

The review reports on the change; the pipeline decides where it goes

Code review and pipeline security are two halves of the same control. The review looks inside the change and tells the people who wrote it what it does to security. The pipeline security side looks at the road the change travels: whether the pipeline is approved, whether the build met its gates, what the artefact contains and who may run scans against it. Both read the same threat model and the same scans, so the developer gets one consistent answer and the security team gets one record from commit to release.

How the review record maps to the frameworks you report on

The review produces evidence that secure development frameworks ask for. The table shows where it helps. It describes evidence. Certification is your assessor's call.

NIST SSDF (SP 800-218)

PW.7, PW.8

Each pull request is reviewed and analysed for vulnerabilities, with findings tied to lines and to the threat model, and the check records whether it passed. That is evidence for reviewing code and testing it before release.

NIST SSDF (SP 800-218)

PW.1, RV.1, RV.2

Threats from design-time modelling are verified against the code, keeping design and implementation connected. Findings become tickets with owners and due dates, which supports identifying, triaging and fixing vulnerabilities.

OWASP

Top 10, ASVS, Code Review Guide

Findings use categories your developers already know. A review that runs on every change, with a record of what it found, supports ASVS verification and the OWASP guidance on code review.

SLSA

Source track

A recorded, automated review result on each change complements the human review that SLSA's source requirements describe. It does not replace two-person review; it gives the reviewer better information.

STRIDE, PASTA, MITRE ATT&CK

Threat language

Findings are classified in the methods security teams use for threat modelling, so a developer, an architect and an auditor read the same finding the same way.

ISO/IEC 27001:2022, SOC 2

A.8.28, A.8.29, CC8.1

Secure coding and security testing in development, and change management evidence: what was found on each change, what was fixed, and which ticket tracked it.

Readiness, review and evidence in one line of sight

AI readiness self-assessment

A free online assessment against the EU AI Act, the NIST AI RMF and related frameworks. Its questions on secure development lead naturally to how code is reviewed.

Aribot

Threat models, code review, code security and pipeline security in one product, so a threat named in design is checked in code and gated in the pipeline.

Ayurak Trust

Assessments against published frameworks. Assessment templates by Aristiun. The review record and its tickets become evidence for answers on secure coding and change management.

Frequently asked questions

Which commit does the review look at?

The head of the pull request. When you scan a pull request from the product, Aribot reads the pull request's head branch and commit from your provider, scans that commit and comments on the pull request when it is done. With the GitHub Action, each push to the pull request runs the check again on the new head.

Will it flood our pull requests with comments?

No. The GitHub Action keeps one summary comment per pull request and updates it on each run. Threat-level comments posted through the MCP tool are one per threat whose linked code the change touches. Each is updated in place on later runs, and a re-run with nothing changed makes no calls at all.

What makes the check fail?

You choose with one setting. Critical fails on any critical code issue or any applicable threat not yet verified. High adds high-severity issues. Unverified fails on any applicable threat left unverified. Any combines them. Separately, the check fails if the scan analysed zero files, or if verification was expected and returned nothing, because an empty result is not evidence of safety.

Do we need a threat model before we can use it?

No, but you get more from it with one. If no threat model is linked, threat verification is skipped and the check falls back to code issues at critical or high severity. Link a threat model and every modelled threat is checked against the code, which is where the review stops being a generic scanner and starts speaking about your system.

What does “verified” mean for a threat?

That the code shows the mitigation. A threat is marked mitigated only when the scan finds it in the uploaded code. Anything else stays unverified and visible. Verification covers the threats in your model, classified with STRIDE and related methods, so a team can see which design-time risks the code addresses.

Which trackers can findings go to?

Jira, GitHub, GitLab, Azure DevOps and ServiceNow. Each threat becomes one ticket on the route you set. Filing the same threat again returns “already filed” and creates no duplicate, and a dry run shows the exact tickets before anything is sent. Owner and due date set on the threat follow to the ticket, and ticket status syncs back.

Does it work for public repositories?

The pull-request check runs wherever you add the workflow. Threat comments on a change are skipped for public repositories, with the reason given, so threat details are not published on a page anyone can read. Ticket previews that would go to a public repository are flagged as visible to anyone.

Can an AI assistant use this?

Yes. Aribot's MCP server lets an assistant your company has connected start a review scan, verify threats against code, comment on a change, file and sync tickets and assign owners, within your company's scope and the signed-in user's permissions. The server is listed in the official MCP Registry as com.ayurak/aribot-mcp.

What permissions does the GitHub Action need?

Read access to the repository contents and write access to pull-request comments, so it can post its summary. It needs no write access to code. Two repository secrets hold the Aribot token and API address; two optional variables choose the threat model and the failure level.

Want to see it on your own code first? Try the code review demo, or read about pipeline security.