Watchdog puts the condition of your whole product in writing.

The score from 0 to 100 sums up the whole product, whatever languages it is built in, and each area, such as security or architecture, gets its own grade. Each grade opens to the findings behind it, so a number never stands on its own. When one repository holds several services, each service also gets its own score.

Every finding is ranked by how much fixing it is expected to raise the score for the work it takes, and findings with the same cause are grouped into one item. The team, or its coding agent, starts at the top and spends its time where it raises the score most.

Watchdog reads the full history of the code. It finds the parts that only one or two people have worked on recently, the files that change often and are hard to read, and passwords or keys left in old commits, even after they were removed from the current code.

For the people who decide. It gives the score for the whole product, its weakest area and what that means, and a rough estimate of what it would cost to build the code again from scratch.

For developers and their coding agents. It explains every finding and ranks them by how much each fix is expected to raise the score for the work it takes, with the file and line where a finding has one.

For the people responsible for security. It grades the code against a list of common web risks (OWASP Top 10), the most dangerous kinds of weakness (CWE Top 25), the card industry's security standard (PCI-DSS) and a checklist for application security (OWASP ASVS). Where no check could test a category, the report says so and why.

For auditors and compliance. It records exactly what was measured: the code version, the rules version, the tools used and what changed since the last survey. It also carries the signed record of the score.

Surveys run on the calendar you choose: every sprint, weekly, monthly or quarterly. They also run in quiet periods when nobody changes the code, so risks that arrive without a change are still caught, such as a part whose knowledge fades because nobody has worked on it for a long time. Before a release, a handover or due diligence, you can run an extra survey by the same rules.

Between surveys, a daily check looks at the libraries the product uses, passwords and keys left in the code, and unsafe settings. What it finds goes to Slack, Microsoft Teams or Discord, so the team hears about a new security hole the same day it is found.

Every survey is graded by the same rules, so each one adds a point to the score trend for the whole product and for each area. The team sees whether the product is getting better or worse, and can show a board, a client or an auditor how it has developed.

Repositories that are shipped together can be surveyed as one product, and the portfolio view shows all your products side by side, weighted by size. Whoever is responsible for several products sees which one needs attention first.

Coding agents such as Claude Code, GitHub Copilot, Cursor or opencode read the ranked list through the standard way they connect to tools (MCP), and the next survey shows whether each fix worked. Keys for coding agents never count as accounts.

How your coding agent works through the list →

Every finding comes in the standard format for code findings (SARIF), labelled with its standard weakness code (CWE), so code-scanning tools such as GitHub's show it next to the findings from your other scanners. The same findings also come as a spreadsheet (CSV).

If your company rates each piece of software against a checklist in a developer portal, such as Backstage with Soundcheck, the portal can read the Watchdog score and use it in its ratings.

Gate your Backstage scorecards on the CAI →

Switch on the regulations you answer to, such as NIS2, DORA or the Cyber Resilience Act, and each survey records evidence for the parts that can be measured automatically. A named person at your company makes the declaration itself.

Compliance →