We just open-sourced Synapse, a governed control plane for software composition analysis,
recon, evidence, and reporting. It is built for people who have to scan a dependency tree,
prove what they found, and hand over a report that holds up.
- Site: https://synapse.kkloudtarus.net/
- Code: https://github.com/KKloudTarus/synapse-ce (Apache-2.0)
Why we built it
The usual workflow is fragmented. One tool for the SBOM, another for vulnerabilities, a
spreadsheet for licenses, a folder of screenshots for evidence, and a report you assemble by
hand. Nothing is reproducible, and when a client asks "how do you know this is real," the
answer lives in someone's memory. Adding an LLM that writes your findings only makes that
worse. We wanted the opposite: fast, but provable.
What it is
Synapse runs the assessment lifecycle behind one control plane, in Go, clean architecture. A
few ideas hold it together:
- Deterministic-first. Scanning, matching, license classification, and reporting are pure, reproducible Go. There is no model in the report path.
- Scope-gated execution. Every engagement carries a scope and an authorization window, enforced server-side before any tool runs. Tools run via argument arrays, never a shell string.
- Tamper-evident evidence. Every artifact is hash-chained and append-only. A broken chain blocks the report.
- Bounded automation. The optional AI layer only ever proposes. A distinct verifier or a human confirms. The agent can never confirm its own claim.
What it does today: SBOM across 15+ ecosystems, multi-source vulnerability detection with
risk-based prioritization (KEV, then EPSS, then CVSS), license compliance, reachability, and
deterministic reports in CycloneDX, SPDX, SARIF, and OpenVEX.
Try it
git clone https://github.com/KKloudTarus/synapse-ce.git
cd synapse-ce
docker compose -f deploy/docker-compose.full.yml up --build
# open http://localhost:5173
Or gate CI on real risk: ./bin/synapse-cli scan . --fail-on high.
We are looking for contributors
Synapse is open source because this kind of tool gets better with more eyes on it. Good places
to jump in:
- New ecosystems and lockfile parsers
- Detection quality and false-positive reduction
- Reachability and SAST coverage
- Reporting and standards (OpenVEX, CSAF, SARIF)
- The dashboard (Vite, React, Tailwind) and the docs
Start with the documentation
and CONTRIBUTING, run it
locally, then open an issue or send a pull request.
One note: Synapse is for authorized security testing only. It validates scope data but cannot
verify your legal authorization, so use it only against systems you are allowed to test.
If it looks useful, a star helps other people find it, and if you want to build with us, open
an issue and say hello.
Top comments (4)
"The agent can never confirm its own claim" is the line that makes this different from most tools waving the AI flag right now. Keeping the report path fully deterministic and letting the model only propose is the right split, since the part a client challenges ("how do you know this is real") is exactly the part you don't want a model in. One thing I'd love to see spelled out somewhere prominent is what happens to a finding the AI proposes that the verifier can't confirm. Does it drop, or does it land in the report flagged as unconfirmed? That policy is where a lot of the trust actually lives.
Great question, and you put your finger on exactly the right spot.
Short answer: a proposal the verifier cannot confirm does not go into the report, and it is not shown to the client as "unconfirmed" either. It stays inside the system as an unconfirmed finding (evidence score 0, not promoted), visible to the operator so nothing is silently lost and a human can pick it up, verify it by hand, or discard it. The report and the export bundle read only publishable findings through a single gate, so an unconfirmed model claim can never reach the deliverable.
Promotion is explicit: a gated claim becomes publishable only on a distinct verifier's sealed verdict at or above the evidence threshold; ungated ones need a human to accept. The agent is propose-only, so it can never move its own claim past that gate.
Two reasons we don't just print "unconfirmed" in the report: an "unconfirmed" line is itself a claim the client can challenge, which is the thing we are trying to avoid; and keeping the proposal in the operator's queue rather than the deliverable means a human decides, with the evidence chain, before anything reaches the client.
You are right that this deserves to be prominent. I will write it up in the docs. Thanks for the sharp read 🙏 If possible, please contribute, thank you!
thanks for sharing!
Tuỵt zờiiiiiii