Security

FerroSCA

Rust-native SBOM / SCA & vulnerability-management server

Sub-second boot, <256 MB RAM AWS service it replaces: OWASP Dependency-Track

A Rust-native SBOM / SCA and vulnerability-management server. It ingests CycloneDX and SPDX SBOMs, scores findings with CVSS and EPSS, and serves results over a REST API. It runs as a single Rust process — no JVM, no separate front-end tier, no separate worker tier — boots in under a second, and embeds its dashboard in the same binary. Hardened Amazon Linux 2023 AMI (arm64 / Graviton).

FerroSCA ingests CycloneDX 1.4 / 1.5 / 1.6 (JSON and XML) and SPDX 2.2 / 2.3 SBOMs, correlates the components against public vulnerability data (NVD JSON 2.0, OSV, public advisory feeds, and the CISA KEV catalogue), scores findings with CVSS v2 / v3 / v4 and EPSS, evaluates policy, and exposes results over a REST API. It supports Package URL 0.6 and CPE 2.3 identifiers, distro-aware matching for Alpine / Debian / Ubuntu base images, a policy engine with 30+ conditions, and SPDX license detection. Notifications go over Email and Webhook. Authentication is local-user (SHA3-256 API keys), OIDC, and LDAP (gated), with TLS via rustls and project-level ACL on mutations. The API is a FerroSCA-native REST API (standard) plus an opt-in Dependency-Track REST API v1 wire-compatible edition (dtrack-compat) for migration. Honest scope: the Dependency-Track API is 100% path coverage but about 69% deep-schema (presence symmetry, not field-level fidelity) — never marketed as 100% wire-compatible or drop-in; MySQL is excluded, and the supported Marketplace topology is single-node. Engineering: #![forbid(unsafe_code)] in every crate, clippy clean at -D warnings, no unwrap() in production code, a cargo deny gate, a CycloneDX SBOM + self-VDR in CI, and fuzz-tested parsers.

The problem

Software supply-chain security needs a server that ingests SBOMs (CycloneDX / SPDX), correlates dependency components against public vulnerability data, scores them with CVSS and EPSS, and keeps watching them under policy. A typical SCA / vulnerability-management server tends to be a multi-tier stack — JVM, a separate front-end, separate workers, an external database — which is operationally heavy. The need is a lean SBOM / SCA server that is also easy to migrate to.

How it works

1
Ingests SBOMs and scores them

FerroSCA ingests CycloneDX 1.4 / 1.5 / 1.6 (JSON / XML) and SPDX 2.2 / 2.3 SBOMs, correlates components against NVD JSON 2.0, OSV, public advisory feeds, and CISA KEV, and scores findings with CVSS v2 / v3 / v4 and EPSS. It supports Package URL 0.6 and CPE 2.3 identifiers and distro-aware matching for Alpine / Debian / Ubuntu.
2
Serves from one process

Results are served over a REST API and the dashboard is embedded in the same binary. It runs as a single Rust process — no JVM, no separate front-end tier, no separate worker tier — boots in under a second, and idles under about 256 MB of RAM. It includes a policy engine with 30+ conditions and SPDX license detection.
3
Native API + a DT-compatible edition

By default it serves a FerroSCA-native REST API, and for migration you can opt into a Dependency-Track REST API v1 wire-compatible edition (dtrack-compat). Authentication is local-user (SHA3-256 API keys), OIDC, and LDAP (gated); TLS via rustls; project-level ACL on mutations; notifications over Email and Webhook.

Highlights

SBOM ingest (CycloneDX 1.4–1.6 JSON / XML, SPDX 2.2 / 2.3) plus vulnerability intelligence (NVD, OSV, public advisories, CISA KEV) scored with CVSS v2 / v3 / v4 + EPSS.

A single Rust process — no JVM, no separate front-end or worker tier; sub-second boot, idles under 256 MB RAM, with the dashboard embedded in the binary.

FerroSCA-native REST API by default, plus an opt-in Dependency-Track REST API v1 wire-compatible edition for migration. Honest scope: DT API is path-compatible (~69% deep-schema), single-node, MySQL excluded.

What's included

Hardened Amazon Linux 2023 AMI (arm64 / Graviton, runs on t4g / c7g / m7g / r7g class)
A single Rust binary implementing the SBOM / SCA and vulnerability-management server (no JVM, no separate front-end/worker tier, sub-second boot, under 256 MB RAM, dashboard embedded)
SBOM ingest: CycloneDX 1.4 / 1.5 / 1.6 (JSON / XML) + SPDX 2.2 / 2.3, with export to CycloneDX, SPDX, VDR, and VEX
Vulnerability intelligence: NVD JSON 2.0, OSV, public advisory feeds, and CISA KEV, with EPSS enrichment, CSAF 2.0 / VEX 1.4 consumption, and air-gapped mirror import
CVSS v2 / v3 / v4 + EPSS scoring, Package URL 0.6 / CPE 2.3, distro-aware matching for Alpine / Debian / Ubuntu, and a policy engine with 30+ conditions plus SPDX license detection
A FerroSCA-native REST API (default) plus an opt-in Dependency-Track REST API v1 wire-compatible edition, Email / Webhook notifications, local-user (SHA3-256 API keys) / OIDC / LDAP auth, rustls TLS, and project-level ACL
No separate control plane, no telemetry home-call, and no license-key check (billed per instance per hour through your AWS bill)

Use cases

Ingesting SBOMs (CycloneDX / SPDX) produced in CI/CD and continuously monitoring dependency components for vulnerabilities

Teams that want a lean single-binary SBOM / SCA server on their own EC2 instead of a JVM-based multi-tier stack

Migrating from Dependency-Track via the REST API v1 wire-compatible edition

Running a vulnerability-management server entirely inside your own VPC, with no separate control plane and no telemetry home-call

FAQ

Which SBOM formats are supported?

Ingest supports CycloneDX 1.4 / 1.5 / 1.6 (JSON and XML) and SPDX 2.2 / 2.3, with export to CycloneDX, SPDX, VDR, and VEX. It offers streaming upload, a memory ceiling, and token-based async processing.

Where does the vulnerability data come from?

From NVD JSON 2.0, OSV, public advisory feeds, and the CISA KEV catalogue, enriched with EPSS. It also consumes CSAF 2.0 / VEX 1.4 and supports air-gapped mirror import.

Is it compatible with Dependency-Track?

The default is the FerroSCA-native REST API. For migration you can opt into a Dependency-Track REST API v1 wire-compatible edition (dtrack-compat). In honest terms, though, the Dependency-Track API is 100% path coverage but about 69% deep-schema (presence symmetry, not field-level fidelity) — it is never marketed as 100% wire-compatible or drop-in, and MySQL is excluded.

Is this a replacement for an AWS service?

FerroSCA sits in the open-source SBOM / SCA and vulnerability-management space and is not positioned as a replacement for any specific AWS service. It is a self-managed server that runs on your own Amazon EC2 instances, shipping as a normal Amazon Linux 2023 AMI (arm64 / Graviton) that you run inside your own VPC.

What about topology and security posture?

The supported Marketplace topology is single-node. Authentication is local-user (SHA3-256 API keys), OIDC, and LDAP (gated); TLS via rustls; project-level ACL on mutations. On engineering: #![forbid(unsafe_code)] in every crate, clippy clean at -D warnings, no unwrap() in production code, a cargo deny gate, a CycloneDX SBOM + self-VDR in CI, and fuzz-tested parsers.