Automated repository security assessment
Code Rail checks a public repository for exposed credentials and known dependency vulnerabilities, then produces a short, prioritized report — the kind of review a developer would otherwise skip. Deterministic scanners do the detection; the AI only reasons over their findings, so it uses a fraction of the tokens that asking an AI to read and check the whole repository directly would take.
Public repositories only. Code Rail clones a temporary read-only copy, scans text files and dependency manifests, then deletes the clone.
config.js apiKey = "AKIA..." lodash: 4.17.15
Click a finding to see the affected file, why it matters, and the recommended fix.
Finds exposed API keys, tokens, passwords and private keys committed to a repository.
Checks third-party packages against known CVE databases so outdated, vulnerable libraries are flagged before they ship.
Every finding is rated high, medium or low, so you know what to fix first instead of facing a flat list of alerts.
Each finding says what the problem is, why it matters, and a concrete recommended fix a developer can act on right away.
Switch between secrets and dependencies, and expand any finding to see the affected file, explanation and fix.
Uses a shallow, read-only copy of a public repository. Nothing is executed and nothing is attacked.
Detection is done by well-known, deterministic tools, so results are repeatable and not an AI guess. The AI only explains and prioritizes what those tools found.
The model receives a short, structured list of findings rather than the whole repository. That saves tokens, keeps cost low, keeps the report focused, and limits how much of your source is ever sent to a model.
Because only the scanners' findings go to the AI, the amount of text it has to process depends on how many issues exist, not how big the codebase is. In the example below, that is roughly 99% fewer tokens. It is an estimate you can adjust, not a measured average.
Small teams and solo developers rarely have time for a full audit. Code Rail gives them a prioritized report in one step, with fixes they can apply the same day.
This is automated static analysis (secret detection and dependency scanning), not a penetration test. We say so in the product, along with its known limitations, because trust in a security tool starts with accurate claims.
An illustrative estimate, not a measured average. Change the numbers to match a repository.
Assumptions: about 10 tokens per line of code; about 500 tokens of instructions plus about 270 tokens per finding (input and output). Real counts vary by language and model. Very large repositories may not fit in a single AI request at all. After running real scans, replace these assumptions with the token counts your AI provider reports.
| Running scanners yourself | Asking an AI to read the repo | Code Rail | |
|---|---|---|---|
| Reliable detection | Yes | Inconsistent | Yes, via the scanners |
| Prioritized, explained results | Raw output to interpret | Yes | Yes |
| Cost to analyze | Free | High, scales with repo size | Low — saves tokens by sending only structured findings, not the repo |
| Setup effort | Install and configure each tool | Upload or paste code | Paste a repository URL |
A shallow, read-only copy of the public repository is pulled for analysis.
Established scanners check for leaked secrets and vulnerable dependencies.
Findings are ranked by severity and explained in plain language.
Code Rail runs two categories of automated static analysis: secret detection (via gitleaks) and software composition analysis (via npm audit / pip-audit) against known CVE databases. It does not execute the application or attempt exploitation — this is not a penetration test.
The scanners above do all the detection work, deterministically and for free. The one AI call reasons over a short, structured list of findings — not the raw repository — to rank severity, explain risk in plain language, and suggest fixes. That is why this uses a small fraction of the tokens an approach that asked an AI to read the whole repository would need.
Secret detection carries known false-positive and false-negative tradeoffs inherent to the underlying tool. This prototype does not check GitHub Actions configuration, repository settings, or source code patterns beyond dependency and secret scanning. It does not replace a professional security audit.