I Built a Map of the Doors I Forgot to Lock

Jahnavi — Sun, 18 Oct 2026 14:13:35 +0000

A stranger, a pull request, and a bot that holds your keys

Picture a normal night. You maintain a project on GitHub. Someone you have never met opens a pull request with a tiny change. You are asleep. But something else is awake: your GitHub Actions workflow, the little bot that builds and tests your code.
That bot holds real keys. Tokens, cloud logins, sometimes a role that can deploy to production. Whether a stranger’s pull request can make it misuse those keys depends on a handful of settings that almost nobody double-checks.
This is not a thought experiment. In December 2024, attackers compromised Ultralytics, a hugely popular Python package, and got a crypto miner into real releases. Security firms who investigated describe a pull request whose branch name carried a shell command, and a workflow that pasted that name straight into a command. GitHub’s own security team has a name for the wider pattern: a “pwn request”, a workflow that runs with trusted privileges on code from an untrusted pull request.

What bothered me was not any single mistake. It was that every step looked reasonable on its own.

Why the usual tools miss it

Today’s tools look at one layer at a time:
• Workflow linters read one YAML file and say “this line looks risky”. They can’t tell what the workflow’s cloud login can actually touch.
• Cloud permission tools read IAM roles and say “this role is powerful”. They can’t tell whether a stranger on the internet can ever reach it.
An attacker doesn’t think in layers. They think in routes:

Stranger’s pull request
  → privileged trigger
  → workflow job
  → cloud role (through GitHub’s OIDC login)
  → a role that can pass an admin role
  → the customer database

Each hop might be rated “medium”. Together they are a breach. A building inspector who checks every lock can still miss the unlocked window that connects two corridors.

What I built

GraphGuard shows you your own repository the way an attacker would see it. It is a defensive tool for the people who own the repo.
It reads your workflow files from GitHub and your AWS permissions from an exported IAM file, joins them into one graph, and answers four questions:

Can a stranger reach anything valuable?
Through which route?
Which single fix closes the most routes?
If I make that fix, does it really work?

Why a graph, and why FalkorDB

Think of a pinboard with string between pins. “Starting from an untrusted trigger, follow the strings, however many hops it takes, and show me every route that ends at something sensitive” is natural there. In a table database, every hop needs another join, and you must guess the number of hops in advance.
In FalkorDB the core question is one Cypher query (simplified here):

MATCH p = (t:Trigger {untrusted: true})-[*1..8]->(r)
WHERE r.sensitive = true
RETURN p

FalkorDB is a graph database that speaks the Redis protocol. It stores graphs as sparse matrices and follows connections with fast matrix math, and it ships graph algorithms such as PageRank and shortest path. It also comes with a browser on port 3000, so I can open the same graph my app is using and run queries by hand.
My data model is small on purpose:

Trigger  -FIRES->      Workflow -RUNS_JOB-> Job -CAN_READ-> Secret
Job      -ASSUMES->    Role     -CAN_PASS_ROLE-> Role
Role     -CAN_ACCESS-> Resource (for example, customer-db)
Decision / Finding -ABOUT-> any node   (the agent’s memory)

If you take FalkorDB out of GraphGuard, there is nothing left to run. The graph is not decoration, it is the engine. It does three jobs:

Path finding. Cypher walks from untrusted triggers to sensitive things.
Choke points. It finds the single connection that sits on the most attack paths, and uses PageRank to show which nodes the graph leans on most.
Throwaway graphs for “what if”. One FalkorDB instance can hold many separate graphs. To test a fix, GraphGuard copies the real graph into a temporary sim_ graph, removes one connection, re-runs the path search, compares before and after, then deletes the copy. Your real graph is never touched.

How a scan works

Read workflows + IAM export
  → build the graph in FalkorDB
  → run 12 detection rules
  → find attack paths
  → rank the fix-first choke point
  → simulate the fix on a throwaway graph
  → ask the agent questions
  → remember decisions

