Every security tool you buy asks you to make the same trade. Send us your findings, your repository names, your file paths, your dependency graph, your secrets metadata — and we'll give you a dashboard. The data lands in the vendor's account, in the vendor's region, under the vendor's retention policy. You get an export button and a promise.
We think that trade is backwards, and we've built the opposite. The scanner is free and open source. The platform behind it gets deployed into your AWS account, not ours. Your findings never leave your walls, because there is nowhere else for them to go.
Start with the boring part: the scanner works everywhere
Before the architecture argument, the tool has to earn its place. Zagware Scanner is a single container that runs three engines over a pull request — infrastructure-as-code misconfigurations, dependency vulnerabilities, and leaked credentials — and posts one comment.
It runs on all four major Git platforms: GitHub, GitLab, Bitbucket, and Azure DevOps. Not "GitHub, and the others eventually." Each one has a proper adapter that understands how that platform exposes its pull requests, its base and head refs, its comment API, and its authentication.
It only tells you what you just broke
The scanner clones the base branch and the head branch, scans both, and reports the difference. A repository with four hundred pre-existing findings does not produce a four-hundred-line comment on an unrelated one-line change. It produces a comment about the one line you changed.
This sounds like a small thing. It is the difference between a tool people read and a tool people mute.
Findings have stable identities
Every finding across all three pillars gets a fingerprint — a hash of what the finding actually is, not where it happens to sit today. Reformat the file, move the resource, shift the line numbers, and the fingerprint survives. That is what makes a diff meaningful across commits, and it is what makes suppressions hold instead of quietly reappearing next week.
Suppressions are a conversation, not a config PR
On GitHub, a reviewer can suppress a finding by replying to the bot in the pull request with the finding id and a reason. No separate file, no second PR, no context switch away from the review that prompted it.
The suppression is then committed to the repository as a record — and if the platform is connected, the same record is pushed to your backend with the author, the timestamp, the reason, and the finding it covers. When an auditor asks why a critical finding was waved through in March, the answer is a query rather than an archaeology project.
One rollout, every repository
Adding a scanner to one repository is easy and pointless. The value arrives when it covers everything, which is why the scanner is designed around the org-wide mechanisms both major platforms already provide — Pipeline Execution Policies on GitLab, and organisation-level rulesets and reusable workflows on GitHub.
You enable it centrally. New repositories are covered on creation. Nobody has to remember to copy a YAML file, and nobody can quietly delete it from their own repo.
Now the part that's actually different
The scanner posts its findings somewhere. That somewhere is the Git Tracking Platform — scan history, suppression audit trails, compliance reporting, activity metrics. It is the piece that turns individual pull request comments into a picture of your organisation over time.
And it runs in your AWS account.
Not "your data is logically isolated in our multi-tenant cluster." Not "we offer a single-tenant tier at enterprise pricing." The actual infrastructure — a VPC, an RDS Postgres database, ECS services, Lambda functions, an API gateway, a CloudFront distribution — is stood up inside an account you own, in a region you choose, under IAM you control.
The practical consequences are worth spelling out:
- Your database is your database. You can connect to it. You can query it. You can back it up on your own schedule, to your own bucket, under your own retention rules.
- Your bill is mostly AWS's. You pay AWS directly for what the platform consumes, which for most organisations is a small monthly figure. You pay us for the service around it, not for the privilege of storing your own data.
- Data residency is a region setting. If it has to stay in eu-west-1, it stays in eu-west-1. That's a Terraform variable, not a sales conversation.
- There is no vendor breach that exposes your findings. We do not hold a copy. There is no central honeypot of every customer's misconfigurations and secret locations, because there is no central anything.
What happens when you leave
This is the question that tells you what a vendor actually believes, so here is our answer plainly.
If you end the contract, we stop pushing updates. That's it. That's the whole consequence.
The platform keeps running. The database keeps holding your data. The dashboards keep rendering, the APIs keep responding, the scan history stays queryable. Nothing phones home, nothing expires, no licence check fails at midnight and takes your compliance reporting down with it. You keep the thing you were using yesterday, exactly as it was.
What you stop getting is the ongoing work: new detections, new report types, platform upgrades, dependency and base-image patching, new Git provider features, the fixes we ship because someone else hit a bug first.
A subscription should buy you continued improvement, not continued permission to use what you already have.
We think that's the honest shape for this. It also keeps us honest: if the monthly work stops being worth the monthly fee, you can stop paying and keep operating. We have to earn the renewal with maintenance and improvements rather than with an off switch.
Bespoke, but still maintained
The usual trade with self-hosted software is that customisation forks you off the upgrade path. You get the changes you asked for, and eighteen months later you're stranded three versions behind because nobody can safely merge upstream into your special build.
We handle that by treating each customer's deployment as a maintained target rather than a one-off. When we ship a change to the platform, it gets pushed into every customer account we look after. Your instance moves forward on the same cadence as everyone else's, including whatever we built specifically for you.
That specific work is a real part of the offering, not a footnote:
- We'll shape the APIs to your reporting stack. If your existing dashboards, SIEM, or data warehouse want a particular payload on a particular schedule, that's an integration we build rather than one you write adapters for.
- We'll add report types. If the way your organisation needs to see this data isn't the way the platform shows it today, the fix is a new report in the platform — not a CSV export and a spreadsheet.
- It's your instance, so the customisation stays yours. Nothing has to be generalised into a product roadmap before you can have it.
Who this is actually for
Not everyone needs this. If you're a ten-person startup with no data residency constraints and no auditors, a SaaS dashboard is genuinely simpler, and you should probably use one.
This model earns its keep in two situations.
You have real constraints about where data lives. Regulated industries, government suppliers, defence, health, finance — anywhere "which account is it in, and who else is in that account" is a question with consequences. The answer here is short: your account, and nobody.
You are tired of the migration treadmill. Most engineering organisations have been through it several times. A vendor gets acquired, or triples its pricing, or sunsets the tier you're on, or pivots away from your use case. Each time, you export what you can, lose the history you can't, and spend a quarter rebuilding dashboards someone already built.
When the database is in your account, that cycle doesn't have the same grip. The worst case isn't a migration — it's a maintenance contract you chose not to renew, running against data you never had to move.
Try the scanner first
None of the above requires a conversation with us. The scanner is free, open source, and runs standalone with no platform at all — point it at a pull request on any of the four providers and read the comment it posts. If it's useful on its own, it's useful.
The platform is the answer to what happens after the hundredth pull request, when you want the history, the audit trail, and the reporting. And when you get there, we think it should live somewhere you control.
Read the scanner docs, or get in touch if the deployment model is the part you want to talk about.