Containerimage-beveiliging voor defensie: hardening, scanning en supply chain-integriteit

Door Corvus Intelligence Engineering Team · Over het team →

25 juni 2026 11 min lezen

Containerimages zijn de atomaire eenheid van moderne softwarelevering voor defensie. Elke workload die draait op Kubernetes-defensieclusters — missietoepassingen, datapipelines, AI-inferentieservices — arriveert als een onveranderlijk image dat ergens is gebouwd, van iets. De veiligheid van alles downstream hangt af van de integriteit van die buildketen. In commerciële omgevingen is een gecompromitteerd containerimage een ernstig incident. In een geclassificeerde defensieomgeving is het een potentieel kanaal voor inlichtingenverzameling, een persistentiemechanisme voor een staatactor, of het toegangspunt voor destructieve mogelijkheden gericht op wapengerelateerde infrastructuur.

Dit artikel behandelt de volledige levenscyclus van containerimage-beveiliging voor defensie: het selecteren en valideren van STIG-conforme basisimages, het beveiligen van builds met multi-stage Dockerfiles, het uitvoeren van kwetsbaarheidsscanning in air-gapped CI/CD-pipelines, het ondertekenen van images met Cosign/Sigstore in niet-verbonden omgevingen, het genereren van SBOM's voor ATO-pakketten en het afdwingen van register-integriteitscontroles in Harbor. De doelgroep zijn platformengineers en beveiligingsarchitecten die werken aan geclassificeerde of gevoelige defensiesystemen.

Waarom containerimage-beveiliging meer telt in defensie dan in de commerciële sector

In een commerciële onderneming vertegenwoordigt een kwetsbaar of gecompromitteerd containerimage een risico op datalekken, operationele verstoring en regelgevingsaansprakelijkheid. In een geclassificeerde defensieomgeving strekken de gevolgen zich uit tot blootstelling van bronnen en methoden, compromittering van missies en kinetische effecten op systemen die een software-kwetsbaarheid een tegenstander in staat kan stellen te besturen of uit te schakelen. Het dreigingsmodel is kwalitatief anders: de tegenstander is geen financieel gemotiveerde criminele groep maar een staatactor met aanhoudende toegangsoperaties en het geduld om jaren te wachten op het juiste moment om een geplante mogelijkheid te activeren.

Aanvallen op de container-supply chain maken gebruik van de gelaagde aard van containerimages. Een typisch missietoepassingsimage kan zijn gebouwd FROM een basis-OS-image, dat runtime-pakketten installeert vanuit een pakketrepository, die op hun beurt transitieve afhankelijkheden bevatten die tijdens de build zijn opgehaald uit upstream taalenpakketregisters. De tegenstander hoeft de interne systemen van de defensiecontractant niet te compromitteren — het compromitteren van een afhankelijkheid drie niveaus diep in die keten heeft hetzelfde effect. De SolarWinds- en XZ Utils-incidenten toonden aan dat dit dreigingsmodel niet theoretisch is; beide waren supply chain-injecties die technisch ondetecteerbaar zouden zijn geweest zonder diepgaande supply chain-controles.

Defensieomgevingen voegen drie vereisten toe die containerimage-beveiliging aanzienlijk operationeel complexer maken dan in commerciële omgevingen:

Air-gap-vereisten. Geclassificeerde netwerken kunnen tijdens runtime geen images ophalen uit internetregisters. Elke image-afhankelijkheid moet vooraf worden goedgekeurd, gescand en gespiegeld in een intern register voordat het kan worden gebruikt — wat betekent dat de supply chain-grens een harde perimeter is die engineeringteams volledig bezitten en verantwoordelijk zijn voor het bewaken.
Formele autorisatievereisten. Software die draait op geclassificeerde systemen moet een Authorization to Operate (ATO)-proces doorlopen, waarvoor gedocumenteerde herkomst vereist is voor elk softwarecomponent. SBOM-generatie en image-ondertekening verschuiven van optionele hygiènepraktijken naar verplichte ATO-bewijsleveringen.
Handhaving van onveranderlijke infrastructuur. Defensieplatforms schrijven steeds vaker voor dat er geen runtime-wijziging van containerimages is toegestaan: containers worden vernietigd en vervangen, nooit ter plekke gepatcht. Dit betekent dat de beveiligingspositie van een geïmplementeerde workload permanent is ingesteld op het moment van image-build, waardoor build-time hardening en scanpoorten niet-onderhandelbaar worden in plaats van een best-effort aanpak.

