synapse-ce

Verify Everything. Trust Nothing.

A governed control plane for the whole security-assessment lifecycle, supply chain, code, cloud, offensive, and runtime defense.

Turn a fragmented, manual security process into one controlled, auditable workflow: SCA, SAST, secret and IaC scanning, reachability, recon and governed exploitation, cloud posture, and a distributed blue-team agent fleet, all behind server-side scope enforcement, hardened tool execution, tamper-evident evidence, and deterministic reports.

Landing page · Documentation · Quickstart · Features · Configuration

[!IMPORTANT] Authorized use only. Synapse is built for authorized security testing, pentest engagements, and defensive security work. Every engagement enforces an explicit scope and a legal authorization window, server-side, before any tool runs. You are responsible for holding written permission to test any target.

Why Synapse

• ✅ Deterministic first. Scanning, matching, and reporting are pure, reproducible Go. No model sits in the report path.
• ✅ Evidence you can trust. Every artifact is hash-chained into a tamper-evident custody record. A broken chain blocks the report.
• ✅ One platform, every angle. Supply chain, code, cloud, offensive, and runtime defense behind a single gate.
• ✅ Reachability aware. A deterministic call graph decides whether a vulnerable symbol is actually reachable from your code.
• ✅ Detection independent. Owns its SBOM parsers and advisory matching, and ingests OSV, GHSA, CSAF and OVAL.
• ✅ A detection is evidence, not an alert. Runtime detections are attributable, hash-chained, and joined to the same asset, finding, and attack path the static pillars reason about.
• ✅ CI ready. synapse-cli is a single static binary that gates a build and emits SARIF for code scanning.
• ✅ Safe by construction. argv-only execution in a Linux sandbox, server-side scope and authorization before any tool runs, secrets never leave the server.

What is Synapse

Synapse runs the whole security-assessment lifecycle behind one governed control plane, across both point-in-time analysis (SCA, SAST, code quality, IaC) and runtime analysis (a distributed agent fleet, eBPF detections, response actions), over container and VM estates, with a single asset model, one authorization model, one hash-chained evidence chain, and one prioritized queue.

It is deterministic-first. Scanning, matching, license classification, scoring, and reporting are pure, reproducible Go with nothing else in the path. Where automated analysis is offered it stays strictly bounded: a proposal is only ever proposed, a typed Go state machine validates and executes, scope and authorization are checked in the execution layer, secrets never leave the server, every artifact is hash-chained into a tamper-evident custody record, and a human approves anything intrusive.

Features

Software supply chain

• SBOM generation across many ecosystems (npm, PyPI, Maven, Gradle, Go, Cargo, RubyGems, Composer, NuGet, Hex, Dart, pnpm, Poetry, yarn and more) with owned per-ecosystem lockfile parsers.
• Vulnerability detection from Synapse's own advisory store as the primary source, matched alongside a live advisory API, cross-correlated and de-duplicated; the store ingests OSV, GHSA, CSAF and OVAL for detection independence.
• Risk-based prioritization ordered by exploitability (CISA KEV, then EPSS, then CVSS), never by raw CVSS alone.
• License compliance: declared-license resolution, SPDX expression parsing, a curated category and risk model, and coordinate recovery for shaded or metadata-less JARs.
• Reachability: a deterministic call-graph engine (Go, plus JVM and JS/TS tiers) decides whether a vulnerable symbol is actually reachable from application code.

Code & configuration

• First-party SAST: a line-level pattern scanner for dangerous idioms (weak crypto, hardcoded secrets, a shell built by concatenation, an unsafe deserializer) across many languages, pinned to a labelled precision/recall corpus. Interprocedural and cross-file dataflow analysis is the separate reachability engine: a taint and call-graph analysis over the sandboxed go/ssa and tree-sitter graphs.
• Secret scanning and IaC misconfiguration (Terraform, CloudFormation, ARM, Kubernetes, Helm, Dockerfile, Compose).
• Code quality rules, quality gates and profiles, and third-party SARIF ingest into the same governance path.

Offensive

• Recon in a hardened sandbox, an attack-path graph over the asset inventory, chained exploitation with per-step proof, and adversary emulation with expected-detection output, all gated by a written offensive policy and a kill switch.
• DAST: authenticated crawling and a first-party check corpus with sessions from the credential vault.

Runtime defense (blue team)

• A distributed agent fleet (host and Kubernetes cluster inventory, coverage/freshness, signed packaging and updates) with certificate enrolment and fenced leadership.
• An eBPF detection engine, detections sealed as hash-chained evidence, a columnar telemetry tier with retention, governed response actions (same admission + evidence as exploitation), and purple-team coverage measured from emulation-expected vs actually-fired.

Cloud posture (CSPM)

