For you
Manufacturer
Articles 13 and 14
One platform. One CRA loop.
alloy-it covers the embedded software supply chain end to end: monitor what you shipped, notify authorities when something is actively exploited, trace back to the release and blueprint, and reproduce the fix.
The four capabilities
Wherever you start, you land in the same loop. SBOMs, firmware, and build environments are ways in, not four things to buy.
01
Monitor
Product inventory & continuous scan
Standing surveillance of everything that constitutes a shipped product: the vendor SBOM, the firmware-derived inventory, and the environment that built it, for the device's entire market life.
02
Notify authorities
Article 14 readiness
When a finding is actively exploited in a shipped product, stamp first awareness and prepare the 24h / 72h / 14-day Article 14 packet. Copy JSON into ENISA SRP / national CSIRT. Alloy does not submit and does not auto-email customers.
03
Trace back
Component → release → evidence
From a CVE or component, walk the chain: which releases contain it, and which build environment produced the binary. Audit-ready in both directions.
04
Reproduce
Rebuild & ship the fix
Because build environments are versioned blueprints, the exact toolchain that built an affected release can be reconstructed to build and ship the fix, even years later, on devices with 10 to 15 year support periods.
The loop closes an incident end to end: monitor detects → notify scopes affected releases → trace-back finds origin → reproduce ships the fix. Authority reporting and customer advisories are separate notify paths.
Built for the manufacturer of record
Also for you
Substantial modifier
Treated as a manufacturer
The teams inside that organisation
Not this product
Authorised representatives, importers acting only as importers, distributors, open-source stewards, notified bodies, and authorities are not the buyer.
How artifacts enter the loop
Products / SBOMs
Create products and releases. Upload vendor CycloneDX/SPDX. Continuous rescan and alerts to the PSIRT inbox.
Firmware
Upload the binary (analyze on demand, never automatic). Derive inventory, compare against the vendor SBOM, trust but verify.
Build-env
Blueprints, toolchain scan, and provenance, the reproduce leg when you must rebuild an affected release years later.
Triage decides what is actually in the product
A scanner gives you thousands of findings. What an assessor wants is the decision you made about each one, and why.
alloy-it · GW-4200 Gateway · v2.4.1 · Triage
| CVE | Component | Severity | Exploited | Decision |
|---|---|---|---|---|
| CVE-2026-1337 | zlib 1.2.11 | CRITICAL | KEV | Affected |
| CVE-2026-0455 | openssl 3.0.8 | HIGH | — | Not affected |
| CVE-2025-9902 | busybox 1.35.0 | HIGH | — | Under review |
| CVE-2025-7710 | libcurl 7.88.1 | MEDIUM | — | False positive |
Every decision carries a justification and a history. That log is the evidence, not the scan output.
Trace back, in both directions
From a CVE down to the releases that carry it, and from a release back to the environment that produced the binary.
Registry & provisioner, the rebuild path
When triage confirms an affected release, build provenance points at the blueprint that produced the binary. The open-source provisioner reconstructs that environment so you can ship a patched release back into monitoring, even years into the support period.
See the platform on your products
Book a CRA walkthrough, or start free with a product and your last N SBOMs.