STIG-conforme basisimages

DISA (Defense Information Systems Agency) publiceert Security Technical Implementation Guides (STIGs) voor besturingssystemen en platforms die worden gebruikt in defensieomgevingen. Voor gecontaineriseerde workloads zijn de meest operationeel significante de RHEL 8 STIG en RHEL 9 STIG, die van toepassing zijn op Red Hat Universal Base Image (UBI)-afgeleiden — de meest gebruikte basisimages in defensiecontainerplatforms, waaronder het Iron Bank-geharde imagerepository van DoD Platform One.

De RHEL STIG dwingt controles af over verschillende categorieën die materieel verschillen van een standaard OS-installatie:

Kernelparameters (sysctl). IP-doorsturen standaard uitgeschakeld (net.ipv4.ip_forward=0), ICMP-omleidingen geweigerd, TCP SYN-cookies ingeschakeld en gerandomiseerde virtuele adresruimte (ASLR) afgedwongen. Deze controles verminderen de blootstelling van het OS als netwerkdoorstuurregel en maken geheugenexploitatie moeilijker.
PAM-configuratie. Regels voor wachtwoordcomplexiteit (minimumlengte, tekenklassen), accountvergrendeling na mislukte authenticatiepogingen en vereisten voor sessieopname. Voor containerserviceaccounts die sleutelgebaseerde of tokengebaseerde authenticatie gebruiken, kunnen sommige van deze controles gedocumenteerde uitzonderingen vereisen.
auditd-regels. De STIG specificeert een uitgebreide set auditd-regels die betrekking hebben op bestandssysteemtoegang tot gevoelige paden, gebruik van privilege-escalatieopdrachten (sudo, su), wijziging van gebruikers- en groepsdatabases, wijzigingen in netwerkconfiguratie en het laden van kernelmodules. In een containercontext draait auditd doorgaans op de hostkern en is van toepassing op alle containers — de STIG-regels moeten worden toegepast op knooppuntniveau, niet per container.
FIPS 140-cryptografisch beleid. De STIG vereist dat het systembrede cryptobeleid is ingesteld op FIPS of FIPS:OSCP, wat TLS 1.0/1.1, MD5, SHA-1 voor handtekeningen, RC4 en DES/3DES uitschakelt. Toepassingscomponenten die afhankelijk zijn van verouderde algoritmen, zullen mislukken onder het FIPS-cryptobeleid — dit is een veelvoorkomend integratieprobleem dat laat in hardening-projecten wordt ontdekt wanneer het STIG-basisimage wordt gevalideerd aan de hand van testsuites van toepassingen.

De Iron Bank (het geharde containerregister van Platform One) publiceert vooraf geharde images die zijn gevalideerd aan de hand van DISA-STIGs, gescand op kwetsbaarheden en ondertekend. Voor programma's die al op Platform One draaien, is het bouwen FROM een Iron Bank-basisimage de meest praktische aanpak: het biedt een gedocumenteerde, vooraf geautoriseerde basislijn die voldoet aan de basisimage-vereisten van de meeste ATO's. Voor programma's die niet op Platform One draaien, is het zelfstandig bouwen en valideren van STIG-conformiteit met OpenSCAP (oscap-docker of oscap tegen een geëxporteerd containerbestandssysteem) het equivalente proces.

# Valideer een containerimage-bestandssysteem aan de hand van de RHEL 9 STIG
# Exporteer het image-bestandssysteem naar een tijdelijke map
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# Voer OpenSCAP uit op het geëxporteerde bestandssysteem
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/stig-results.xml \
  --report /tmp/stig-report.html \
  --chroot /tmp/image-fs \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Multi-stage build hardening

Multi-stage Docker-builds zijn de meest effectieve enkelvoudige techniek voor het verminderen van het aanvalsoppervlak van containerimages. Het principe is eenvoudig: gebruik een of meer tussenliggende buildstages met alle tools die nodig zijn om de toepassing te compileren en te verpakken, en kopieer alleen de gecompileerde artefacten naar een definitieve runtimestage die niets bevat wat de toepassing niet nodig heeft om te draaien. Een C++-toepassing die is gebouwd in een stage met gcc, make, cmake en development-headers, produceert een definitief image dat alleen het binaire bestand en de runtime-gedeelde bibliotheken bevat.

