Source to Sink: Bob Catches Data Leaks in PRs

The problem Most data leaks don't look like leaks. A developer adds a small helper that returns { ...customer, source: "web" } and passes it to a CRM call. There's no API key or password in the diff, so secret scanners let it through and a busy reviewer approves it. But that one spread just sent every customer's CNIC, phone number and home address to a third party. With AI writing so much of our code, these slip through more often, and personal data quietly ends up in logs and API responses. What I built Source to Sink is a GitHub Action that runs IBM Bob on every pull request. Bob reads the changed code, checks the models to see which fields actually exist, and follows the data through helpers, object spreads and variables until it finds where it ends up. If sensitive data reaches a log, a third party API, an API response, an error tracker or unencrypted storage, Bob reports it with the exact file and line. Identity, financial and credential data count as high severity, so the check fails, and with a branch ruleset the merge button stays locked until it's fixed. Who it's for Teams whose apps handle personal data: fintech, healthcare, HR, legal and ecommerce. How it works day to day Setup is one workflow file and one secret, your Bob API key. On each PR, a single comment appears and keeps itself updated. It shows which field leaks, where it goes and on which line, with a suggested fix and a prompt you can copy into Bob. The developer pastes it into Bob's Privacy Fixer mode, Bob makes the smallest safe change, they push, and the check goes green. Every scan is also saved to a dashboard. You sign in with GitHub and see only your own repos, private ones included, with totals, a chart of the last two weeks, the fields that leak most, filters and search. Sensitive data isn't a fixed list: teams add their own fields, like salary or profit_margin, with one line in the workflow. Why it's different Most privacy scanners are built on static analysis. Here Bob's reasoning is the engine, so it catches leaks hidden behind helpers and spreads, explains each one in plain English, and doesn't report fields that don't exist. The rules are simple markdown files anyone can read and change. Finding a leak and fixing it happen in the same loop. Scans reach the dashboard through GitHub's OIDC tokens, so there are no shared secrets between repos, and private repo access follows the permissions people already have on GitHub. Does it work I tested it on a small shop app and on a pull request with one leak each in Python, Java, Go, C#, PHP and Ruby, covering all five kinds of sinks. A harmless PR touching the same six languages passed with nothing flagged. I also added profit_margin as a custom field, and exposing it in an API response blocked the PR.