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.

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.

Open a cluster for its identity (kube-system UID), the nodes serving it, and the full findings list.

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.

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.

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.

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.

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.

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.
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.