# Stage 1: build — volledige toolchain, niet aanwezig in het definitieve image
FROM registry.mil/ironbank/redhat/ubi/ubi9:latest AS builder
RUN dnf install -y gcc make cmake openssl-devel && dnf clean all
WORKDIR /build
COPY src/ .
RUN cmake -DCMAKE_BUILD_TYPE=Release . && make -j$(nproc)

# Stage 2: runtime — minimale basis, geen buildtools
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Niet-root gebruiker — STIG- en NSA-beveiligingsvereiste
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

Voor statisch gecompileerde Go- of Rust-toepassingen kan de definitieve stage scratch zijn — een volledig leeg image dat alleen het binaire bestand bevat. Dit elimineert de OS-laag volledig, waardoor alle OS-niveau-kwetsbaarheden van het scanoppervlak van de scanner worden verwijderd. De cross-compilatie- en statische koppelingscapaciteiten van de Go-standaardbibliotheek maken scratch-images praktisch voor een brede klasse van defensiemicroservices zonder extra buildcomplexiteit.

Wanneer de toepassing een shell of OS-hulpprogramma's nodig heeft tijdens runtime (debugging in development, health check-scripts, initialisatielogica), bieden gcr.io/distroless-images een middenweg: een minimale Debian- of Alpine-basis die alleen de taalruntime en C-bibliotheek bevat, zonder shell, zonder pakketbeheerder en zonder systeemhulpprogramma's. Distroless-images worden onderhouden door Google en gepubliceerd met kwetsbaarheidscanresultaten; defensieprogramma's die distroless gebruiken, moeten deze images spiegelen in hun interne register en hun eigen kwetsbaarheidsbeoordeling bijhouden.

Handhaving van niet-root-gebruikers is een beveiligingsvereiste in zowel de NSA Kubernetes Hardening Guide als de STIG. De instructie USER in de Dockerfile stelt de standaardgebruiker in voor alle volgende opdrachten en voor het container-entrypoint. Gebruik een numerieke UID (geen benoemde gebruiker) om afhankelijkheid van het /etc/passwd-bestand te vermijden, en kies een UID boven 10000 om conflicten met systeemgebruikerbereiken te vermijden. Admissiecontrollers die het Pod Security restricted-profiel afdwingen, zullen pods afwijzen waarbij runAsNonRoot niet true is of waarbij een container runAsUser: 0 declareert.

Kwetsbaarheidsscanning in geclassificeerde CI/CD-pipelines

Kwetsbaarheidsscanning is de kwaliteitspoort die verhindert dat images met bekende exploiteerbare CVE's geclassificeerde implementaties bereiken. Twee open-source scanners domineren defensiecontainerplatformimplementaties: Trivy (Aqua Security) en Grype (Anchore). Beide ondersteunen offline werking — een niet-onderhandelbare vereiste voor CI/CD in air-gapped defensieomgevingen.

De offline modus van Trivy vereist dat de kwetsbaarheidsdatabase vooraf wordt gedownload en overgebracht naar de air-gapped omgeving. De database dekt OS-pakketten (RPM, DEB, APK), taalecosysteempakketten (pip, npm, Maven, Go-modules, Cargo) en binaire handtekeningen van toepassingen. De overdrachtworkflow met verwijderbare media of een cross-domain-oplossing moet worden geïntegreerd in de reguliere operaties van het team als een geplande taak — een verouderde database (ouder dan 14 dagen) is een veelvoorkomende bevinding bij beveiligingsbeoordelingen van geclassificeerde omgevingen.

# Op verbonden (internetgericht) systeem — download Trivy DB
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# Breng /transfer/trivy-cache over naar air-gapped systeem via goedgekeurde media

# Op air-gapped CI/CD-runner — scan image met lokale DB
trivy image \
  --skip-update \
  --cache-dir /opt/trivy-cache \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --ignore-unfixed \
  --format json \
  --output /artifacts/scan-results.json \
  registry.classified.mil/myapp@sha256:abc123...

# Grype-equivalent — auto-update uitschakelen, naar lokale DB verwijzen
GRYPE_DB_AUTO_UPDATE=false \
GRYPE_DB_CACHE_DIR=/opt/grype-db \
grype registry.classified.mil/myapp@sha256:abc123... \
  --fail-on critical \
  --output json > /artifacts/grype-results.json

Scanbeleidpoorten bepalen welke bevindingen een pipeline-build blokkeren versus waarschuwingen genereren. Een verdedigbaar poortbeleid voor geclassificeerde omgevingen:

