Is your code getting better or worse?

A function with a convincing name that returns the same value whatever you give it. It passes the build and does nothing useful.

Tests that pass without checking any result, and your coverage figure counts them anyway.

Code that catches a failure and carries on as if nothing happened, so the problem turns up later with no trace of where it began.

Notes that say "fix this later", warnings switched off, old code commented out and left behind. None of it breaks the build, so it piles up.

Copied blocks that drift apart, so a fix made in one copy is missing from the others.

A library you rely on is found to have a security flaw after it passed your checks. Your own code didn't change, so there is no new build to catch it.

In the parts of MS.Microservice that process audio files and Excel spreadsheets, the survey found four places where the code catches an error and throws it away. Nothing is logged and no alert is raised. The program carries on as if everything worked, so a file that failed can look just like one that succeeded, and the problem only shows up later, far from where it started.

Read the 380 other findings in the survey →

Atlas is the back end of a legal-services product. Like most software, it's built on ready-made building blocks written by others, called libraries. The survey found 37 of them out of date and 4 that are no longer maintained. Three have publicly known security holes, two rated high severity, including the ones it uses to handle email. The code builds and runs fine, so nothing flags it until the team updates those libraries or an attacker uses one of the holes.

Read the 82 other findings in the survey →

In 66 of dev-store's files, almost all of the recent work comes from one developer. The survey calls it an off-boarding risk: if that person leaves, nobody else knows those files. Across all 73 of the project's main files, the knowledge has faded so far that, in the survey's words, no one currently understands them.

Read the 93 other findings in the survey →

A map of how your system is put together, redrawn at every survey (C4 model), so it matches the code even after months of changes.

A changelog drafted from the code's history, so release notes start from facts instead of memory.

In the standard format for a software bill of materials (CycloneDX SBOM): the list your security team, your lawyers and your customers keep asking for.

What the codebase is, how it's organised and how it came to be that way. A head start when a new developer joins or a buyer starts a due diligence.

A check of whether the code still follows the design decisions your team wrote down (ADR conformance), with every place it has drifted.

Every security finding, tagged with its standard weakness type (CWE), the way auditors and security teams expect to see it.

We never build the code we measure and we take no success fees, so a higher or lower score earns us nothing. We're paid to measure, never to move the number.

The scoring rules are published before your code is scored, and neither side of a contract can change them. When they change, that's a new published version, every result names the version it used, and a contract can lock one version for its whole term.

Every survey carries the evidence behind its score, and the program that turns that evidence into the number is open source. Run it yourself and you get the same number back. That confirms the calculation; how each measurement was taken is set out in the survey itself.

Each survey runs automatically on Watchdog's own hardware in Denmark, inside the EU. Your code is held in memory while it runs and erased the moment it finishes, without ever being saved to disk. No person reads it, and no cloud provider is involved at any point.

Watchdog's language model runs on the same machines as the survey, and it only assists with a few advisory notes; the score itself comes from the measurements. Your code is never sent to OpenAI, Anthropic, Google or any other AI provider, and never used to train a model, so there's no outside AI service for your security or legal team to approve.

If your organisation needs it, the whole survey can run on your own machines, so your code never leaves your network.

EU security and resilience rules, accessibility standards and security checklists (NIS2, DORA, WCAG 2.2, OWASP ASVS and more), switched on per repository. Watchdog checks the part a tool can check, and a control it finds failing can't be quietly passed. You declare the rest. Not a certifier: it records the evidence, and a named human signs.