Asset inventory audit

The /inventaires screen — Debug → Inventories — lists every run of an asset connector, across all communities, and opens each one on what it built and posted: every item, in send order, the very items the Sekoia endpoint received. It is to the OCSF assets what Dispatches is to the logs.

A community's Assets tab shows its last 20 runs. Each row carries an Audit link, and All the runs of this community, in Debug → Inventories opens this screen filtered on it.

Kept, not rebuilt

The audit shows what left, not what would leave. Each run records the items it built and posted — OCSF items for a connector, {agentId, body} requests for the Sekoia Agent's compliance and software inventory — at the moment it ends. Rebuilding them afterwards would describe the past with today's settings: an NVD refresh, or a population or an archetype edited since the run, would change the result, and the audit would contradict what Sekoia received.

Nothing secret is kept. The community's API key travels in the Authorization header, the Sekoia Agent's intake key in the header of its requests; neither is part of an item.

Every item, without a cap. An audit that stopped at the first hundred items would let a missing device pass for one that never left. A software inventory weighs a few megabytes per community and per day; the retention depth is what bounds it.

Kept for 24 hours

The items of a run are kept 24 hours after it ends — the contract of the messages of /envois, applied the same way:

• the threshold is applied when reading: an item past its 24 hours is never shown, even if the clean-up has not run;
• the clean-up only reclaims space — it empties the items and keeps the run: its status, its counts and its reason stay in the record.

With the daily inventory, the day's run stays auditable until the next one, as long as the community runs. The depth counts from the end of the run, not its start: a run is recorded as soon as it is queued, and one that waited in the queue would otherwise see its items born expired.

The run's build report — what the construction left aside — is kept with the run, without a depth: it explains the counts.

The list

Column	What it says
Community	The community the run belongs to — a link to its Assets tab
Format	The connector, its category, and whether the run was daily or manual
Day	The community's local day
Status	Queued, Sending, Sent, Failed or Skipped — and why, when it fails
Items sent	Accepted out of built
Requests	Grouped hosts for software (ten for a new connector), batches of 1,000 for the others, one per device for the Sekoia Agent
Finished	When it ended, with the HTTP status and the duration — while it sends, when it started

The filters — Community, Format, Status — and the page live in the URL: the screen can be shared, going back works, and everything works without JavaScript. The page updates itself on every run of every community — and while a run sends, as it progresses.

A run

Audit opens three cards — four when Sekoia refused batches:

• Run: its status and reason, the items accepted out of built, the requests, the Spacing it played between two of them — the community's agent delay for the Sekoia Agent, a dash for a run that sent nothing —, for a software inventory the Hosts per request it grouped, when it ended. Items are placed in their batches by that grouping, the one the run played, never by today's setting;
• Refused batches: every batch Sekoia did not accept, in send order — its rank, the hosts it carried for a software inventory, its item count. Each host leads to its items, by a search on its agent identifier, which appears in that host's items only; a batch of 1,000 leads to the page where it starts;
• What the build left aside: the same named lists as the preview — entities without a usable identity, systems with no known product, entities without an archetype, unclassified binaries, non-Windows hosts. Absent when the run abstained before building anything;
• Items: the kept items, fifty per page.

Each item unfolds on its JSON as it left. Its summary line gives:

• its position in the send;
• the batch that carried it — a request for the Sekoia Agent;
• what it names: a device's hostname, a user's address, a vulnerability's CVE and hostname, a software item's application and hostname, a Sekoia Agent request's host and agent;
• its outcome, deduced from the run:

Outcome	What it means
Accepted	The run was sent, or Sekoia accepted the item's batch
Batch not accepted	Sekoia refused the item's batch — or the batch stopped the run, network included
Not sent	After a stop: it never left
Outcome unknown	A failed run recorded before refused batches were kept: nothing is guessed

A batch refused for its own content does not stop the run. Items Sekoia rejects, or a batch too large, say nothing about the next batch: the batches after it still leave, and the run keeps the rank of every refused batch. What holds for every batch stops it — a refused key, an unknown connector, a wrong endpoint, an API that stays unavailable —, and the batches after the stop never left. The Sekoia Agent's sends stop only on a refused key.

Search the items looks through the whole item, case-insensitive: a hostname, a UUID, a CVE, a path. A Windows path is typed with single backslashes, as it reads — not as JSON escapes it. A search never renumbers: an item keeps its position, hence its batch.

Download the JSON returns every kept item of the run, in send order — to check against the model Sekoia validates with, or against yesterday's inventory. An expired run, or one that kept nothing, answers with a message rather than an empty file, which would pass for an empty inventory.

Above the items, one sentence says what is left:

Sentence	When
Items kept: n, in send order.	The run ended less than 24 hours ago
These items are no longer kept: …	It ended more than 24 hours ago
This run kept nothing: …	It abstained, failed before building, is still running, or predates the audit

What this does not do

• A run from before this screen, or an expired one, has nothing to show: nothing is rebuilt.
• The items leave with their community: deleting a community deletes its runs, as before.
• The preview does not change: it still shows what the next run would send, three items at most.