Start with the survey. Add scanners where it says you need them.

Tangled logic, classes that try to do too much, code copied instead of shared, and notes left to fix later. These make every change slower and riskier, and code-quality scanners exist to catch them.

Code patterns that often lead to security holes, found by checking the code against published security rule sets (OWASP). Each finding carries its standard weakness code (CWE), the way auditors and security teams expect to see it.

Passwords, tokens and keys written into the code, including ones that were deleted later but can still be read in the code's history.

Every library the product depends on is checked against publicly known security holes (CVEs) and against packages published as malicious. The survey also lists every library and its licence (CycloneDX SBOM).

Settings that leave a system open, found in the files that describe how it is built and run, such as Dockerfiles, Kubernetes and Terraform files.

Every day, a security watch checks the libraries the product uses, passwords and keys left in the code, and unsafe settings. It sends what it finds to Slack, Microsoft Teams or Discord.

Every repository you ship together is surveyed as one product and graded from 0 to 100, whatever mix of languages it is written in. When several services live in one repository, each also gets its own score, so the team can see that the product is fine while one service is not.

When a product is built around a model of the business, messages between its parts or a stored history of events, Watchdog grades whether the code keeps to that design. It also checks whether the code still follows the design decisions the team wrote down. Where the product is divided into separate areas, it draws a map of them from the code at every survey.

Watchdog reads the code's history: files that change often and are hard to read, parts only one or two people know, and code nobody has worked on for so long that the knowledge of it has faded. It also checks whether the platforms the product runs on still get security updates.

Every finding, from security to design, is ranked in one list by how much fixing it is expected to raise the score for the work it takes. The team, or its coding agent, starts at the top, and the next survey shows whether the fixes worked.

Four reports, written for leadership, engineering, security and audit, come with every survey. With them come a description of the system, release notes drafted from the code's history, and the evidence a tool can provide for regulations such as NIS2, DORA and the Cyber Resilience Act. They are rebuilt at every survey, so they match the code on the day someone asks for them. What you get lists everything a survey delivers.

Every survey comes in a signed package, so a customer, an auditor or an investor can check it has not been changed. The rules behind the score are published, and anyone holding the survey can work the score out again.

Watchdog works without any of the tools you run, and their findings never go into its score. The score comes only from Watchdog's own measurements of your code, by rules published on What we measure. The same code gets the same score, and when the score moves, the survey shows whether your code, the rules or the known security holes changed.

The survey reads the pipeline files in your repository and sees which of five common kinds of automatic check already stop a change that fails them, such as a check for passwords and keys left in the code. It ranks the missing kinds by what it found in your own code: if it found keys in the code and nothing in your pipeline checks for them, that check comes first. If your pipeline has none of these checks yet, the ranking shows which one to start with. The survey names the kind of check, never a product. The guide on which automatic check to add first explains the ranking.

Your coding agent, such as Claude Code or GitHub Copilot, can read the ranked fix list through the standard way coding agents connect to tools (MCP), so you can ask it to work through the fixes in order. The findings also come as a file in the standard format for code findings (SARIF), which code-scanning tools such as GitHub's can show next to the findings from your other scanners. If your company keeps an internal site that rates each piece of software against a checklist (a developer portal, such as Backstage with Soundcheck), that site can read the Watchdog score and use it in its ratings. Once a fix is made, the next survey shows whether the problem is gone.

Watchdog makes no commits and opens no pull requests, so every change is made by your own team. The survey runs on the schedule your team sets, outside the checks every change must pass, so it never delays a release.

Every Watchdog survey checks for code that is hard to maintain and for security weaknesses, and grades what no single line shows: how the parts of the product depend on each other, and how knowledge of the code is spread across the team. Code-quality tools, such as SonarQube, give a closer view while the work happens: they check each line as it is written and each change before it is merged.

Watchdog checks the product's libraries at every survey and in a daily watch, lists every library with its licence (CycloneDX SBOM), and ranks each security hole in one list with every other problem, so the team can see whether a library upgrade or a fix elsewhere should come first. Library security tools, such as Snyk, look closely at the libraries themselves, and many prepare the upgrade for the team.

Watchdog checks the team's own code against published security rule sets (OWASP), and in the same survey looks for passwords and keys in the code and its history, libraries with known security holes, and unsafe container and cloud settings. Deep analysis tools, such as Coverity, give a detailed view of one kind of risk: they trace how data moves along each path through the code to find crashes, leaks and paths an attacker could use.

At every survey Watchdog looks at the product once the changes are in, and shows which part got worse since the last survey, so the team sees the effect of all its reviewed work together. Review tools, such as CodeRabbit, look at the work one step earlier: they comment on each proposed change (pull request) before it is merged.

Watchdog draws the dependencies between the parts of the whole product as a map and a matrix, across the languages it covers, and shows at every survey where loops between parts have appeared. Structure tools, such as NDepend, look at .NET code from another side: a team can explore how the parts depend on each other down to single methods, inside the developer's editor, with rules it writes as code queries.

Watchdog reads the code's history for files that are hard to read and change often, and for parts only one person knows, and ranks these risks in one list with security, library and design problems. Behavioural analysis tools, such as CodeScene, look at the same history from the team's side: they analyse single functions and how people work across the code, and some can rewrite code for the team.

Because Watchdog's rules are published and the same for every product, a manager, an owner or a buyer can compare one survey with the next and one product with another, and anyone holding a survey can work the score out again. Many code-analysis tools let each team set its own rules and limits, which gives the team checks that fit the way it works.

Watchdog surveys the code where it is kept, so a service still being built and the module written this sprint are graded by the same rules as the rest of the product. Monitoring tools look at the same product once it is live: they show which parts are used, how fast they respond and where errors occur.

Watchdog reads code without anything being installed in a running system, so an owner can grade a supplier's delivery, and a team can grade a product it has just taken over before it runs any of it. Monitoring tools give the operating team a detailed view of the systems it runs itself.

Watchdog checks every library the product depends on against publicly known security holes, and ranks each one with every other problem, whether or not that code has run yet. Some tools that watch the running system add another view: which libraries and functions actually ran in production, so a team can see which known holes sit in code that is in use.

Watchdog grades each repository by published rules that no team can adjust, tied to one exact version of the code and of the rules, so the score means the same for every service in the portal. Developer portals add the company's own view: who owns each service, whether it has someone on call, and which of the company's own standards it meets.

A portal can read the Watchdog score and the grade of each part on a schedule, so a check can require, for example, a score of 70 or more, or a minimum security grade for services that handle customer data. The portal adds what it does best: levels, certifications and campaigns across teams, so the company can see which services meet its bar and follow them as they improve.