Blokkeren (pipeline mislukt, image niet gepusht): elke CRITICAL-ernst-CVE, elke HIGH-ernst-CVE in een directe afhankelijkheid met een CVSS-exploiteerbaarheidssubscore boven 7.0 of een EPSS-score boven 0.05.
Waarschuwen en vrijstelling vereisen: HIGH-ernst-CVE's in transitieve afhankelijkheden, HIGH-ernst-CVE's waarvoor geen leverancierspatch beschikbaar is, MEDIUM-ernst-CVE's.
Alleen informatief: LOW- en NEGLIGIBLE-bevindingen, CVE's die componenten treffen die aantoonbaar niet bereikbaar zijn in het uitvoeringspad van de toepassing.

Elke vrijstelling moet een ondertekend, tijdgebonden document zijn dat de CVE-identificatie koppelt aan de rechtvaardiging (geen patch beschikbaar, component niet bereikbaar, compenserende controle), de goedkeurende beveiligingsfunctionaris en een vervaldatum die herbeoordeling triggert. Vrijstellingen opgeslagen als code-beoordeelde YAML-bestanden in het CI/CD-repository bieden een auditeerbaar overzicht dat voldoet aan de ATO-bewijs vereisten.

Image-ondertekening met Cosign/Sigstore in niet-verbonden omgevingen

Image-ondertekening biedt cryptografisch bewijs dat een specifiek containerimage — geïdentificeerd door zijn SHA-256-inhoudsdigest — is geproduceerd door een geautoriseerde pipeline en niet is gewijzigd na ondertekening. Cosign (onderdeel van het Sigstore-project van de Linux Foundation) is het standaard image-ondertekeningsgereedschap voor containeromgevingen geworden, waarbij OCI-compatibele handtekeningen worden geproduceerd die zijn opgeslagen als artefacten in hetzelfde register als het image.

De sleutelloze ondertekeningsstroom van Sigstore maakt gebruik van OIDC-identiteitstokens en publieke infrastructuur (Fulcio CA en Rekor-transparantielogboek) om images te ondertekenen zonder langdurige privésleutels te beheren. Dit model is goed geschikt voor publieke open-source CI/CD, maar vereist internettoegang tot de publieke Sigstore-infrastructuur — niet compatibel met air-gapped geclassificeerde omgevingen. Niet-verbonden omgevingen hebben twee praktische opties:

Sleutelondertekening (aanbevolen voor geclassificeerd). Genereer een Cosign-sleutelpaar; sla de privésleutel op in een HSM of goedgekeurde secrets manager (HashiCorp Vault met FIPS-gevalideerde backend, AWS CloudHSM of Azure Dedicated HSM). De ondertekeningsstap in de CI/CD-pipeline haalt de sleutelreferentie op en ondertekent de image-digest. De publieke sleutel wordt gedistribueerd naar admissiecontrollers voor verificatie. Er is geen externe infrastructuur vereist.
Privé Sigstore-instantie. Implementeer Fulcio en Rekor binnen het geclassificeerde netwerk. Dit biedt de sleutelloze UX en transparantielogboekvoordelen, maar vereist het beheren van aanvullende infrastructuur, inclusief een intern OIDC-identiteitsprovider. Geschikt voor grote programma's met speciale platformengineeringteams.

# Genereer Cosign-sleutelpaar (eenmalig uitvoeren, privésleutel in HSM/Vault opslaan)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Onderteken image nadat scanpoorten zijn geslaagd — refereer image op digest, niet op tag
IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myapp:v1.2.3)
cosign sign \
  --key awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def \
  --tlog-upload=false \
  registry.classified.mil/myapp@${IMAGE_DIGEST}

# Verifieer handtekening (gebruikt door admissiecontrollers en bij handmatige audits)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

Handhaving van image-handtekeningen door admissiecontrollers sluit de kloof tussen pipeline-ondertekening en runtime-implementatie. Een Kyverno ClusterPolicy met een verifyImages-regel weigert elke pod die verwijst naar een image zonder een geldige handtekening van de goedgekeurde Cosign-publieke sleutel. Het beleid moet ook mutateDigest: true inschakelen, waardoor veranderlijke tagreferenties bij toelating worden herschreven naar onveranderlijke digestreferenties in de pod-spec — zodat de containerruntime exact het geverifieerde image ophaalt, niet een latere push naar dezelfde tag.

SBOM-generatie voor ATO-pakketten

