Skip to content

How it works

alloy-it is one platform built around one loop of four capabilities. It is not four tools that happen to be sold together: each capability produces what the next one needs, and the fourth feeds back into the first.

flowchart LR
    M["1. MONITOR<br/>product inventory<br/>and continuous scan"]
    N["2. NOTIFY<br/>authorities, and<br/>separately customers"]
    T["3. TRACE BACK<br/>component to release<br/>to build environment"]
    R["4. REPRODUCE<br/>rebuild the toolchain<br/>and ship the fix"]

    M -->|actively exploited| N
    N -->|affected releases| T
    T -->|origin release| R
    R -->|patched release| M

Read it as an incident: monitor detects → notify scopes the affected releases → trace-back finds the origin → reproduce ships the fix → the patched release goes back under monitoring.

Monitor

Standing surveillance of everything that constitutes a shipped product, for the device's entire market life:

  • the vendor's claimed inventory (the SBOM you were given, or produced at build time),
  • the actual artifact (an inventory derived from the firmware binary),
  • and the environment that built it (the blueprint and its toolchain).

Scheduled passes re-query vulnerability intelligence for every stored inventory. New high and critical findings go to your PSIRT inbox, never to your customers. Actively-exploited data from CISA KEV and the EU EUVD is overlaid on the inventory, so a match against something you shipped is what opens an incident.

→ Monitoring · Products and releases

Notify

Two paths, with different triggers, audiences, and clocks. Keeping them apart is the single most important distinction in the product.

Authorities Customers
Trigger A finding is actively exploited in a release you placed on the market Triage confirms the product is exploitable and a fix, mitigation, or documented reason to inform exists
Clock 24 hours, 72 hours, then 14 days, from 11 Sep 2026 Your schedule
Goes to ENISA SRP or your national CSIRT The customers who own the affected product
alloy-it does Stamps awareness, builds the payload for you to copy Drafts the advisory, exports CSAF/PDF, publishes to your portal
alloy-it never Submits it for you Emails anyone before triage concludes

September 2026 is a report to authorities. It is not an obligation to email end customers; that duty sits with vulnerability handling, toward full application in December 2027.

→ Reporting (Article 14) · Advisories

Trace back

From a CVE or a component, walk the chain in either direction:

flowchart LR
    C["CVE / component"] --> R1["releases that<br/>contain it"]
    R1 --> TR["triage decision<br/>per component"]
    TR --> B["the blueprint that<br/>built the binary"]

Which releases carry this component? Which of those did triage actually mark affected? And which build environment produced that binary? The answer has to survive years, because the question usually arrives years after the release shipped.

→ Triage · Evidence packs

Reproduce

Build environments are versioned blueprints, so the exact toolchain that produced an affected release can be reconstructed on demand (the same compiler, SDK, and dependency versions) and used to build and ship the fix.

This is what makes a ten- or fifteen-year support period a plan rather than a hope. A release carries a provenance link to the blueprint that built it, which is the bridge between trace-back and reproduce.

→ Build environments · Installing

How artifacts enter the loop

The dashboard areas are entry points, not separate products. Wherever you start, you land in the same loop.

Entry point What you do Where it goes
Products / SBOMs Upload a vendor CycloneDX or SPDX document per release Inventory → CVE analysis → continuous rescan and alerts
Firmware Upload the shipped binary and, on demand, derive an inventory from it A second inventory to compare against the vendor's, trust-but-verify
Build environments Scan blueprints and toolchains, record provenance The reproduce leg, and CVE hygiene in the build itself

Rules worth knowing up front

These are decisions the platform holds to, and they explain most of its behaviour.

  1. SBOM-only works. Upload just an SBOM and you get monitoring and analysis for it. No firmware required.
  2. Firmware is never opened automatically. Completing an upload does not start analysis. A derived SBOM is created only when you explicitly ask for one. Rescans re-query vulnerability data; they never re-extract a binary.
  3. Dual inventories, compared not merged. A release can carry both a vendor SBOM and a derived one. Both are monitored, and the difference between them is shown as a read-only diff, because the difference is the interesting part.
  4. A release is the unit of record. Impact, triage, reporting, and advisories all answer which product, which release?
  5. Field devices are out of scope. alloy-it tracks what you placed on the market, not a registry of serial numbers installed at customer sites.

Next