• Read-only AWS, Azure and GCP posture connectors behind a sandboxed helper, with vault-ref credentials over an inherited FD, per-operation server-side authorization, and IaC-vs-live drift findings.

Governance & evidence

• Tamper-evident evidence: every artifact is hash-chained (RFC-3161 anchored); a broken chain blocks the report. Audit and evidence logs are append-only.
• Hardened execution: tools run via argv arrays inside a Linux sandbox with egress scoping; scope and the authorization window are enforced before any tool runs.
• RBAC, tenant isolation (Postgres RLS), and separation of duties through a single authorization chokepoint.
• The Judgment primitive: every AI/analysis claim is propose → verify → confirm; gated capabilities promote only on a distinct verifier's sealed verdict.

AI analysis (optional, bounded)

• AI false-positive triage grounded in deterministic evidence citations, with provider-independent proposer/verifier separation of duties, budgets, circuit breakers, observability, and a fail-closed adversarial counterfactual gate for model/prompt promotion.
• The agent proposes; a distinct verifier or a human confirms. No model ever sits in the report path.

Standards & reports

• Standards native: CycloneDX and SPDX with PURL, SARIF and OpenVEX exports; CSAF advisory ingestion; KEV and EPSS prioritization.
• Deterministic reports templated from stored data, with a curated CWE → OWASP, PCI and ISO compliance mapping.

See the full walkthrough with screenshots on the documentation site.

How it compares

Detection is at parity with the popular scanners, and sometimes ahead. On one representative real-world repository, Synapse reported 261 unique CVEs to Trivy's 239 (235 in common) and attached a license to 1443 packages to Trivy's 1394. Numbers move with the project, so treat these as illustrative rather than a benchmark claim.

The lasting difference is what sits around the finding:

Quickstart

Prerequisites

• Go 1.26 (pinned in go.mod), Node and pnpm (use pnpm, not npm or yarn).
• No external scanner is required: the owned SBOM producer + owned advisory store are the default and run with no third-party tool. Syft (optional, broadest SBOM coverage / cross-check) and Grype (optional, adds the offline database) are supported extras, make tools installs both, pinned and checksum-verified, into ./bin.
• Docker is optional and is the easiest way to run the full stack.
• The hardened sandbox and live recon need a Linux host. Without them the API still runs (SCA, findings, reports); sandboxed execution fails closed rather than running unsandboxed.

Install a released build

Grab a prebuilt binary from the Releases page (Linux and macOS on amd64/arm64, and Windows on amd64) and verify it against checksums.txt. Each archive bundles the packaged commands.

# Example: linux/amd64
curl -fsSL -o synapse.tar.gz \
  https://github.com/KKloudTarus/synapse-ce/releases/latest/download/synapse-ce_<version>_linux_amd64.tar.gz
tar -xzf synapse.tar.gz synapse-cli
./synapse-cli scan ./path/to/project --fail-on high

Or scan with zero install using the container image (bundles synapse-cli, plus grype for the opt-in OS-package cross-check):

Container images are not published by the current release workflow. Use a release archive or build deploy/Dockerfile locally when a containerized CLI is required.

Gate a repository in CI with the reusable action (see docs/guide/cli.md):

- uses: KKloudTarus/synapse-ce@v1
  with:
    fail-on: high

Run the full stack with Docker

The stack has no default database password and no default API token. That is deliberate: a credential committed to a public repository ends up in a deployment that somebody can reach, so the Compose file fails fast rather than booting with a password an attacker already knows. Generate the values once into deploy/.env.local, which .gitignore already covers:

umask 077
DB_ADMIN_PASSWORD="$(openssl rand -hex 16)"
DB_APP_PASSWORD="$(openssl rand -hex 16)"
BLOB_PASSWORD="$(openssl rand -hex 16)"
cat > deploy/.env.local <<EOF
DB_ADMIN_PASSWORD=$DB_ADMIN_PASSWORD
DB_APP_PASSWORD=$DB_APP_PASSWORD
BLOB_PASSWORD=$BLOB_PASSWORD
SYNAPSE_API_TOKEN=$(openssl rand -hex 32)
SYNAPSE_DB_DSN=postgres://synapse_app:$DB_APP_PASSWORD@postgres:5432/synapse?sslmode=disable
SYNAPSE_DB_MIGRATION_DSN=postgres://synapse_admin:$DB_ADMIN_PASSWORD@postgres:5432/synapse?sslmode=disable
EOF

docker compose --env-file deploy/.env.local \
  -f deploy/docker-compose.full.yml up -d --build --wait

--env-file is required. Compose does not read deploy/.env.local just because the Compose file lives in deploy/. Hex passwords keep the DSNs URL-safe; percent-encode anything else.

curl localhost:8080/readyz                       # {"status":"ready",...}
open http://localhost:5173                       # dashboard