Een Software Bill of Materials (SBOM) is een machineleesbare inventaris van elk softwarecomponent in een geïmplementeerd artefact — OS-pakketten, taalruntimebibliotheken, toepassingsafhankelijkheden en hun relaties. Voor ATO-pakketten biedt de SBOM de autoriserende functionaris supply chain-inzicht in het geïmplementeerde systeem en is steeds vaker een vereiste levering onder het DoD-softwareaankoopbeleid en de CISA-richtlijnen die Executive Order 14028 implementeren.

Syft (Anchore) is de standaard open-source SBOM-generator voor containerimages. Het scant het image-bestandssysteem laag voor laag, identificeert pakketten door zowel OS-pakketdatabaserecords als taalecosysteemvergrendelingsbestanden, en geeft gestructureerde SBOM-documenten uit. Het uitvoeren van Syft tegen de definitieve image-digest (niet de Dockerfile of het bronrepository) legt de werkelijk geïmplementeerde componentset vast, inclusief pakketten die transitief zijn geïnstalleerd of toegevoegd tijdens het buildproces die niet expliciet worden vermeld in toepassingsafhankelijkheidsbestanden.

# Genereer SBOM in zowel SPDX- als CycloneDX-formaten van het definitieve image
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# Koppel SBOM aan het image in het register (opgeslagen als OCI-artefact)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# Verifieer SBOM-koppeling
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

Over de keuze tussen SPDX en CycloneDX: beide formaten worden geaccepteerd door de CISA-richtlijnen en zijn in staat dezelfde componentinformatie te vertegenwoordigen. SPDX (ISO/IEC 5962:2021) is de oudere standaard met het sterkste mandaat in overheidscontexten; CycloneDX heeft sterkere toolingondersteuning voor kwetsbaarheidsverrijking via VEX-documenten (Vulnerability Exploitability eXchange). Voor SBOM-handhaving in defensiepipelines kost het genereren van beide formaten vanuit één Syft-aanroep niets en garandeert compatibiliteit met alle downstream ATO-tooling of voorkeur van de autoriserende functionaris.

De SBOM die aan de AO wordt voorgelegd, moet vergezeld gaan van een kwetsbaarheidsopenbaarmaking-document dat SBOM-componentidentificatoren koppelt aan scanresultaten en hun dispositie (gepatcht, vrijgesteld met rechtvaardiging, niet getroffen). Dit gecombineerde pakket — image-digest, SBOM, scanresultaten, vrijstellingen en Cosign-handtekening — vormt de supply chain-bewijsset die auditors gebruiken om de betrouwbaarheid van een geïmplementeerd systeem te beoordelen.

Beveiliging van containerimage-registers

Harbor is het CNCF-afgestudeerde containerregister dat het meest wordt ingezet in defensie- en geclassificeerde omgevingen. De functieset richt zich op de specifieke operationele vereisten van defensieregisters: tag-onveranderlijkheid, integratie van inhoudsvertrouwen met Cosign, op rollen gebaseerde toegangscontrole, integratie van kwetsbaarheidsscanning (Trivy) en replicatiebeleid voor multi-enclave registernetwerken. Het uitvoeren van Harbor in een geclassificeerde omgeving vereist aandacht voor verschillende configuratiegebieden die standaardinstellingen niet afdwingen.

Tag-onveranderlijkheid voorkomt dat een push-operatie een bestaande image-tag overschrijft. Zonder deze controle zou een gecompromitteerd CI/CD-serviceaccount of een verkeerd geconfigureerde pipeline stilletjes een goedgekeurd, ondertekend image kunnen vervangen door een kwaadaardig of niet-ondertekend image onder dezelfde tag. De tag-onveranderlijkheidsregels van Harbor zijn geconfigureerd per project en kunnen worden beperkt tot specifieke tagpatronen — bijvoorbeeld het vergrendelen van alle tags die overeenkomen met v[0-9]* (releaseversies) terwijl veranderlijke dev-*-tags in ontwikkelprojecten worden toegestaan.

Inhoudsvertrouwensbeleid in Harbor integreert met Cosign om handtekeningverificatie af te dwingen bij pull-time. Wanneer inhoudsvertrouwen is ingeschakeld voor een project, roept de proxylayer van Harbor Cosign verify aan voor elk image-pullverzoek en geeft een autorisatiefout terug als het image geen geldige handtekening heeft van de geconfigureerde publieke sleutel. Dit biedt registerbeveiliging onafhankelijk van de Kubernetes-admissiecontroller — images kunnen niet worden opgehaald, zelfs niet door tooling die de admissiewebhook omzeilt.

