From Source Code to Network Profile: Automated and Traceable MUD Profile Generation for IoT Devices

What it is

AutoMUD, from a University of Padua / TU Eindhoven group (arXiv:2609.31594v1, Sep 2026), generates IETF MUD (Manufacturer Usage Description) network access-control profiles for IoT devices by statically analyzing firmware/source trees instead of observing live traffic. The summary already covers this and the traceability/exclusion-preservation angle; what follows is the concrete architecture and the maturity boundary the summary omits.

How it works

The pipeline runs four phases:

flowchart TD
  A[Application Discovery & Isolation<br/>group network-relevant regions into workspaces] --> B[Retrieval-Oriented Representation<br/>chunk, add metadata, embed into per-app vector index]
  B --> C[Protocol Discovery & Role Inference<br/>semantic retrieval + syntactic extraction + exact-source]
  C --> D[Endpoint Consolidation & MUD Synthesis<br/>dedup, eligibility checks, compile]
  D --> E{Concrete, source-supported<br/>packet-level semantics?}
  E -->|yes| F[enforceable ACE rule]
  E -->|no| G[retained for operator review,<br/>NOT converted to permission]

Per-application vector indexes (rather than monolithic indexing) are a deliberate scalability choice (their requirement R1). Static extraction targets calls like socket(), connect(), bind() and tracks propagation of ports/addresses/config values; the LLM layer closes the semantic gap from those low-level facts to MUD abstractions (protocol, transport, IP family, role, direction). Only endpoints with concrete, internally consistent packet-level semantics become rules (R3, conservative synthesis).

Why it matters vs. the alternative

The paper's Table 1 quantifies the gap it addresses: the incumbent traffic-based tool MudGee requires four to six months of collected traffic to obtain representative traces, and still misses rare, configuration-dependent, update-related, or failure-triggered flows — and can encode malicious behavior if the device is compromised during capture. AutoMUD needs no device deployment and attaches source-to-rule provenance plus exclusion evidence, which traffic tools cannot.

Caveats

This is an early evaluation, not a field-proven tool. The entire assessment runs on one Linux-based repository containing curl, wget, and OpenSSH — heterogeneous networking code, but standard Unix services, not real constrained IoT firmware. The error-detection claim comes from a controlled semantic fault-injection campaign, i.e. faults the authors introduced, not naturally occurring bugs. Recovery correctness depends on LLM reasoning over retrieved code; the page states the design constraints but reports no false-positive/negative rates. Treat this as a promising provenance-first approach to validate, not something to enforce on production devices today.