synapse-ce - Synapse - a governed control plane for software co

项目说明

<di="center">

<img src="assets/logo-full-black.png#gh-light-mode-only" alt="Synapse" width="380">
<img src="assets/logo-full-white.png#gh-dark-mode-only" alt="Synapse" width="380">

E. Trust Nothing.

**A go 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 go exploitation, cloud posture, and a
distributed blue-team agent fleet, all behind ser scope enforcement, hardened tool
execution, tamper-e e, and deterministic reports.

![Docs]()
![CI]()
![Go Report Card]()

Landing page · Documentation · Quickstart · Features · Configuration

</div>

---

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

<di="center">
<img src="assets/engagements-o.png" alt="Synapse engagements o" width="900">
</div>

Why Synapse

✅ Deterministic first. Scanning, matching, and reporting are pure, reproducible Go. No model sits in the report path.

✅ E you can trust. Every artifact is hash-chained into a tamper-e 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 symbol is actually reachable from your code.

✅ Detection independent. Owns its SBOM parsers and ad matching, and ingests OSV, GHSA, CSAF and OVAL.

✅ A detection is e, 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. arg execution in a Linux sandbox, ser scope and authorization before any tool runs, secrets ne the server.

What is Synapse

Synapse runs the whole security-assessment lifecycle behind one go control plane, across
both point-in-time analysis (SCA, SAST, code quality, IaC) and runtime analysis (a distributed
agent fleet, eBPF detections, response actions), o and , with a single
asset model, one authorization model, one hash-chained e 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 e, a typed Go state machine and
executes, scope and authorization are checked in the execution layer, secrets ne the
server, every artifact is hash-chained into a tamper-e 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.

detection from Synapse's own ad store as the primary source, matched

alongside a li 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 C.

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 symbol is actually reachable from application code.

Code & configuration

First-party SAST: a line-le 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 go path.

Offensive

Recon in a hardened sandbox, an attack-path graph over the asset in, **chained

exploitation with per-step proof, and ad emulation** with expected-detection output,
all gated by a written offensi 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 in, co/freshness,

signed packaging and updates) with certificate enrolment and fenced leadership.

An eBPF detection engine, detections sealed as hash-chained e, a **columnar

telemetry tier with retention, go response actions** (same admission + e as
exploitation), and purple-team co measured from emulation-expected .

Cloud posture (CSPM)

Read-only AWS, Azure and GCP posture connectors behind a sandboxed helper, with

credentials over an inherited FD, per-operation ser authorization, and IaC- drift findings.

Go & e

Tamper-e e: every artifact is hash-chained (RFC-3161 anchored); a broken chain

blocks the report. Audit and e logs are append-only.

Hardened execution: tools run via arg 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 → → confirm; gated

capabilities promote only on a distinct 's sealed .

AI analysis (optional, bounded)

AI false-positi grounded in deterministic e citations, with pro

proposer/ separation of duties, budgets, circuit breakers, obser, and a fail-closed
ad counterfactual gate for model/prompt promotion.

The agent proposes; a distinct or a human confirms. No model ever sits in the report path.

Standards & reports

Standards native: CycloneDX and SPDX with PURL, SARIF and Open; CSAF ad 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 illustrati than a benchmark claim.

The lasting difference is what sits around the finding:

| Capability | Synapse | Most scanners |
| --- | --- | --- |
| SCA, license, IaC misconfig, secret scanning | Yes | Yes |
| First-party SAST (source-code rules) | Yes | Usually no |
| Reachability via a call graph | Yes | Rarely |
| Offensi paths, chained exploitation, emulation, DAST | Yes | No |
| Runtime blue team: agent fleet, eBPF detections, response actions | Yes | No |
| Detections sealed as hash-chained e, joined to the same asset | Yes | No |
| Cloud posture (AWS/Azure/GCP), IaC- drift | Yes | |
| Hash-chained, tamper-e e | Yes | No |
| Ser scope and authorization before a tool runs | Yes | No |
| RBAC, tenant isolation (RLS), separation of duties | Yes | No |
| Deterministic, model-free report path | Yes | |

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 ad store are the default

and run with no third-party tool. Syft (optional, broadest SBOM co / cross-check) and Grype
(optional, adds the offline database) are supported extras, make tools installs both, pinned and
checksum-, into ./bin.

