Security on your actual dependency graph.
CVE triage that knows whether you really reach the vulnerable code. Secret detection across your full git history. SBOM and audit support, built on the same graph that powers everything else in repowise. Deterministic, with no model in the scanning path.
Scanners drown you in CVEs for code you never call and miss the secrets buried deep in your history. The signal is there, but the noise makes it useless.
A flat CVSS-ranked list treats a vulnerability in a package you exercise on every request the same as one in a transitive dependency you never load. Meanwhile a key committed two years ago and later deleted is still sitting in your history, invisible to a scanner that only looks at HEAD. repowise scores against the graph you actually run and reads the whole history, so the findings that reach you are the ones that matter.
Findings ranked by what you actually reach.
repowise builds on the same dependency graph, git history, and code-health layers that power the rest of the platform, so security is graph-aware from the start rather than a flat scan bolted on top.
Prioritize the vulnerabilities you can actually be hit by
CVE-aware dependency analysis scores findings with KEV and EPSS, then usage-aware triage filters them down to the vulnerabilities your code actually reaches through the dependency graph. Instead of a wall of CVEs ranked by raw CVSS, you get the subset that is reachable in your codebase. Generally available on the hosted platform.
- KEV and EPSS scoring on top of the raw advisory data
- Reachability through the real dependency graph, not a flat list
- Function-level reachability triage on the roadmap
- Graph-aware enhanced scanning and language-specific rulesets in development
Find the secrets buried in your git history
Secret detection runs across your full git history, not just the current tree. Keys and tokens that were committed and later removed are still live exposures, and repowise scans the entire history to surface them. Generally available on the hosted platform.
- Scans full git history, not only the working tree
- Catches secrets that were committed and later deleted
- Runs on the hosted platform with the rest of the security surface
- Audit trail for the security surface on Teams and above
A bill of materials your auditors can use
repowise generates a CycloneDX software bill of materials and can diff SBOMs between versions, so you can answer procurement and audit questions about what is in your software and what changed. Generally available on the hosted platform.
- CycloneDX SBOM generation
- SBOM diffs between versions for change tracking
- Useful for procurement reviews and audits
- Dedicated PCI-DSS and SOC 2 compliance reporting on the roadmap
No model in the loop, self-hosted, reproducible
The scanning and scoring path is deterministic, with no AI or ML model making security decisions. The same inputs produce the same findings every time, so scans are reproducible and auditable. Because there is no model in the loop, the EU AI Act high-risk obligations do not apply. repowise is self-hosted, so your source code never leaves your infrastructure.
- No AI or ML model in the scanning or scoring path
- Same inputs produce the same findings, every time
- EU AI Act high-risk obligations do not apply
- Self-hosted: raw source is processed transiently and never persisted
From index to triaged findings in four steps.
Index
repowise builds the dependency graph, git history, and code-health layers from your repo, inside your infrastructure.
Map
Manifests are parsed and the dependency graph is resolved, so repowise knows which packages your code actually reaches.
Triage
CVEs are scored with KEV and EPSS, secrets are detected across full git history, and findings are ranked by reachability.
Report
Generate a CycloneDX SBOM, diff it across versions, and pull the security surface into reviews and the audit trail.
Whatever the security task, the graph already knows.
Prioritize the CVEs that matter
Usage-aware triage scores with KEV and EPSS and filters to the vulnerabilities your code actually reaches through the dependency graph.
Find secrets in history
Secret detection scans your full git history, catching keys and tokens that were committed and later deleted, not just what is on HEAD.
Generate an SBOM for procurement
Produce a CycloneDX software bill of materials and diff it between versions to answer audit and procurement questions.
Prove reachability to auditors
Show that findings are scored against the real dependency graph, so the list you act on reflects code you actually run.
Self-host in your perimeter
Run the whole platform inside your network. Source is processed transiently and never persisted, with BYO key or fully offline via Ollama.
Deterministic, reproducible scans
No model in the scanning path means the same inputs produce the same findings every time, so results are auditable and repeatable.
Generic scanners rank by CVSS and bury you in findings for code you never execute. repowise scores by what you actually reach through the dependency graph, so the list you get is the list worth acting on. Function-level reachability triage and compliance reporting such as PCI-DSS and SOC 2 are on the roadmap.
Questions, answered
Does repowise scan code I do not actually call?
It deprioritizes it. repowise runs CVE-aware dependency analysis scored with KEV and EPSS, then uses usage-aware triage to surface the vulnerabilities your code actually reaches through the dependency graph. The list you get is the list worth acting on, instead of every CVE in every transitive package. Function-level reachability triage, which narrows this further to the exact call paths, is on the roadmap.
Where does my code go, and can we self-host?
repowise is self-hosted. The core engine runs inside your infrastructure and your source code never leaves it. Raw source is processed transiently and never persisted: what is stored is the dependency graph, non-reversible embedding vectors, generated wiki pages, and git metadata. You can bring your own API key for wiki generation or run fully offline with a local model via Ollama, so there is no external call at all.
What about secrets already committed to history?
Secret detection runs across your full git history, not just the current working tree. A key or token that was committed and later deleted is still in the history and still a live exposure, so repowise scans the whole history rather than only HEAD. This is generally available on the hosted platform.
Do you generate an SBOM?
Yes. repowise generates a CycloneDX software bill of materials and can diff SBOMs between versions, which is useful for audits and procurement reviews. SBOM generation and diffs are generally available on the hosted platform.
Is there an AI model in the scanning path?
No. The scanning and scoring path is deterministic, with no model in the loop. The same inputs produce the same findings every time, so scans are reproducible and auditable. Because there is no AI or ML model making security decisions, the EU AI Act high-risk obligations do not apply. An LLM is used only to generate the documentation wiki, never to score vulnerabilities.
What compliance reports are available?
An audit trail for the security surface is generally available on the hosted platform on Teams and above. SBOM (CycloneDX) generation and diffs are also generally available and serve procurement and audit needs today. Dedicated compliance reporting such as PCI-DSS and SOC 2 templates is on the roadmap, so we mark it as planned rather than presenting it as shipped.
How is this different from a standard SCA or dependency scanner?
A generic scanner ranks by CVSS and returns a flat list, so you get findings for code you never execute. repowise scores against your actual dependency graph, so vulnerabilities you genuinely reach are surfaced ahead of ones buried in unused transitive packages. It is built on the same graph, git history, and code-health layers that power the rest of repowise, not a bolt-on scanner. Graph-aware enhanced scanning and language-specific security rulesets are in active development.
Can security signals show up during code review?
Yes. get_risk surfaces security signals alongside hotspots, dependents, and co-change partners, and in pull-request mode it returns a directive block so reviewers see what a change touches. The Repowise PR Bot posts deterministic comments with zero LLM calls, so there is no prompt-injection surface and the same pull request always gets the same comment.