Threat modeling
at the speed of code.
Your threat model lives in the code, so it can’t go stale.
GuardLink keeps your threat model inside your code.
Every security engineer and every developer knows how it goes. The threat model gets written once and forgotten the day coding starts. After that, it’s pentests and scanners. So we asked a simple question. What if every developer left a comment for the security team, right in the code? Add a file upload, and write beside it: @exposes “File upload here. Not security reviewed yet.” The security team reads those comments and knows exactly what to test. The fix gets a comment of its own, and the loop keeps going. Now AI coding agents write the code and the comments, and GuardLink runs the loop. Your codebase becomes the single source of truth, so no threat quietly gets lost.
Live from GitHub and npm, refreshed every hour. Each figure links to its source.
Security knowledge lives outside the code.
That is the bug.
Teams pay for all three, and all three start going stale the next time someone opens an editor.
Two lines in a pull request. The reviewer reads them next to the code they describe, the parser checks that #cmd-injection and #tui are declared, and the exposure stays open until a control answers it.
Three commands keep the model current.
GuardLink puts the claims in the repository and checks them, so a stale claim fails the build instead of sitting there unnoticed.
- 01 / 03
An agent writes the claims
Your coding agent reads the code and records what each part holds, what threatens it, and what already defends it. Claims go in .gal sidecar files by default, or inline in comments.
$ guardlink annotate - 02 / 03
The CLI checks them
Every #id must resolve to something declared. Dangling references, duplicate ids and syntax errors fail here, not six months later when someone finally reads the model.
$ guardlink validate . - 03 / 03
CI enforces them
An exposure with nothing answering it fails the build. To close one, name the control that handles it, or have a person accept the risk under their own name.
$ guardlink ci --strict
guardlink 2.5.0 on the sample project the dashboard below is drawn from. The sidecar records its claims for app/notify.py, including a fictional tracking ticket; validate and ci print what they say about the whole model.
What 2.5.0 adds.
Track remediation beside the exposure, focus annotation work, and keep per-PR checks precise.
Track the work to fix an exposure
guardlink dashboard .guardlink sarif . -o guardlink.sarif- @ticket links a threat on an asset to a tracker ID or URL, with an optional SLA label, assignee and due date. The model, dashboard, diff and SARIF carry it. The annotation is the record: GuardLink never calls the tracker, and a ticket leaves the exposure open.
Give annotation work a clear scope
guardlink unannotated . --jsonguardlink unannotated . --excluded- Get the files still needing annotations and the reason each other file is left out. Coverage measures this scope; annotations in excluded files still stay in the model.
Keep reminders separate from gate failures
guardlink lint . --json- A ticket on a mitigated or accepted pair is an info-level reminder. The JSON includes summary.infos; info never fails the gate. Keep the ticket as a record or remove its annotation when it closes.
Review changes against a consistent base
guardlink diff origin/main --fail-on-new- An unchanged exposure stays stable when lines shift within its anchored symbol. Base and head use the same anchors, and summaries count coding-agent configuration and reach changes too.
Write reach identities the parser can read
guardlink annotate "review agent reach" . --stdout- The prompt and reference now teach the optional as identity as an asset reference: #id, Dotted.Path or a quoted name. Malformed reach annotations explain the expected shape and the token that needs attention.
Twenty-five verbs. Two of them close a finding.
GAL is a small grammar for security intent. It lives in comments, so it works in any language, and its one job is to make a claim about code checkable.
Relationships
Connect threats to assets. Record the controls and decisions that resolve them.
@exposesopens finding- Marks an asset exposed to a threat at this line. Every one creates a finding.
@mitigatescloses finding- Names the control that answers a threat on an asset, and closes the finding.
@confirmed- Records a threat as verified exploitable, with the evidence that proved it.
@ticket- Records an open tracker ticket for a threat on an asset, with an optional SLA label, assignee and due date. Remove the line when it closes; no tracker is called.
@acceptscloses finding- Records a decision to carry the risk instead, which also closes the finding.
@entitles- States an actor is entitled to a capability by design. An agent proposes; a person accepts.
@transfers- Moves responsibility for a threat to another asset or team.
What comes out the other end.
One command turns the model into a self-contained HTML dashboard. The screens below are real guardlink 2.5.0 output for a sample Flask service with an AI assistant built in, and that dashboard is hosted on this site.
Overview. How many exposures are open and how bad, what changed since the commit you name, and what to do next, each item carrying the command that does it.
Open this viewOpen the real dashboard
The file guardlink dashboard wrote, served unchanged: one HTML file, no server, no build step. Open the drawers and diagrams yourself.
Watch the full run
From an empty repository to a reviewed threat model: init, annotate, validate, and the dashboard the run produces.
Your coding agent writes the annotations.
guardlink init detects your coding agent and sets up two things: an MCP server it can query, and a rule in its instruction file that tells it to annotate security-relevant code as it writes it.
- MCP + ruleClaude Code
CLAUDE.md + .mcp.json - ruleCursor
.cursor/rules/guardlink.mdc - ruleCodex
AGENTS.md - ruleGitHub Copilot
.github/copilot-instructions.md - ruleGemini CLI
.gemini/GEMINI.md - ruleWindsurf
.windsurfrules - ruleCline
.clinerules
Any editor that speaks MCP can run the same server: guardlink mcp.
28 tools the agent can call
Read the model, validate it, suggest annotations for a snippet, query threats by keyword, generate a report or a dashboard, export SARIF, or diff against a git ref. The agent asks “what threatens #api?” before it writes code that touches the API.
What the agent itself may do is in the model too
Since 2.4.0, GuardLink reads the configuration that decides what a coding agent may run, edit and call without asking: .claude/settings.json, .mcp.json, .cursor/, .codex/config.toml, skills, hooks and more. Each capability lands in the threat model with the file and line that grants it. Nothing it names is started or fetched.
guardlink validate .- Flags hidden Unicode in instruction files, skills and commands.
guardlink ai-bom .- Exports agents, MCP servers and skill bundles as a CycloneDX 1.6 AI-BOM.
guardlink reach .- Checks the reach the model declares against an optional code graph.
guardlink attest <doc>- Compares a tool inventory or call log with the reach the model declares.
An agent can find an exposure and propose an entitlement. It cannot accept a risk, or decide that a caller was always meant to hold a power: those two statements close a finding or excuse one. The MCP server’s annotate tools reject @accepts and @entitles. An entitlement goes to a person as a proposal, and an acceptance is written only with the name of the person who made the call.
A threat model that can fail a build.
GuardLink runs as a check. A new route with no annotations, or a control removed from under an exposure, shows up in the diff and can block the merge.
- name: Install GuardLink
run: npm install -g guardlink
- name: Validate annotations
run: guardlink validate .
- name: Threat model diff
run: guardlink diff origin/main --fail-on-new
- name: Export SARIF
run: guardlink sarif . -o guardlink.sarif
- uses: github/codeql-action/upload-sarif@v3
with: { sarif_file: guardlink.sarif }The full workflow, with PR comments and SARIF upload, ships as examples/github-action.yml. Multi-repo setups get two more in examples/ci/.
Parse diagnostics: 0 error(s), 3 warning(s) (prose-like 3)Annotations the parser could not read: 3Unmitigated exposures: 16 (high 3, medium 7, low 6)Confirmed exploits: 0Acceptances: 0 (source: @accepts annotations in this repository)Annotation coverage: 92% — 171 of 185 source file(s) annotated, 1061 annotation(s)…⚠ 16 unmitigated exposure(s):#agent-config → #prompt-injection [low] (src/agentconfig/read.ts:26)#agent-launcher → #prompt-injection [medium] (src/agents/launcher.ts:13)#agent-launcher → #prompt-injection [high] (src/agents/prompts.ts:6)#agent-launcher → #config-tamper [medium] (src/agents/prompts.ts:10)#llm-client → #data-exposure [low] (src/analyze/index.ts:12)#llm-client → #prompt-injection [medium] (src/analyze/llm.ts:17)…
Run on GuardLink’s own repository at v2.5.0; ten more exposures and the parse-diagnostic, anchor-drift and stale-claim details are cut here. It is advisory by default and exits 0; --strict makes it a gate.
- New route, no annotations
- The diff shows the gap before a reviewer has to spot it.
- Control removed
- The exposure reopens, and --fail-on-new blocks the PR.
- Exposure accepted
- Recorded under a person's name, not deleted.
Model your first threat
in about ten minutes.
Node 18 or newer is the only requirement. init detects your agent and writes the config; everything after that is three commands.
A threat model says what's exposed. Testing says what's reachable.
GuardLink stops at the code: it never builds or runs your app. When you need to know which exposures an attacker can actually reach, that is what Bravos, Bugb's pentesting product, is for.
GuardLink, open source
What's exposed
Reads the annotations in your source and lists every exposure: the asset, the threat, and whether anything mitigates it.
Bravos, from Bugb
What's reachable
Attacks a running copy of your app with real logins, and ends every threat with a verdict and the reason for it:
- confirmed
- refuted
- not tested
Not sure what GuardLink would find in your code? Send a public GitHub repository and the Bugb team runs GuardLink on it, then emails you the threat model it finds. Nothing is pushed to your repository.
GuardLink is open source. A star helps it travel.
It costs nothing and takes one click, and for a project this size it does two useful things.
- Other teams find it
- GitHub search, topic pages and trending lists all weigh stars. Each one makes GuardLink easier to find for the next team looking for a threat model they can keep in their code.
- The maintainers know it is used
- Stars tell us people rely on it. Issues tell us what to build next, so if something is missing, an issue is worth even more than a star.