Asset & Inventory keeps a current record of every machine SITEY can see: what operating system it runs, what software is installed, which services are running, which ports it is listening on, what patch state it is in, and what changed since the last collection. Triage, remediation, patching and reachability checks all read from this record, so the quality of your inventory sets the ceiling for the quality of every decision that follows.
The problem
Most vulnerability programs do not fail at the scanning step. They fail at the step before it. The asset list lives in a spreadsheet that was accurate at the time of the last audit. Nobody is certain which of the 40 Windows servers still has the old Java runtime, which machines have Defender real-time protection switched off, or whether the emergency patch that was applied last Tuesday actually landed. When a critical CVE is published, the first two days are spent answering “are we even affected?” by hand: logging into hosts one at a time, running wmic or dpkg -l, and pasting the results into a chat thread.
The same gap makes automation unsafe. An AI-generated remediation script is only as good as its assumptions about the target: write a PowerShell cmdlet that does not exist on Windows Server 2008 R2, or restart apache2 on a host that runs httpd, and the fix fails, or worse, half-succeeds.
Without a current inventory, nobody can tell the difference between “the patch worked” and “the scanner did not see it this time.”
How it works
- The endpoint agent collects a bounded, low-noise snapshot
The Windows and Linux agents run a purpose-built inventory collector. On Windows it reads the 64-bit and 32-bit uninstall registry keys, queries winget, Chocolatey and Scoop when they are present, lists installed hotfix KBs, evaluates pending-reboot indicators, enumerates running services with their binary path and start account, lists LISTEN sockets, and reads posture signals: Defender status, firewall profile defaults, and whether RDP is enabled. It also collects .NET Framework, Visual C++ redistributable and Java versions, plus the machine’s Windows Update policy (WSUS/WUfB). On Linux it collects dpkg or rpm package lists, available updates, the running kernel, systemd service state, listening sockets with PID and process name, firewall, mandatory-access-control and fail2ban posture, and, on Linux hosts only, disk, memory, CPU and uptime metrics.
The collector is deliberately conservative. It performs no network sweeps, no LDAP or domain-controller queries, and no credential dumping. Every external command runs under a strict timeout, result sets are capped, and collection is throttled: once per 24 hours by default, adjustable through an agent-side environment variable. The goal is a snapshot that is useful for CVE correlation while keeping the collector’s footprint small on the endpoint.
- The backend accepts a snapshot only from the machine that owns it
Each agent authenticates its inventory upload with a secret that is unique to that agent and stored server-side as a PBKDF2-SHA256 hash. A shared installer secret is explicitly not accepted. This matters because snapshots are not read-only decoration: the autonomous patching engine, the AI remediation path and the assistant all treat the latest snapshot as a decision input. Allowing one host to write inventory under another host’s identity would be a route to controlling the fleet, so it is closed at the API.
- Network discovery covers what has no agent
Hosts you cannot or will not install an agent on are picked up by nmap discovery against your configured VLANs and subnets. Discovery runs on a recurring interval, hourly by default, can be switched off, and can also be run on demand. Each discovered host is persisted with its IP, hostname, MAC and vendor where nmap reports one, OS fingerprint, open ports and matched subnet, and is classified by heuristic into windows, linux, switch, camera or other, with camera and network-device signatures evaluated before the generic OS guess, so a Linux-kernel IP camera is not filed as a server.
- Everything lands in one asset view
The ASM dashboard merges three sources into a single table: registered agents, structured asset records (with their ports, services and subdomains), and discovered hosts. Rows are matched to findings by IP address, so a host shows the severity breakdown, critical, high, medium, low and informational, of the active findings recorded against its address. The inventory and the risk picture are the same screen rather than two exports you reconcile by hand. The full per-host detail, software, services, ports, updates, posture, runtimes and update policy, lives on that host’s own agent page.
- Snapshots are compared, so change is visible
Snapshots are append-only and timestamped: each collection writes a new row instead of overwriting the previous one, so history accumulates and retention is bounded by your own database housekeeping. Any two snapshots can be compared, including automatically around a specific patch job. The diff reports added and removed packages, added and removed hotfix KBs, newly opened and newly closed listening ports, services whose state changed, and posture flags that flipped, with a compact summary line for the timeline and the full item list underneath.
What you can do
For any agent-based host: the Windows uninstall registry plus package managers, or the Linux dpkg/rpm package set.
Installed Windows hotfix KBs and pending-reboot indicators, or available Linux updates and the running kernel.
Running services with binary path and start account, and listening sockets with the owning process.
Antivirus and real-time protection, firewall profiles and default actions, RDP exposure, SELinux/AppArmor and fail2ban.
.NET Framework, Visual C++ redistributable and Java versions, plus each machine’s Windows Update policy.
Disk, memory, CPU and uptime, read directly from Linux hosts.
Diff two snapshots, or diff automatically around a patch job, to see exactly what a change did to a host.
Browse it per host to answer “when did this package appear?”
Per-asset counts by severity, shown next to the asset itself.
MAC, vendor, OS guess, open ports, VLAN and device type.
Criticality (normal, high, critical), environment (test, staging, prod, defaulting to prod so an untagged machine is never treated as disposable), and an explicit exemption from autonomous action with a recorded reason.
Push records in over the API, including their ports, services and subdomains, to feed the inventory from an external source. SITEY does not enumerate subdomains itself, so that data has to come from your own tooling.
Who it is for
Need to answer exposure questions in minutes rather than days.
Want a single honest view of what is actually installed across Windows and Linux fleets.
Tired of reconciling a scanner’s host list against a CMDB that nobody updates.
Need to report coverage: how many hosts are instrumented, how many are only visible through discovery.
An accurate, dated asset register is the starting point for the evidence almost every framework asks for.
Why it matters
Fresh inventory is what makes the rest of the platform safe to automate. Before a patch runs, a preflight check grades inventory freshness: a snapshot under 24 hours old passes, 24 to 72 hours raises a warning, and older or missing data raises a warning that says the decision is resting on stale input. When a remediation plan is generated, the host’s real installed software, running services, listening ports and posture are handed to the model as context, and an OS capability profile derived from the snapshot constrains what the generated script is allowed to assume. Which is the difference between a script that runs and a script that throws on an unsupported cmdlet.
It is a visible flag rather than a hard stop, so the operator decides.
The commercial value is the time you stop spending. “Which hosts have this package?” becomes a query instead of a two-day fire drill. “Did the patch land?” becomes a diff that shows the KB appearing, the service returning to Running and the port closing, rather than a retest you have to schedule and then interpret. And criticality and environment tags give you a hard boundary: the machines you have marked critical or production can be held back from autonomous action while the rest of the fleet moves at full speed.
Works with
- Agent Management, deploying, authenticating and monitoring the endpoint agents that produce inventory snapshots
- Attack Surface Management, the unified asset view, network discovery and exposure mapping built on this data
- Patch Management, preflight freshness gates and before/after inventory diffs around each patch job
- AI Remediation, host-specific context and OS capability constraints that keep generated fixes executable
Frequently asked questions
Does the agent scan my network or query Active Directory?
No. The inventory collector is deliberately limited to the local machine: registry and package database, local services, local listening sockets and local posture settings. It performs no network scanning, no LDAP or domain-controller queries and no secret extraction. Network-level discovery is a separate capability that runs from the server against the subnets you have configured, and it can be turned off.
How often does collection run, and will it disturb the endpoint?
By default, once every 24 hours per host. The interval is set through an agent-side environment variable rather than from the web interface. Each underlying command runs with a short timeout and the collector caps how many items it returns, so a machine with thousands of packages does not turn collection into a long-running job. The design brief for the collector is explicit about staying quiet: no network sweeps, no directory queries, no credential access.
Could someone forge inventory for a machine they do not control?
Inventory writes are accepted only from an agent that proves the secret belonging to its own identifier, verified against a PBKDF2-SHA256 hash held by the server. A shared installation secret is rejected. An older agent without its own secret is refused with an error rather than silently accepted, so the failure is visible instead of quietly poisoning the data the automation depends on.
What do I get for hosts where I cannot install an agent?
You get a discovered-host record: IP, hostname, MAC and vendor, OS fingerprint, open ports, matched VLAN and a device-type classification, refreshed on each discovery run and shown in the same asset table as agent-backed hosts. It is genuinely shallower, there is no installed-software or patch-state data without an agent on the machine, and the classifier labels only windows, linux, switch and camera specifically, with printers and appliances falling under other. But it does mean those devices are counted rather than invisible.
Your data stays on your infrastructure: SITEY is installed in your own environment, and inventory snapshots never leave your servers. If you want to see what a real inventory of your fleet looks like, review the pricing and deployment options and get the installer running this week.