# Harbor-projectconfiguratie via CLI (harbor-cli of curl tegen Harbor API)
# Schakel tag-onveranderlijkheid in voor productieproject
curl -X POST https://registry.classified.mil/api/v2.0/projects/mission-apps/immutabletagrules \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{
    "action": "immutableTagRule",
    "scope_selectors": {"repository": [{"decoration": "repoMatches","pattern": "**"}]},
    "tag_selectors": [{"decoration": "matches","pattern": "v[0-9]*"}]
  }'

# Schakel kwetsbaarheidsscanning bij push in voor alle projecten
curl -X PUT https://registry.classified.mil/api/v2.0/projects/mission-apps \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{"metadata": {"auto_scan": "true", "severity": "critical"}}'

Pull-through cache in Harbor vervult een kritieke functie in multi-enclave-architecturen. De verbonden (lagere-classificatie) Harbor-instantie is geconfigureerd met upstream proxy-cacheprojecten die verwijzen naar goedgekeurde externe registers (Red Hat Registry, Iron Bank). Aan de geclassificeerde kant heeft een aparte Harbor-instantie geen upstream register geconfigureerd — deze bedient alleen images die door de cache zijn opgehaald aan de verbonden kant, gescand, ondertekend en fysiek zijn overgebracht naar het geclassificeerde-kant-register via het goedgekeurde cross-domain-overdrachtsm mechanisme. Dit creëert een gecontroleerde image-promotieworkflow waarbij elk image beveiligingscontroles moet doorstaan voordat het de geclassificeerde omgeving binnengaat in plaats van bij de ingang.

Garbage collection-beleid in Harbor verwijdert niet-getagde manifesten en ongebruikte lagen op een bepaald schema. In geclassificeerde omgevingen met beperkte opslagcapaciteit voorkomt garbage collection dat registeropslag onbegrensd groeit naarmate images worden vervangen door nieuwe versies. De aanbevolen configuratie voert garbage collection wekelijks uit tijdens een onderhoudsvenster, behoudt een configureerbaar aantal historische getagde images per repository voor rollback-mogelijkheid, en genereert een verwijderingslogboek voor auditbaarheid. Verwijdering van images in een geclassificeerd register moet worden gecoördineerd met de ATO-bewaarsvereisten — SBOM- en scanartefacten voor geïmplementeerde imageversies moeten mogelijk worden bewaard na de image-levenscyclus.

Kernpunt: Containerimage-beveiliging is geen enkelvoudige controle maar een defense-in-depth-keten: STIG-basisimages verminderen het geërfde kwetsbaarheidsoppervlak; multi-stage builds elimineren ongebruikt aanvalsoppervlak uit het runtime-image; kwetsbaarheidsscanning tijdens de build vangt bekende CVE's op vóór implementatie; image-ondertekening biedt integriteitsverificatie van build tot runtime; SBOM-generatie biedt supply chain-transparantie voor autorisatie; en registercontroles (onveranderlijkheid, inhoudsvertrouwen, pull-through cache) dwingen de keten af op de distributielaag. Een gat in een schakel van die keten — een niet-ondertekend image, een verouderde kwetsbaarheidsdatabase, een veranderlijke tag — is het aanvalsoppervlak dat een tegenstander met supply chain-toegang zal exploiteren.

Bespreek uw project

Wij ontwerpen en implementeren containerbeveiliging-pipelines voor geclassificeerde defensieomgevingen — van STIG-basisimage-validatie en air-gapped kwetsbaarheidsscanning tot Cosign-ondertekeningsinfrastructuur en Harbor-registerconfiguratie voor multi-enclave-architecturen.

Secure Cloud-diensten → Boek een briefing

Deze analyse is opgesteld door Corvus Intelligence-engineers die bedrijfskritische software bouwen voor defensie- en overheidsorganisaties. Meer over ons team →

Veelgestelde vragen

Waarom vereist containerimage-beveiliging een andere aanpak in defensie dan in commerciële bedrijven?

