Skip to content

Dashboard tour

The alloy-it dashboard is where product security, compliance, and engineering work happens. This page walks through every area. For the workflows themselves, follow the links out to the task guides.

Signing in

  1. Go to alloy-it.io and click Login, or go to the dashboard directly.
  2. Authenticate.
  3. You land on the Overview.

Community users can register themselves; enterprise users are added by their organisation administrator.

The mental model: products and releases

Everything centres on products (what you place on the market) and releases (the firmware versions you shipped). Impact, triage, investigation, remediation, Article 14, and advisories all answer: which product, which release?

Field fleet and installed-device inventory, and ERP sync, are not in the platform. Disclosure targets are advisory recipients and alert emails, not a registry of serial numbers in the field.

→ Products and releases

Group Pages
Overview /
Products Products, All releases, Unlinked uploads
Work Triage, Reporting, Advisories, Evidence
Build environments Explore blueprints, My blueprints, Create a blueprint, Build security, Collaborations
Settings Profile, Email, Registry access, Plan & billing, Organization profile, Members, Usage & storage, PSIRT alerts, Integrations
Help Getting started, CRA checklist, Build environments, Documentation

Press ⌘K (Ctrl+K) anywhere for the command palette. It jumps to pages and searches CVEs, products, releases, and blueprints.

Overview (/)

Tier-aware. Compliance-tier organisations (Team and Enterprise) see engineering posture: findings by severity, triage queue depth, advisories, and actively exploited incidents. Community and Builder tiers get a build-environment view instead.

Treat Overview as an attention queue, not a report. What it surfaces should be something you act on today.

Products

/products: the product list

One product per thing you place on the market: name, SKU, CRA risk class (default, important_i, important_ii, critical), and a support end date.

The risk class determines the conformity assessment pathway on the Conformity tab.

/products/releases: all releases

Every release across every product, with inventory and finding status.

/products/inbox: unlinked uploads

Firmware binaries and SBOMs uploaded but not yet attached to a release. Link them here.

/products/:productId: the product workspace

Tab Contents
Overview Release list and posture summary
Triage This product's triage queue
Advisories Advisories issued for this product
Reporting Exploit incidents affecting this product
Conformity The Annex VII documentation checklist

Release detail

  • Inventory: components from the vendor SBOM and, separately, from firmware analysis.
  • Findings: CVEs with severity, KEV flag, and which source matched them.
  • Compare: vendor SBOM against the firmware-derived inventory, when both exist.
  • Unified inventory: one merged list with source badges and findings deduplicated across sources. Presentation only; the stored inventories stay separate.
  • Artifacts: the firmware image and the analysis report as downloads.
  • Process: triage, advisory, and provenance sub-states in one place.
  • Provenance: which blueprint built this release, and at which verification tier.

Uploading a vendor SBOM. CycloneDX or SPDX JSON. Scanning starts on ingest. → Uploading SBOMs

Uploading firmware. A release can hold several binaries (bootloader, kernel, root filesystem), each tagged with a role and analysed independently. Before you analyse, the page tells you what to expect from the detected format. → Firmware analysis

Analysis is never automatic

Completing an upload does not open the file. A derived SBOM is created only when you click Generate SBOM from firmware.

Where the optional deep-analysis profile is deployed, a Deep analysis action runs an EMBA-class scan (hardening, kernel configuration, version strings), taking tens of minutes to hours.

Triage (/triage)

The queue is organised by component, not by CVE row. For each component you record affected, not affected, or false positive, with a justification. Decisions persist across rescans and can be carried forward to a new release, with a preview of what would carry. VEX documents can be imported to seed decisions.

→ Triage

Reporting (/reporting)

Exploit incidents and CRA Article 14 filing. KEV and EUVD data is overlaid on your product inventory; a match opens an incident and stamps first awareness; 24h / 72h / 14d clocks run from there; the workspace builds the three SRP payloads for you to copy into ENISA or your national CSIRT.

alloy-it does not submit anything.

→ Reporting (Article 14)

Advisories (/advisories)

Customer-facing notification. Draft from findings, prefill from release data, write the structured document sections, publish to your public portal at /o/:orgSlug/advisories, export CSAF or PDF, and notify configured recipients.

Customer notification is gated on a recommended version (or an explicit delayed-inform) and at least one exploitable triaged finding.

→ Advisories

Evidence (/evidence)

The org-wide audit log: uploads, scans, triage decisions, awareness timestamps, who acted and when. From a release you can generate an evidence pack and download it as one document set.

→ Evidence packs

Build environments (/build-env)

The reproduce leg of the loop.

Page Contents
Explore blueprints Public and community blueprints, searchable by name, project, or repository
My blueprints Your organisation's private repositories
Create a blueprint Publish a new build environment
Build security CVE scans of blueprints and toolchains, with component drill-down
Collaborations Blueprints shared with you

Pulling a blueprint

alloy-provisioner install community/raspberry-pi/raspberry-pi-5:1.0.3
alloy-provisioner install community/nordic/nrf91:1.1.3

The exact command is shown on each blueprint's detail page.

In CI, reference blueprints by digest

A tag is a moving target and cannot support a reproduction claim. Pin the digest.

Registry access with ORAS

Settings → Registry access shows your CLI secret, with a show/hide toggle and a copy button:

oras login <registry-url> -u <username> -p <cli-secret>
oras repo list
oras repo tags <project>/<repository>

→ Build environments · Installing

Settings

Section What it holds
Profile Username, user ID, tier, groups
Email Email address
Registry access Registry CLI secret, generate and rotate, recent activity
Plan & billing Current plan and upgrade
Organization profile Organisation details and the logo used on the public advisory page
Members Organisation members, invitations, invitation links
Usage & storage Seats, storage, and compute against your plan
PSIRT alerts Alert email recipients, reporter identity for Article 14 filings, advisory ID scheme, public advisories toggle
Integrations CI/CD integration tokens and pipeline snippets for release ingest

Fill in PSIRT alerts before you need them

The reporter identity is what makes an SRP payload usable, and nobody wants to be filling in a contact phone number inside a 24-hour window.

→ Reporting: reporter identity

Help (/help)

Four tabs: Getting started, CRA checklist, Build environments, and Documentation (which links here). The CRA checklist is guidance, not a compliance score.

Keyboard shortcuts

Shortcut Action
⌘K / Ctrl+K Command palette
Esc Close modal or dropdown

Browsers

Latest Chrome, Edge, Firefox, and Safari. The dashboard is responsive, but triage and release detail are built for desktop.