| [scintx-dev] Welcome to the Eclipse Supply Chain Gateway project |
Hello everyone,
Welcome to scintx-dev, the development mailing list for the Eclipse Supply Chain Gateway project (SCINTX).
This is the primary channel for SCINTX project discussion: architecture and design decisions, specification feedback, roadmap planning, and day-to-day development. Like all Eclipse mailing lists, it has a public, searchable archive [1], so decisions about the project happen here, in the open.
Security information about open-source artifacts is fragmented: vulnerability data, malware reports, and license findings each live in different silos, in different formats, behind different APIs. Registries and pipelines that want to screen artifacts before those artifacts reach developers end up building one bespoke integration per vendor, over and over.
SCINTX (Supply Chain INTelligence eXchange) is a vendor-neutral standard, plus an open-source reference implementation, for a supply-chain security gateway: a service that accepts a submission describing an artifact, routes it to whichever security providers the operator has enabled, normalizes their results into a common findings model and verdict, and applies policy (allow / review / deny / defer) before the artifact reaches a developer machine or a build.
One open contract from "artifact submitted" to "policy decision", so that providers, registries, and consumers can interoperate instead of everyone hand-rolling their own.
The project proposal passed community review in September 2026, and the repository now lives at the Eclipse Foundation:
https://github.com/eclipse-scintx/scintx (EPL-2.0, incubation phase)
The initial contribution includes:
A submission HTTP API (OpenAPI 3.1) with idempotent, resumable jobs
A provider-adapter framework with hash-based capability matching
Result aggregation into a normalized verdict model
A YAML policy engine (allow / review / deny / defer)
CloudEvents-based webhooks
Provider adapters for OSV and Sonatype OSS Index
Coming up on the roadmap: the first tagged release of the reference implementation
Subscribe to this list [3] if you haven't — it is required for committers and open to everyone.
Contributions go through GitHub pull requests [4]; you will need an Eclipse Foundation account and a signed Eclipse Contributor Agreement (ECA) [5]. Issues are tracked in the same repository.
Feel free to introduce yourself! Who you are, and what you would want out of a supply-chain gateway — which registry, pipeline, or provider you would want supported first. Two questions we would specifically like input on:
Which provider capabilities should the v1 specification prioritize (vulnerability, malware, license, provenance)?
Is anyone interested in participating in conformance testing once the harness lands?
I'm Alejandro, the project lead for SCINTX. My background is in security research and developer advocacy within the Web3 ecosystem. I've spent years triaging critical vulnerabilities at the top Web3 bug bounty platform, served on Arbitrum's Security Council, and am a strong advocate for open security practices.
Through this work, I witnessed how security threats increasingly extended beyond smart contracts into software supply chains and operational infrastructure. That shift helped shape the vision for SCINTX: making security knowledge accessible earlier in the development lifecycle, reducing integration overhead, and standardizing how security findings are shared and consumed.
SCINTX began with an initial code contribution from Yeeth Security, but as an Eclipse Foundation project, it is now community-owned and developed in the open.
Best regards, Alejandro Muñoz-McDonald Project Lead, Eclipse Supply Chain Gateway (SCINTX)
[1] https://www.eclipse.org/lists/scintx-dev/
[2] https://accounts.eclipse.org/mailing-list/incubation
[3] https://accounts.eclipse.org/mailing-list/scintx-dev