DevInt operator documentation

DevInt gives you a live, queryable, standardized inventory of everything installed and trusted across your fleet of Linux and Kubernetes nodes — OS packages, language dependencies, binaries, certificates, kernel and runtime configuration — enriched with vulnerability data and read-only security findings, all in one console.

How it fits together

A tiny read-only agent on each node collects a full bill-of-materials and pushes it over mutual TLS to the control plane, which normalizes, deduplicates, enriches with CVE data, and answers fleet-wide questions through the console you are reading the docs for.

┌──────────────┐   mTLS push   ┌───────────────┐   ┌──────────────────────────┐
│  Edge agents │ ────────────► │ Ingest /       │──►│ Query / Intelligence     │
│ (Linux/K8s)  │  BOM deltas   │ normalize+CVE  │   │ (graph + search + store) │
└──────────────┘               └───────────────┘   └───────────┬──────────────┘
                                                     The Console (this UI) ◄─┘

Onboarding a node

Connecting a node takes three steps. The whole exchange is automatic after you paste one command.

1 · Mint an enrollment token

In the console, open Onboarding (under Platform). Fill in a label, choose the agent privilege mode, optionally a cluster tag, a time-to-live (default 1 hour), and how many nodes the token may enroll (max uses — set 0 for unlimited-until-expiry to bulk-enroll a fleet). Click Mint token and copy the value — it is shown once.

2 · Run the install command on the node

The console shows the exact command with your token substituted in.

# Linux host
curl -sSL https://<your-instance>/install | sh -s -- --token=<TOKEN>

# Kubernetes (in-cluster agent)
helm install devint oci://<your-instance>/chart --set token=<TOKEN>

The agent generates its own keypair, sends a certificate signing request plus the token, and receives an mTLS client certificate whose identity carries its assigned node_id and your org_id.

3 · Watch it appear

Within seconds the node shows up under Devices and begins streaming its full CycloneDX inventory. A re-enrolled node is reconciled by its stable machine-id, so re-installs never create duplicates.

Every screen, explained

Each console screen below: what you see, the possible values, and how to read them.

Dashboard

The at-a-glance posture of your whole fleet: node count and coverage, the CVE severity rollup, open security findings, and recent activity.

Devices

The fleet inventory — every node, host or container. This is the entry point to per-node detail.

Device detail

Click any device to open it. The left panel is the node's general information; the tabs on the right hold its components, certificates, and vulnerabilities.

General information (left)

Node ID and machine-id, type, OS family and kernel, agent mode, coverage, the cluster it serves, the host it runs on, and enrolled / last-seen timestamps. This is the node's identity and provenance at a glance.

Tabs (right)

• components — every package and dependency with its ecosystem and CVE count. Sorted worst-first.
• certs — certificates found on the node; an expiry in the past is shown in critical red.
• vulns — CVEs affecting this node, with severity, CVSS, and the offending component. Only exploitable (VEX-affected) CVEs appear.

The CycloneDX ↓ button exports the node's full bill-of-materials verbatim.

Component detail (drill-down)

Click any component to open it fleet-wide: its ecosystem and versions, the CVEs affecting it, and every node that carries it — so "which machines have this package" is one click, not a query.

Clusters

Kubernetes clusters as first-class assets. A container node that watches a cluster serves it; the cluster owns the cluster-scoped findings (RBAC, privileged pods, NetworkPolicy) rather than hanging them off the sensor pod.

Cluster detail (drill-down)

Open a cluster for its identity (kube-system UID), distribution and version, the nodes serving it, the full cluster-scoped findings list, and its live workload inventory — namespaces, pods, and the images running in them. From here the Topology graph draws the whole cluster.

Vulnerabilities

The fleet-wide CVE view. Each row is a distinct CVE with its severity, CVSS, whether it is a known-exploited vulnerability, and how many nodes it affects.

CVE detail (drill-down)

Open a CVE for its description, CVSS vector, KEV status, the affected component(s), and every node it touches — the pivot from "a CVE exists" to "here is exactly where, and whether it is exploitable."

Images

Container images running across your clusters, scanned as first-class assets. Every distinct image observed in a cluster is pulled apart into its own package inventory (via Trivy) and matched against the same CVE pipeline as hosts — so a vulnerable base image is visible fleet-wide, not hidden inside a pod.

Image detail (drill-down)

Open an image for its full package list and per-package CVEs, plus a blast-radius graph: every pod, node, and cluster that runs this image — so you see exactly what one vulnerable image reaches before you patch it.

Certificates

Every certificate DevInt found across the fleet — TLS, CA, self-signed — with expiry, key strength, and signature algorithm. Only fingerprints and metadata are stored; never private key material.

The list filters to the hygiene signal you care about — expired, expiring within 30 days, self-signed, or weak key (< 2048-bit) — so a rotation queue is one click away.

Licenses

License aggregation across every component in the fleet. DevInt reads the license declared in each package's metadata and rolls it up, so you can answer "what licenses are we shipping, and where" in one place — the compliance flip-side of the SBOM.

Copyleft licenses (GPL/AGPL) on something you ship are the ones to review first; a click drills into the packages and nodes that carry them.

Security

The read-only security findings the agents report: privilege-escalation surface, SSH hygiene, exposed ports, host posture, supply-chain tampering, and more. Each finding links to a runbook in Knowledge.

Finding categories map to collectors — see The agent & collectors for exactly what each one inspects. Severity is critical → info; findings are pruned automatically when the underlying issue is resolved on the next scan.

Drift

What changed since the last scan. DevInt content-addresses each bill-of-materials and diffs it against the prior state: components and findings that appeared, disappeared, changed, or were tampered.

The first scan of a node establishes an immutable baseline silently. You can acknowledge a drift event to hand it off with a note.