Paste the SYNAPSE_API_TOKEN from deploy/.env.local into the dashboard and accept the Acceptable Use Policy. Two roles exist on purpose: synapse_admin owns the schema and runs migrations, synapse_app serves traffic and cannot bypass row level security. PostgreSQL writes its initial credentials into the volume, so rotating the env file afterwards does not change the stored password; for throwaway local data, reset with docker compose --env-file deploy/.env.local -f deploy/docker-compose.full.yml down -v.

Full details, including the port table and what this profile deliberately does not harden, are in Deployment.

Run natively (development)

make install                       # Go modules + web deps
make tools                         # optional: syft + grype for the opt-in cross-check
export PATH="$PWD/bin:$PATH"

export SYNAPSE_API_TOKEN="$(openssl rand -hex 32)"   # required for operational API routes; /healthz and /readyz are public
make dev                           # API on :8080, dashboard on :5173

Open http://localhost:5173, paste the token, accept the Acceptable Use Policy. A blank SYNAPSE_DB_DSN runs an in-memory dev store, so nothing is persisted. Migrations are embedded and applied automatically at startup.

For a durable local database, start the dependency stack and point the API at it. Its one-shot postgres-init container creates the application role the API connects as.

docker compose -f deploy/docker-compose.yml up -d   # Postgres + MinIO; same as `make docker-up`
# The stack's own defaults; set these in deploy/.env to use anything else.
export DB_PASSWORD="${DB_PASSWORD:-synapse}" DB_APP_PASSWORD="${DB_APP_PASSWORD:-synapse-app}"
export SYNAPSE_DB_DSN="postgres://synapse_app:${DB_APP_PASSWORD}@localhost:5432/synapse?sslmode=disable"
export SYNAPSE_DB_MIGRATION_DSN="postgres://synapse:${DB_PASSWORD}@localhost:5432/synapse?sslmode=disable"
make dev

Both DSNs are needed. synapse owns the schema, migrates it, and grants the runtime role its table privileges; synapse_app is NOSUPERUSER NOBYPASSRLS and is the only role the API will serve under. Connecting as the superuser stops the API at startup with rls: runtime DB role cannot enforce isolation: role is SUPERUSER, because row level security is silently a no-op for such a role. These credentials are throwaway local defaults.

Skip --wait on this stack: Compose counts the exited postgres-init container as not running and reports a failure even when it finished successfully. To block until the role exists, run docker compose -f deploy/docker-compose.yml run --rm postgres-init, which is idempotent.

Command line

synapse-cli runs the same pipeline as the server, ideal for CI gating.

make build
./bin/synapse-cli scan ./path/to/project --fail-on high

The exit code is 0 when no finding meets the threshold, non-zero otherwise.

Binaries

Architecture

Clean architecture with a strict, inward-only dependency rule:

domain  <-  usecase  <-  adapter / infrastructure

All external I/O (database, tools, storage, sandbox) goes through ports, which are interfaces in internal/usecase/ports. cmd/* is the composition root, with dependency injection in main and no business logic.

Configuration

Synapse reads its configuration from the process environment. Copy .env.example and adjust. The only required variable in development is SYNAPSE_API_TOKEN. In production, SYNAPSE_MEASURE_CURSOR_SECRET is also required (generated via openssl rand -hex 32). See the configuration reference for the full list.

Full documentation lives in docs/guide/: introduction, installation, quickstart, features, configuration, CLI, architecture, deployment, and the security model. See CHANGELOG.md for what has changed.

Roadmap

Synapse is under active development. The current roadmap extends the shipped platform rather than introducing new pillars:

• Broader deterministic rule and ecosystem coverage beyond the current Go, JavaScript/TypeScript, Python, Java/JVM, .NET, Rust, Ruby, PHP, Swift, Dart, Elixir, Conda, R, Julia, and Conan coverage.
• Deeper language-aware reachability and taint analysis, with conservative handling for dynamic code.
• More model-free compliance profiles and ready-to-run CI, fleet, and deployment recipes.
• Continued hardening of sandbox, supply-chain, evidence, and agent-update boundaries.

Have a request? Open an issue or start a discussion. Issues tagged good first issue and help wanted are a good place to start.

Team & contributors

Synapse is built by its founding team and contributors.

	Member	Role
	nghiadaulau	Founder
	nnatuan03	Co-founder
	pho-veteran	Lead maintainer
	VietSory	Engineer
	lethanhsang188	Engineer
	tuu-ngo	Brand identity designer
	H1eu232	AI engineer (contributor)
	XUanhoa04	AI engineer (contributor)
	thx2an	AI engineer (contributor)

Contributions are welcome. See CONTRIBUTING.md, the Code of Conduct, and report vulnerabilities per the Security Policy.

License

Licensed under the Apache License 2.0.