Defensieomgevingen voegen drie drukpunten toe die afwezig zijn in de meeste commerciële omgevingen. Ten eerste kunnen geclassificeerde workloads geen images ophalen uit internetregisters, zodat elke afhankelijkheid moet worden gespiegeld in een goedgekeurd intern register — wat betekent dat de supply chain-grens een harde perimeter is die u volledig bezit. Ten tweede moet defensiesoftware voldoen aan een formeel autorisatieproces (ATO) dat gedocumenteerde herkomst vereist voor elk component, waardoor SBOM-generatie en image-ondertekening van nice-to-have naar verplicht verschuiven. Ten derde omvat het dreigingsmodel voor de tegenstander staatactoren met de mogelijkheid en motivatie om kwaadaardige componenten upstream te injecteren in open-source bibliotheken of basis-OS-pakketten — precies het aanvalsoppervlak dat een container-image-supply chain blootstelt.

Welke STIG is van toepassing op container-basisimages en wat dwingt het af?

DISA publiceert de Container Platform Security Requirements Guide (SRG) en specifieke STIGs voor Red Hat Universal Base Image (UBI)-afgeleiden en RHEL 8/9. De RHEL STIG is de meest operationeel relevante basislijn: het verplicht specifieke sysctl-kernelparameterwaarden (beperking van IP-doorsturen, ICMP-omleidingen en SYN-cookies), PAM-configuratie die wachtwoordcomplexiteit en accountvergrendeling afdwingt, auditd-regels die bestandstoegang, privilege-escalatie en wijzigingen in netwerkconfiguratie omvatten, en het FIPS 140-2/140-3-cryptografische beleid. Wanneer u FROM een door DISA geleverd of onafhankelijk STIG-geharde basisimage bouwt, erft u de OS-niveaucontroles en hoeft u alleen uw toepassingslaag daarbovenop te beveiligen.

Wat is een distroless containerimage en wanneer moeten defensieworkloads het gebruiken?

Een distroless image bevat alleen de toepassingsruntime en de directe bibliotheekafhankelijkheden — geen pakketbeheerder, geen shell, geen systeemhulpprogramma's. Het beveiligingsvoordeel is aanzienlijk: een container zonder shell kan niet worden geëxploiteerd via shell-injectie; een container zonder pakketbeheerder kan niet worden gebruikt om aanvallerstools te downloaden en te installeren na compromittering. Voor statisch gecompileerde Go- of Rust-binaries is scratch (een volledig leeg basisimage) nog minimaler. Defensieworkloads die distroless kunnen verdragen — de meeste stateless microservices kunnen dat — moeten er de voorkeur aan geven boven algemene OS-basisimages, ongeacht hoe geharde dat OS-image is.

Hoe voert u Trivy of Grype uit in een air-gapped geclassificeerd netwerk?

Zowel Trivy als Grype ondersteunen offline databasewerking. Voor Trivy downloadt u de kwetsbaarheidsdatabasebundel op een verbonden systeem, brengt u deze over via de datadiode of verwijderbare media naar het geclassificeerde netwerk, en verwijst u Trivy naar de lokale kopie met de vlaggen --skip-update en --cache-dir. Grype gebruikt een vergelijkbaar patroon: download de grype-db-bundel, plaats deze in de geconfigureerde cachemap en stel GRYPE_DB_AUTO_UPDATE=false in. De sleuteldiscipline in operaties is een reguliere (wekelijkse of per-sprint) databasevernieuwingscyclus — verouderde kwetsbaarheidsdatabases in geclassificeerde omgevingen zijn een veelvoorkomende compliance-bevinding omdat het vernieuwingsproces fysieke mediaoverdracht vereist en gemakkelijk wordt uitgesteld.

Wat is Cosign en hoe maakt het image-ondertekening mogelijk zonder een publieke Fulcio/Rekor-instantie?

Cosign (onderdeel van het Sigstore-project) ondertekent containerimages door een cryptografische handtekening te koppelen als een OCI-artefact dat is opgeslagen in hetzelfde register naast het image. In een sleutelloze Sigstore-stroom maakt Cosign gebruik van OIDC-identiteitstokens en het publieke Fulcio CA en Rekor-transparantielogboek — wat internettoegang vereist. In een air-gapped defensieomgeving vereist de eenvoudigere sleutelondertekeningsstroom — waarbij Cosign ondertekent met een privésleutel opgeslagen in een HSM of secrets manager — helemaal geen externe infrastructuur en is de meest praktische aanpak voor geclassificeerde omgevingen. De vlag --tlog-upload=false schakelt het uploaden naar het transparantielogboek uit, en --insecure-ignore-tlog=true slaat Rekor-verificatie over aan de verificatiekant.

Welk SBOM-formaat moeten defensieprogramma's gebruiken — SPDX of CycloneDX?