The 12 rules cover things like a pull_request_target workflow that checks out the pull request’s own code, user-controlled text pasted into a shell command, third-party actions that are not pinned to a fixed commit, write-all permissions, and cloud roles that can pass a more powerful role.

The part I’m proudest of: it stays quiet when it should

I expected the first real repository I scanned, pandas, to light up. It uses pull_request_target, a trigger people rightly worry about. GraphGuard found zero attack paths.
My first thought was that I had a bug. Then I read their workflows. They pin the checkout to a fixed commit, give the workflow no permissions by default, and only fetch trusted scripts. They never run the pull request’s code. GraphGuard only connects an untrusted trigger to a workflow when that workflow actually runs untrusted code.
A risky doorbell is not an open door. A security tool that cries wolf gets muted, so I would rather it said “clean” when a repo is clean.

An agent that is only allowed to quote the graph

You can ask GraphGuard plain questions like “Can an untrusted PR reach the database?” The agent does not free-write an answer. It chooses a graph tool (find paths, blast radius, shortest path, most depended-on, simulate a fix, recall a memory), runs the query, and answers from the rows it got back.
Every answer ends in one of four honest outcomes: answered with a path, from memory, not in graph, or unknown node. Ask about a service that does not exist, like ghost-service, and it says so instead of inventing one. Names in an answer are checked against what the tools actually returned, and an answer with a made-up name is thrown away and rebuilt from the real rows.
To be upfront: by default the agent is a deterministic router that picks tools from your question, so GraphGuard works with no API key at all. If someone sets a key, an LLM picks the tools instead. Either way, the graph supplies the facts.

Memory that lives in the graph

Security work is full of decisions: “we accept this risk until the end of the month, owner Priya, because the deploy is being rebuilt.” GraphGuard stores those as Decision and Finding nodes linked to the node they are about. They are kept in the graph, not in a chat window, so they come back after a rescan, and an accepted risk that has expired shows up again.

Three things that broke (and what they taught me)

• The app would not start. Spring found two constructors in one class and didn’t know which to use. My tests passed because they built objects by hand. Lesson: add a test that boots the real wiring.
• A scan froze forever. Downloading each workflow file from a second host stalled on my network. I moved to a single API host, added timeouts, and made the error say what actually went wrong.
• A fake database showed up in a real scan. The demo’s customer-db appeared inside my scan of pandas. Sample data must never leak into real results, so a scan of a real repo now starts with no cloud data unless you upload an IAM file.

Try it yourself

git clone https://github.com/jahnavichalla19-Jaanu/graphguard.git
cd graphguard
docker compose up --build

Open localhost:8080 for GraphGuard and localhost:3000 for the FalkorDB browser. No API key is needed. Click Load Demo Graph, then Find Attack Paths, then ask the agent about the database. After that, scan one of your own public repositories.

What it can’t do (yet)

• It shows where to look. A path means a risky route exists in the setup. It does not prove someone could exploit it today.
• Cloud permissions come from an exported IAM file. Live AWS scanning is not implemented.
• It has 12 rules, not every CI/CD weakness.
• The API has no login, so run it on your own machine.
• The graph drawing library loads from the internet, so the picture needs a connection.

What I’d build next

Tests against a real FalkorDB in CI, API authentication, SARIF export so findings appear in GitHub’s code scanning, a bigger evaluation set for the agent, and exposing the graph tools through MCP so other agents can use them.

How I built it

I built GraphGuard during the hackathon, using AI coding assistants for code, review and documentation [edit this line to describe exactly how you used them]. I directed the design, ran and debugged everything, and I can explain the graph model, the queries and the decisions behind them. The data is public workflow files and a made-up IAM sample, nothing private.
If you take one thing from this post, let it be this: the most useful security answer is not a list of 400 warnings. It is “fix this one thing first”, and proof that it works.
Code: https://github.com/jahnavichalla19-Jaanu/graphguard· Demo: https://youtu.be/-uLW4-E6fdc

DEV Community: Jahnavi