AI-assisteret sikkerhedsvurdering af IoT-systemer

Problem

Moderne IoT-systemer afhænger ikke kun af applikationskode. De afhænger af biblioteker, build tools, containere, firmware-nære hjælpeværktøjer, transitive dependencies, package metadata, lockfiles, vulnerability advisories, SBOM-data, runtime-evidens og de systemdele, hvor dependencies rammer device identity, updates, telemetri og netværkstransport.

AI-assisteret udvikling sætter større krav til kode review-processen. Kodebaser og dependency-grafer kan vokse hurtigere, end manuel sikkerhedsreview komfortabelt kan følge med. Det betyder ikke, at en AI-model bør træffe sikkerhedsbeslutninger. Det betyder, at review-flowet har brug for bedre måder at organisere evidens på, før en person vurderer, hvad der faktisk betyder noget.

Hvad jeg byggede

Jeg byggede local-ai-vet, en Rust CLI til lokal AI-assisteret sikkerhedstriage.

CLI’en tager struktureret sikkerhedsevidens, sender den til en lokal Ollama-model,¹ modtager strukturerede AI-triage-kandidater, validerer de refererede evidens-ID’er og genererer en Markdown-review-rapport til godkendelse af en person.

Den strukturerede sikkerhedsevidens er tænkt som et downstream-lag oven på den evidensbaserede audit engine, jeg byggede til audits af IoT-sikkerhed og driftssikkerhed. Audit engine’en genererer deterministiske, auditerbare artefakter fra prober og regel-evaluering, og de artefakter kan kombineres med supply-chain-evidens som:

• CycloneDX Software Bill of Materials for Rust/Cargo-projekter, hvor værktøjet skaber et samlet SBOM over projektets dependencies.²
• cargo audit-findings fra RustSec Advisory Database.³
• Audit-engine findings, baseline diffs, scanner findings og systemkontekst fra det bredere review-flow.

Kombinationen er vigtig, fordi dependency-review bliver stærkere, når en advisory eller SBOM-komponent kan kobles til systemkontekst. En sårbar dependency i et ubrugt developer tool er ikke det samme som en sårbar dependency i en sti, der håndterer device identity, certifikatvalidering, MQTT, TLS, serialisering eller software updates.

Kortet viser den kontekst, som workflowet skal hjælpe med at holde synlig. Dependency-graf, SBOM-dækning, vulnerability intelligence, build-provenance, container-artefakter, certifikater, update paths og runtime-telemetri påvirker alle, hvor alvorligt et fund bør reviewes. Pointen er ikke at lave en universel risikoscore. Pointen er at give revieweren en struktureret måde at se, hvor AI kan korrelere evidens, og hvor et menneske stadig skal vurdere exploitability, remediation-prioritet og accepteret risiko.

Den relaterede designkontekst er beskrevet i Design af en evidensbaseret audit engine til IoT-sikkerhed & driftssikkerhed.

Hvorfor det betyder noget

AI’en træffer ikke den endelige sikkerhedsbeslutning.

Den hjælper med at organisere evidens, opsummere review-worthy kandidater, forklare IoT-relevans, foreslå review checks og forberede en struktureret rapport. Revieweren er stadig ansvarlig for at godkende, afvise, eskalere, acceptere risiko eller bede om mere evidens.

Den grænse er vigtig. En model kan være nyttig til at omsætte en stor evidenspakke til en review-kø, men den må ikke få lov til at opfinde CVE’er, package names, versioner, exploitability claims, remediation facts eller unsupported references. Workflowet er derfor bygget med evidens først, AI-assistance bagefter og menneskelig beslutning til sidst.

Teknisk udsnit

• Rust CLI
• Lokal Ollama-model
• JSON-evidens som input
• Struktureret triage-output
• Validering af evidens-ID’er
• Markdown-rapportgenerering
• Human-in-the-loop review-flow

CLI’en har tre centrale kommandoer:

1. triage læser en JSON evidence pack, kalder den lokale model og skriver struktureret AI-triage-output.
2. validate kontrollerer, at hver finding-kandidat refererer til evidens-ID’er, der faktisk findes i inputpakken.
3. report renderer det validerede triage-output til en Markdown-reviewrapport.

Rapport-formatet er bevidst praktisk. Hver kandidat indeholder affected components, evidence references, hvorfor fundet er review-worthy, IoT-relevans, foreslåede menneskelige checks, uncertainty og eksplicitte checkbokse til human decision.

Workflow-overblikket viser grænsen mellem evidensindsamling, model-assisteret triage, validering og menneskelig review. Inventory og SBOM-data etablerer, hvad systemet består af. Vulnerability intelligence, dependency-analyse, build artefacts, runtime-kontekst, update mechanisms, network exposure, policy-krav og monitoring-evidens tilføjer den operationelle betydning. Modellen organiserer evidensen som kandidater, men reviewsporet bliver først brugbart, når referencerne er valideret, og et menneske godkender, afviser, eskalerer eller beder om mere evidens.

Sikkerhedsprincip

AI-forslag skal være forankret i reel evidens.

Unsupported evidence references bliver afvist, før de kommer ind i reviewrapporten. Kandidater uden evidensreferencer bliver også afvist. Prompten instruerer modellen i kun at bruge den leverede evidens og i at behandle package source, metadata, README-filer, kommentarer og build scripts som untrusted input.

Det er kernen i prototypen: AI må gerne assistere revieweren, men den må ikke smugle usupporterede påstande ind i beslutningsgrundlaget.

Outcome

Resultatet er en prototype på et workflow, der kan skalere sikkerhedsreview på tværs af IoT- og software supply-chain-evidens uden at afhænge af cloud-AI eller ukontrolleret modeloutput.

Projektet viser et praktisk mønster for AI-assisteret sikkerhedsarbejde:

• hold sensitiv review-kontekst lokal, hvor det er muligt
• repræsenter evidens som struktureret data
• bed modellen om kandidater, ikke endelige beslutninger
• valider evidensreferencer før rapportgenerering
• bevar uncertainty i stedet for at skjule den
• gør det menneskelige review-step eksplicit

Værdien er ikke, at AI erstatter sikkerhedsvurdering. Værdien er, at en reviewer kan arbejde gennem dependency-, SBOM-, sårbarheds- og audit-engine-evidens med en bedre forberedt kø og et tydeligere beslutningsspor.

Referencer