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 security for repowise-dev/repowise: code patterns in source and a fix-first queue with the file and line of each finding.

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.

  1. 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.

  2. Secrets in history

    Every commit, not just the checkout.

    A key removed last year is still an exposure. Repowise looks where it went.

  3. SBOM and VEX

    CycloneDX, with diffs between releases.

    What changed in your dependency set, in the format auditors ask for.

  4. 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.

Most scanners stop at the manifest. Repowise carries on into the graph, so it knows the difference between imported and executed.
  1. 01 / Read

    Parse manifests and lockfiles

    Dependencies and versions across every ecosystem the index supports.
  2. 02 / Reach

    Trace them through the graph

    Which vulnerable packages your code actually calls.
  3. 03 / Score

    Rank by exploitability

    KEV and EPSS, then reachability, so the list you act on is the list worth acting on.

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.