Fleet

Group nodes, pick a golden node, capture a desired-state baseline, and validate convergence — which nodes match the baseline and which have drifted.

Geography

Where your fleet lives. Nodes roll up into a region → country → city → datacenter tree; drill down on a tactical map (self-hosted, no external tiles) to see posture aggregated per location.

Posture (CVEs, findings) aggregates up the tree, so a region tile reflects everything beneath it.

Alerts

Grouped, deduplicated alert instances with a full lifecycle. New high/critical findings and CVEs fire alerts routed by your rules to email and webhooks.

Related events are grouped by fingerprint, so 12 CVEs from one rollout become one alert, not twelve pages.

Integrations

Third-party tool findings, normalized alongside DevInt's own. Connect an EDR/scanner (e.g. via signed webhook); DevInt unifies health, findings, and coverage — and shows where a tool should be reporting but isn't.

A coverage gap (a node an EDR doesn't cover) is itself a finding — blind spots are risk.

Insights

Suspicious-pattern detection and the attack-surface graph. Fleet-relative anomalies (a binary on only one node in a cluster) and combination queries (a node with both a privilege-escalation finding and an exposed port) surface here.

Topology

The interactive graph view of a cluster: its namespaces, pods, the images they run, and the nodes that serve it — the same Apache AGE graph the query engine traverses, drawn so you can see relationships instead of reading rows.

Nodes and edges are colored by posture, so a vulnerable image or a privileged pod stands out at a glance. The graph is lazy-loaded, so large clusters stay responsive.

Query

The visual query builder. Ask any question of the fleet — components, certificates, CVEs, findings — and turn the answer into a saved view, an alert, or an exported inventory.

Knowledge

The runbook library. Every finding type has an entry: what it is, why it matters, and how to fix it, with reference links. Findings in the console link straight to their runbook.

Capabilities

The self-describing catalog of everything DevInt can detect and do — every collector, every finding type, every enrichment source — with its status. It answers "what does this platform actually cover?" without reading the source, and doubles as the map from a finding category to the collector that produces it.

Settings

Collection schedules per device class. Each group of collectors (core, runtime, compliance, k8s) has its own cadence, pushed to the agent so it self-paces — you tune how often each layer is re-scanned.

Audit log

An append-only record of every operator action on the platform — tokens minted and revoked, drift acknowledged, alerts actioned, settings changed. Who did what, when, and to which object.

Onboarding & tokens

Covered in full under Onboarding a node. This screen mints reusable enrollment tokens, lists all tokens with their validity and use counts, and lets you revoke any of them. Token management requires the admin role.

The agent & its collectors

The agent is a tiny read-only Rust binary. It runs a set of collectors, each reporting its coverage honestly as full, partial, or skipped. Collectors are organized into groups that can be scheduled independently (see Settings).

Core group — the inventory

Runtime group — live privilege surface

Compliance group — host posture & integrity

Kubernetes group — cluster attack surface

Data lifecycle & vulnerability detection

What happens to the data

1. Emit. The agent assembles a CycloneDX 1.6 BOM (components + certs + findings as spec-compliant properties, no schema fork) and content-addresses it — so ingest volume scales with your change rate, not fleet size.
2. Push. It sends the BOM (or just the delta) to the ingest gateway over mutual TLS. The client certificate carries the node and org identity, so a node can never write into another tenant.
3. Normalize & store. The control plane deduplicates and writes the relational source of truth (PostgreSQL), the raw BOM (object store), a search index (OpenSearch), and enqueues graph projection.
4. Project. An async worker builds the Apache AGE graph: nodes, components, certificates, findings, and the relationships between them — HAS_COMPONENT, RUNS_ON (container→host), SERVES (node→cluster), AFFECTED_BY.
5. Query. The console routes each question to the cheapest store — a point lookup, an aggregation, or a graph traversal.

How posture aggregates

Counts roll up along the structures you browse: a cluster aggregates the findings of the nodes that serve it; a location aggregates everything in its subtree; a group aggregates convergence against its baseline. Every count is a live query, so drilling from a tile to the underlying set never goes stale.

How vulnerabilities are detected

1. Match. Each component (by package URL) is matched against live CVE feeds — OSV.dev plus distro data — to find candidate CVEs. The same pipeline covers container images: every distinct image running in a cluster is inventoried by Trivy and matched identically, so image CVEs sit right beside host CVEs.
2. Suppress false positives. DevInt separates version ordering from CVE fixed-ness. A distro backport (-1ubuntu) can fix a CVE without bumping the upstream version — those are marked not affected via VEX, so you don't chase ghosts.
3. Prioritize. Confirmed affected CVEs carry CVSS severity, and any on CISA's Known-Exploited-Vulnerabilities catalog are flagged KEV — actively exploited, triage first.
4. Alert on deltas. Newly-appearing critical/high CVEs and findings feed the alerting pipeline, grouped and routed by your rules.

Beyond CVEs — the other finding classes

The same data spine carries more than package CVEs, and they all land in one model:

• Read-only security findings from the host collectors above (Security) — priv-esc, SSH hygiene, exposed ports, supply-chain tamper — and the cluster collectors (RBAC, privileged pods, NetworkPolicy).
• Container-image CVEs from the Trivy scan of every observed image (Images).
• Certificate hygiene — expired, expiring, self-signed, and weak-key certificates, computed over the fleet's certificate inventory.
• Drift — what changed between two inventories, with fleet-relative attribution: a change unique to one node reads as manual/out-of-band, one spread across the fleet reads as an automated rollout, and an integrity mismatch is flagged suspicious (Drift).
• Third-party tool findings — an EDR/scanner's own detections, normalized alongside DevInt's, plus the coverage gaps where a tool should be reporting but isn't (Integrations).