What we check
Every module NittiM can run against a repository, in plain English — no jargon, no mechanism, just what it looks for and why it matters.
The exact module set is selected per repository from its file tree — a repo with account, auth, analytics, or EU-facing content picks up the GDPR vertical below; every repository gets the core scanners and dimensions. Every report shows a "Modules run" strip naming exactly what fired on that audit.
Evidence Scan
Free · deterministic · runs on every audit, paid or not
Hardcoded Secret Scan
DeterministicWe 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.
Dependency Vulnerability Scan
DeterministicWe check every dependency your project actually installs against public vulnerability databases, resolving the real installed version from your lockfile wherever one exists. Known High and Critical vulnerabilities in packages that ship to production are surfaced as hard evidence.
Deep Verification
Paid · Claude Opus 4.8 reasons across every selected module in one pass
Security
Claude-reasonedWe 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.
Privacy & Compliance
Claude-reasonedWe 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.
Reliability & Resilience
Claude-reasonedWe 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.
Code Quality & Architecture
Claude-reasonedWe 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 / Vibe Coding Risk
Claude-reasonedAI-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.
Performance & Scalability
Claude-reasonedWe 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.
Infrastructure & DevOps
Claude-reasonedWe 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.
Data Layer
Claude-reasonedWe 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.
Business & Product Risk
Claude-reasonedWe 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.
Developer Experience
Claude-reasonedWe 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.
Accessibility & UX
Claude-reasonedWe 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.
Observability
Claude-reasonedWe 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.
Maintainability Forecast
Claude-reasonedWe 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.
IP & Novelty Exposure
Claude-reasonedWe 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.
GDPR Readiness
Claude-reasonedA 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.
Evidence, never a verdict — until Deep Verification
The Evidence Scan is deterministic fact-finding: a committed secret or a known CVE is either there or it isn't. It never issues a green light — absence of findings is reported as unaudited, not safe. Only Deep Verification, which reasons across every selected module above, produces the six scores and the ship / don't-ship verdict.
See Data & Trust →