Docker is optional and is the easiest way to run the full stack.

The hardened sandbox and li 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 it against checksums.txt. Each archi
the packaged commands.

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):

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
once into deploy/.en, which .gitignore already covers:

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

Paste the SYNAPSE_API_TOKEN from deploy/.en into the dashboard and accept the
Acceptable Use Policy. Two roles exist on purpose: synapse_admin owns the schema and runs
migrations, synapse_app ser and cannot bypass row le. PostgreSQL writes
its initial credentials into the , so rotating the env file afterwards does not change the
stored password; for throwaway local data, reset with
docker compose --en deploy/.en -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 (de)

Open < paste the token, accept the Acceptable Use Policy. A blank
SYNAPSE_DB_DSN runs an in-memory de, 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.

Both DSNs are needed. synapse owns the schema, migrates it, and grants the runtime role its
table pri; synapse_app is NOSUPERUSER NOBYPASSRLS and is the only role the API will
ser. Connecting as the superuser stops the API at startup with
rls: runtime DB role cannot enforce isolation: role is SUPERUSER, because row le 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.

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

Binaries

| Binary | Role |
| --- | --- |
| synapse-api | HTTP API server, the primary service |
| synapse-cli | Run an SCA/SAST scan from the command line, CI-friendly (SARIF, --fail-on) |
| synapse-worker | Durable job runner for recon and background jobs, lease-based, leader-gated |
| synapse-callgraph | Sandboxed go/ssa call-graph builder for reachability and taint |
| synapse-ast | Sandboxed tree-sitter AST helper for source-code analysis |
| synapse-cspm | Sandboxed cloud-posture helper (AWS/Azure/GCP), read-only, FD-passed credentials |
| synapse-dast-helper | Sandboxed DAST crawler/check helper |
| synapse-agent | Fleet agent: host in and eBPF runtime detections |
| synapse-cluster-agent | Fleet agent: Kubernetes workload/exposure/identity in |
| synapse-fptriage-eval | Offline e harness for AI false-positi |
| synapse-fptriage-compare | Deterministic candidate- gate for AI model/prompt promotion review |
| synapse-fptriage-release | PM/Security-appro and rollback ledger for AI triage |
| synapse-fptriage-curate | Offline privacy- and label-re feedback curation for AI false-positi |
| synapse-fptriage-drift | Offline language/CWE/project distribution drift e for AI triage |
| synapse-mcp | Read-only, propose-only integration server, ne |

Architecture

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

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 en. Copy .en and adjust.
The only required in de 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 acti. The current roadmap extends the shipped platform rather than
introducing new pillars:

Broader deterministic rule and ecosystem co beyond the current Go, Ja/TypeScript,

Python, Java/JVM, .NET, Rust, Ruby, PHP, Swift, Dart, Elixir, Conda, R, Julia, and Conan co.

Deeper language-aware reachability and taint analysis, with conser handling for dynamic code.

More model-free compliance profiles and ready-to-run CI, fleet, and deployment recipes.

Continued hardening of sandbox, supply-chain, e, 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 |
| --- | --- | --- |
| <img src=" width="46" height="46" alt="nghiadaulau"> | nghiadaulau | Founder |
| <img src=" width="46" height="46" alt="nnatuan03"> | nnatuan03 | Co-founder |
| <img src=" width="46" height="46" alt="pho-"> | pho- | Lead maintainer |
| <img src=" width="46" height="46" alt=""> | | Engineer |
| <img src=" width="46" height="46" alt="lethanhsang188"> | lethanhsang188 | Engineer |
| <img src=" width="46" height="46" alt="tuu-ngo"> | tuu-ngo | Brand identity designer |
| <img src=" width="46" height="46" alt="H1eu232"> | H1eu232 | AI engineer (contributor) |
| <img src=" width="46" height="46" alt="XUanhoa04"> | XUanhoa04 | AI engineer (contributor) |
| <img src=" width="46" height="46" alt="thx2an"> | thx2an | AI engineer (contributor) |

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

License

Licensed under the Apache License 2.0.

项目信息

开发语言：Go

Star 数：43

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Synapse - a governed control plane for software composition analysis, recon, evidence, and reporting. Verify Everything. Trust Nothing.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。