Monitoring¶
An inventory is only useful if it keeps being checked. Monitoring is the standing surveillance of every stored inventory, for the whole market life of the product, which for embedded frequently means a decade.
This is the monitor leg of the loop.
What gets monitored¶
Everything that constitutes a shipped product:
| Inventory | Source |
|---|---|
| Vendor SBOM | uploaded: the CycloneDX or SPDX document for a release |
| Firmware-derived | derived: generated on demand from the shipped binary |
| Build environment | The blueprint and toolchain that produced the binary |
Both product inventories are monitored, independently. A finding records which source matched it, so you can tell whether a CVE came from the vendor's claim or from the binary itself.
What a rescan does, and does not do¶
Does: re-queries vulnerability intelligence for every component in every stored inventory, on a schedule. New CVEs against components you already shipped are found without anyone re-uploading anything.
Does not: re-extract firmware. The components in a shipped binary do not change, so there is nothing to re-derive. Generating a new derived SBOM stays an explicit user action.
That distinction is the reason monitoring can run continuously without ever opening a customer's firmware unprompted.
Actively exploited: KEV and EUVD¶
A background job overlays two feeds onto your product inventory:
| Feed | Source |
|---|---|
| KEV | CISA Known Exploited Vulnerabilities catalogue |
| EUVD | The EU Vulnerability Database |
A CVE being known is ordinary. A CVE being actively exploited *in a component of a release you placed on the market is the trigger for Article 14, and it is what this overlay is for.
When one matches, alloy-it writes an awareness record and opens an exploit incident. That record is immutable and holds the timestamp the Article 14 clock runs from.
Alerts¶
New high and critical findings are emailed to the addresses in Settings → PSIRT alerts.
This is your internal awareness path. Nothing here reaches a customer. Customer notification is a separate, later, deliberately gated action.
Configure alerts before you need them
An alert list nobody set up is a monitoring system nobody is watching. Set the recipients when you create your first product, not after the first incident.
Reading the output¶
Monitoring produces findings, not decisions. A single firmware image can yield thousands of findings across a few dozen components, and most of them will not affect your product.
The queue is deliberately organised by component rather than by CVE row, because that is the only shape in which the work is finishable. What turns findings into something an assessor can read is triage.
Next¶
- Triage: decide what is actually in the product
- Reporting: when something exploited hits a shipped release
- Evidence packs: exporting what monitoring recorded