Beide formaten worden geaccepteerd door CISA en zijn in staat dezelfde supply chain-informatie te vertegenwoordigen. SPDX (ISO/IEC 5962:2021) is de oudere standaard met sterkere overheidsmandaten, inclusief de Executive Order 14028 SBOM-richtlijnen. CycloneDX heeft sterkere ondersteuning voor kwetsbaarheidsverrijking (VEX-documenten), beveiligingsbeoordelingen en machineleesbare componentidentiteit, en wordt steeds vaker geprefereerd door SBOM-analysetooling. Voor ATO-pakketten kost het produceren van beide formaten vanuit één Syft-run niets en voldoet aan elke vereiste van een downstream-autoriserende functionaris — gebruik twee --output-vlaggen in één opdracht.

Hoe beschermt tag-onveranderlijkheid in Harbor tegen image-substitutieaanvallen?

Standaard staan containerregisters toe dat een bestaande tag wordt overschreven met een andere image-digest — zodat :latest of :v2.3.1 morgen naar een volledig ander image kan verwijzen. In een defensie-supply chain zou een gecompromitteerd registeraccount of een verkeerd geconfigureerde CI-pipeline stilletjes een goedgekeurd image kunnen vervangen door een kwaadaardig image onder dezelfde tag. De tag-onveranderlijkheidsfunctie van Harbor, geconfigureerd per project, verhindert elke push die een bestaande tag zou overschrijven. Gecombineerd met image-ondertekening (die de digest vastlegt in de handtekening) en admissiecontroller-digest-pinning sluit tag-onveranderlijkheid het image-substitutieaanvalsoppervlak volledig af.

Welke scanbeleidpoortdrempels zijn geschikt voor defensie-CI/CD-pipelines?

Een verdedigbaar beleid: blokkeer op elke CRITICAL-kwetsbaarheid met een bekende exploit (EPSS-score boven 0.05 of CVSS-exploiteerbaarheidssub-score boven 7.0); blokkeer op elke HIGH-kwetsbaarheid in een directe afhankelijkheid met een bekende exploit; waarschuw en vereist gedocumenteerde vrijstelling voor HIGH-kwetsbaarheden zonder publieke exploit en MEDIUM-kwetsbaarheden. De blokkeer-op-alle-HIGH-regel is gebruikelijk in compliance-frameworks, maar genereert in de praktijk overmatig ruis — met name voor OS-pakketkwetsbaarheden in STIG-basisimages waarvoor de leverancierspatch nog niet beschikbaar is. Gating op ernst plus exploiteerbaarheid vermindert fout-positieve blokkades terwijl nog steeds kwetsbaarheden worden gevangen die het meest waarschijnlijk worden bewapend.

Wat is de rol van een SBOM in het ATO (Authorization to Operate)-proces?

Een SBOM is een machineleesbare stuklijst die elk softwarecomponent in een geïmplementeerd systeem opsomt, inclusief versie-identificatoren en componentrelaties. In het ATO-proces biedt de SBOM de autoriserende functionaris (AO) inzicht in de volledige software-supply chain — waardoor de AO kan beoordelen of een component bekende kwetsbaarheden, commerciële licentiebeperkingen of onbetrouwbare herkomst heeft. De SBOM die aan de AO wordt ingediend, moet worden gegenereerd tijdens de image-buildtijd (niet vanuit de bron), moet alle lagen van elk containerimage dekken en moet onveranderlijk worden opgeslagen naast het ondertekende image in het artefactregister. Een begeleidend VEX-document dat CVE's koppelt aan hun exploiteerbaarheidsstatus versterkt de indiening.

Hoe ondersteunt pull-through cache in Harbor geclassificeerde netwerkoperaties?

Het proxy-cacheproject van Harbor stelt u in staat een upstream register (Red Hat Registry, Iron Bank) te configureren en transparant images te spiegelen bij de eerste pull. In een geclassificeerd netwerk zonder internettoegang wordt pull-through cache doorgaans vooraf gevuld: images worden door de cache opgehaald aan de verbonden enclave-kant, en de Harbor-registergegevens worden gerepliceerd naar de geclassificeerde-kant Harbor via verwijderbare media of een datadiode-overdracht. De geclassificeerde-kant Harbor heeft geen upstream register geconfigureerd en bedient alleen vooraf goedgekeurde, vooraf gescande, vooraf ondertekende images. Dit dwingt beveiligingscontroles af voordat images ooit de geclassificeerde omgeving binnengaan in plaats van alleen te vertrouwen op runtime-handhaving.