Vulnerability data is fetched live, never a bundled snapshot
New exploits and CVEs get disclosed daily. RepoSentry never ships with a bundled or cached vulnerability database - every scan queries OSV.dev in real time at the moment you run it, so a dependency flagged safe last month is re-checked against whatever's known right now. This tool doesn't need to be updated for its results to stay current.
The detection layers
Dependency, secrets, due-diligence, and privacy are deterministic - same input, same output, every time. AI deep review is where actual reasoning happens: the layer regex and a CVE database structurally can't replace. Agent-targeting is a hybrid of the two - a deterministic pass narrows down candidates, then the same AI review judges intent.
Dependency check - always live, never a bundled snapshot
Public scans check the manifest directly (package.json, requirements.txt, go.mod) - direct dependencies at whatever version range was declared. Private-repo scans on the Teams plan read the repo's lockfile when one is committed (package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, go.sum, Cargo.lock, Gemfile.lock, composer.lock) instead - the full resolved tree, direct and transitive, at exact installed versions. Either way, every dependency found is looked up with a real-time API call made at the moment of your scan, not against a copy of the database shipped with this tool.
Secrets scan
Regex scan for hardcoded credentials (AWS, GitHub, Slack, Stripe, Google, OpenAI, Anthropic, Twilio, and SendGrid keys, private key blocks, JWTs, generic password assignments).
Source: Pattern set modeled on gitleaks' default rules - every text file in the repo, no sampling.
Repository & author due diligence
Repo age, last-updated date, stars/forks, license, archived status; author account age, public repo count, followers.
Source: GitHub REST API - public, unauthenticated, the same data anyone sees on the repo's GitHub page.
Data handling & privacy disclosure - 10 categories, every scan
PII in test fixtures/seeds, personal data in logs, telemetry/analytics SDKs, outbound third-party calls, disk/storage writes, retention & deletion handling, encryption signals, the repo's own commit metadata, cross-border hosting hints, and privacy documentation. Every category gets an explicit clear / flagged / not-determinable answer, never a silent gap - shown in its own dedicated section for GRC/compliance review.
Source: A disclosure pass separate from the security findings; flagged results are also mirrored into the findings list at low/medium/info severity.
AI deep review - every claim checked against the real file
Reads every file the heuristic pass flagged, plus CI workflows, Dockerfiles, and manifests, using judgement rather than pattern matching - catches intent, typosquatting, CI secret exposure, obfuscation. Every finding it produces must cite a real file and a verbatim snippet, which is then programmatically re-verified against the actual cloned file before being accepted - an unverifiable claim is dropped, not kept.
Source: Claude, following a fixed review specification, with independent verification of every claim before it's accepted - auditable, not a black box.
Agent-targeting content scan - shown in its own dedicated section
Content aimed at manipulating an AI coding agent rather than a human: prompt-injection phrasing addressed to an AI/assistant/agent, hidden or invisible Unicode text, and MCP server configs pointing at untrusted remote endpoints. Known agent-instruction files (AGENTS.md, CLAUDE.md, .cursorrules, MCP configs) are always handed to the AI deep-review step for a full read, even with no keyword match. Classified against the OWASP LLM Top 10 and CWE-1427, not OWASP Top 10 (2021) - a different risk category, kept separate rather than mixed into the OWASP Top 10 breakdown.
Source: A dedicated deterministic pass, the same AI deep-review step for judgement, verified the same way as every other AI-sourced finding.
Classification frameworks
OWASP Top 10 (2021)
Every finding is tagged with one of these ten categories, so results are comparable across scans and to what security teams already use.
CWE (Common Weakness Enumeration)
Maintained by MITRE. A specific weakness ID where applicable, e.g. CWE-798 for hardcoded credentials.
CVSS v3.1
Dependency findings with a real CVSS score from OSV.dev use it directly; everything else gets a severity band loosely aligned to the same scale.
What's intentionally excluded, and why
Generated/vendored directories
node_modules, vendor, dist, build, .git, venv, __pycache__, and similar are not scanned - they're third-party or generated code, not the repository's own, and scanning them would mostly reproduce whatever the dependency check already covers. A stated exclusion, not a silent one.
Binary files
Not scanned for secrets/heuristics - there's no text to pattern-match - but dependency and author checks still apply regardless.
The target repository's code is never executed
Not npm install, not a build step, not opening any file from the clone in an interpreter. Only fetching and reading files as text. A deliberate safety boundary, not a coverage gap - see /security.
Bounded, not silently capped
A small number of practical limits exist to keep a scan from running forever on a pathological input. Every one is designed to disclose, not hide, when it's actually hit: file walking is capped at 50,000 text files and 5MB per file (generous enough that this essentially never triggers on a normal repository - if it does, the scan's log and coverage stats say exactly how many files were skipped and why), and full CVSS detail lookups for dependency vulnerabilities are capped at 300 distinct advisories per scan (beyond that, a finding is still produced, just with an estimated severity - also disclosed in the log).
Keeping the AI review step efficient
AI only sees what's already been narrowed down
The heuristic scan hands the AI review step a list of just the files worth judgement - dynamic code execution, base64 near eval, shell exec, npm lifecycle scripts, obfuscation-shaped code - not every file in the repo. Everything the deterministic layers can already answer outright never reaches the AI step at all.
One pass, not a fan-out of subagents
The AI review runs as a single structured call per batch of flagged files - no open-ended agent loop, no dozen parallel contexts each re-paying their own setup cost.
A hard spending ceiling regardless of repo size
A batch cap stops any single scan from running away on cost no matter how large or unusual the target repo is.
Interruptions resume instead of restarting
If a scan is cut off partway through, resuming continues from where it left off rather than re-fetching and re-scanning the repo from the beginning.
Actual per-scan cost and token usage is shown on every finished report under For developers - straight from real usage accounting, not an estimate.
See also /security for why RepoSentry itself is safe to trust.