Security
Fix the vulnerabilities you actually reach.
CVE triage on your real dependency graph, secrets found across full history, and an SBOM for the auditor, all on infrastructure you control.
No model in the scanning path. Reproducible, auditable results.

repowise-dev/repowise · the security fix-first queue
At a glance
- KEV + EPSS
- scoring
- Then filtered to the vulnerabilities your code reaches.
- Full history
- secret detection
- Every commit, not only the current checkout.
- CycloneDX
- SBOM
- Generation and diffs between releases, with VEX.
- 0
- LLM calls
- No model in the scanning path. Reproducible and auditable.
Sound familiar?
Four hundred findings. Three that matter.
- 01
The scanner lists CVEs in code we never execute.
- 02
The key we rotated is still in the history.
- 03
Procurement wants an SBOM by Friday.
What makes it different
The short list, and the paperwork.
- Reachable first
Scored with KEV and EPSS, filtered to code you call.
A CVE on a live path ranks above one in a package you import but never run.
- Secrets in history
Every commit, not just the checkout.
A key removed last year is still an exposure. Repowise looks where it went.
- SBOM and VEX
CycloneDX, with diffs between releases.
What changed in your dependency set, in the format auditors ask for.
- Compliance maps
PCI-DSS and SOC 2 coverage from live findings.
Control by control, with evidence drill-ins. Teams tier and above.
In plain words
Not every vulnerable package is a vulnerability you have.
A scanner reports every CVE in every package you install. Repowise carries on into the dependency graph and asks whether your code imports the package, and whether it runs the code that is broken. Most findings fall away. The ones left are the ones to fix.
How to read it
What reachable means
- Reached
- Your code imports the package and runs the vulnerable code. Fix first, especially with a KEV flag.
- Imported, not run
- The package is imported but the vulnerable path is never called. Schedule it.
- Not imported
- Installed, never imported. Upgrade when convenient.
- Dev only
- Only in test or build tooling. Lowest priority.
- Secrets in history
- A key removed from the checkout is still in the history and still live. Rotate it.
How it works
Manifests, graph, score.
- 01 / Read
Parse manifests and lockfiles
Dependencies and versions across every ecosystem the index supports. - 02 / Reach
Trace them through the graph
Which vulnerable packages your code actually calls. - 03 / Score
Rank by exploitability
KEV and EPSS, then reachability, so the list you act on is the list worth acting on.
Where it shows up
Shows up where the work already happens.
Dashboard
Every finding with its score, whether your code reaches it, and secrets and dependencies on the same screen. Nightly CVE refresh without a re-index.
CLI
Export the SBOM, diff it against the last release, and run the full-history secret scan in CI.
Coding agents
An agent that touches a dependency is told which of its vulnerabilities the code actually reaches.
Questions
What people ask before they try it.
Does it scan code I do not actually call?
That is the part most scanners get wrong. repowise scores known vulnerabilities with KEV and EPSS, then filters them against your real dependency graph so the list narrows to the vulnerabilities your code actually reaches. A CVE in a package you import but never execute is not the same as one on a live code path, and the triage reflects that. Usage-aware CVE triage is generally available on the hosted platform. Function-level reachability triage, which narrows further to the exact functions you call, is on the roadmap.
Where does my code go, and can I self-host?
Your code never leaves your infrastructure. repowise is open source under AGPL-3.0 and fully self-hostable, with a managed hosted platform as an option. 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, not your source files.
What about secrets that are already in my history?
Secret detection runs across your full git history, not just the current tree. A key that was committed and later removed is still recoverable from history and still a live exposure, so repowise looks at every commit, not the current checkout alone. Secret detection across full git history is generally available on the hosted platform.
Do you generate an SBOM?
Yes. repowise generates a CycloneDX software bill of materials and produces diffs between versions, so you can see exactly what changed in your dependency set between releases. VEX is supported for communicating which listed vulnerabilities actually affect you. SBOM (CycloneDX) generation and diffs are generally available on the hosted platform.
Is there an AI model in the scanning path?
No. There is no model in the loop in the scanning and scoring path, so results are deterministic, reproducible, and auditable. The same inputs always produce the same findings. Because no AI or ML model sits in the loop, EU AI Act high-risk obligations do not apply to the scanning path.
What compliance reports exist?
PCI-DSS and SOC 2 control-coverage reports are generally available on the Teams tier and above: control-by-control coverage derived from your live findings, with evidence drill-ins and JSON/Markdown export. They are not an audit; they are an honest map of where an assessor will look. repowise also generates a CycloneDX SBOM with version diffs and VEX, and there is an audit trail for the security surface on Teams and above.
How is this different from a generic CVE scanner?
Generic scanners rank findings by CVSS severity and return everything that matches a manifest, including vulnerabilities in code you never execute. repowise scores with KEV and EPSS and then filters to what you actually reach on the dependency graph, so the list you act on is the list worth acting on. The scanning path is deterministic and the whole thing is self-hostable.
Which security capabilities are shipped versus on the roadmap?
Generally available on the hosted platform: CVE-aware dependency analysis with KEV and EPSS, usage-aware CVE triage, secret detection across full git history, SBOM (CycloneDX) generation and diffs, and PCI-DSS / SOC 2 control-coverage reports on Teams and above. In development: graph-aware enhanced scanning and language-specific security rulesets. On the roadmap: function-level reachability triage.
Last reviewed: October 2026
Get started
See the short list on your own dependency graph.
Talk to us about running Repowise security on your infrastructure, or index a public repository free first.