What we check

We scan every file in your snapshot for credentials committed straight into source — API keys, database passwords, private keys, and access tokens. A hit on a real production code path is treated as hard evidence, not a guess.

We check every dependency your project actually installs against public vulnerability databases, resolving the real installed version from your lockfile wherever one exists — covering npm, Python, Go, and Rust. Maven/Gradle manifests are read too, but Java has no universal lockfile, so those versions are declared, not resolved, and are reported as advisory. Known High and Critical vulnerabilities in packages that ship to production are surfaced as hard evidence. A manifest in a language we don't yet cover (Ruby, PHP, …) is named explicitly rather than silently skipped — its dependencies are unverified, not clean.

We look for the vulnerabilities that turn a data breach into a headline — injection flaws, broken authentication, exposed secrets, and gaps in how your APIs and infrastructure protect themselves. Every finding points to the exact file and line, with a fix.

We check how your app collects, stores, and hands off personal data — consent, data governance, audit trails, and readiness for the regulations that actually apply to you, including GDPR, CCPA, HIPAA, PCI DSS, and SOC 2.

We look at what happens when something goes wrong — a crash, a dropped connection, a bad deploy — and whether your app recovers gracefully or takes your users down with it. Backups, failover, and fault tolerance all fall here.

We read your codebase the way a senior engineer would on day one: is it organized, is it readable, and how much will the next feature cost to build on top of it. This is where technical debt gets named.

AI-generated code has its own failure modes — confident-looking placeholder logic, hallucinated APIs, copy-pasted duplication, and edge cases nobody thought to handle because nobody wrote the code by hand. We look specifically for these.

We look at what slows your app down under real load — inefficient queries, missing caching, wasted memory, and anything that gets more expensive as you grow.

We check the machinery that gets your code into production and keeps it there — your CI/CD pipeline, container and infrastructure setup, environment separation, and how secrets are managed through their whole lifecycle.

We look at your data layer for the mistakes that are hardest to undo — unsafe migrations, missing constraints, unencrypted sensitive fields, and transaction handling that can silently corrupt data.

We step back and ask the practical questions a founder or investor would: is this ready to run a real business on, what does it actually cost to keep alive, and where are you locked into a vendor or a license you didn't mean to take on.

We check how easy your own repository is to work in — local setup, build reproducibility, onboarding a new engineer, and the release process. A repo that's painful to develop in slows down everything else.

We check whether your app is usable by everyone — screen-reader and keyboard support, responsive layouts, clear error messaging, and basic internationalization and browser-compatibility gaps.

We check whether you'd actually notice if something broke — logging, metrics, tracing, and alerting that gets a human to the right place before your users notice first.

We take a forward-looking view: how much of this codebase depends on one person's memory, how expensive a future rewrite would be, and whether this is something you can keep maintaining a year from now.

We flag the genuinely novel ideas in your codebase — algorithms, architectures, or methods worth protecting — and check two separate ways they can leak: through a public repository, and through public-facing copy (README, docs, marketing) that spells out how something works rather than just what it does. This is an independent signal and never affects your production verdict.

A focused pass on GDPR readiness: whether you have a lawful basis for the personal data you collect, real consent flows, a clear picture of where personal data lives, a working path to honor deletion and data-subject-rights requests, and a plan for cross-border transfers and breach notification. Findings here are grouped with the broader Privacy & Compliance check. nittim runs this automatically when a repository shows signs of handling personal data.

We compare your own documentation — README, CLAUDE.md/AGENTS.md, docs, ADRs, SECURITY.md, and privacy/security/trust pages — against the code it describes: a claim that names something concrete is checked for whether it actually exists, and a claim that states a rule is checked against whether the code actually follows it. This catches two failure shapes a normal audit misses: a documented feature whose implementation was deleted or never finished, and an endpoint that quietly contradicts a rule the documentation states as fact. A free scan already reports which documented claims name something missing — this module adds the deeper check of whether an existing, anchored claim is actually still true.