CI/CD-pipelines voor air-gapped defensieomgevingen

Standaard CI/CD-pipelines zijn gebouwd op de aanname van alomtegenwoordige uitgaande internetverbinding. Elke runner haalt een basisimage op uit een openbaar register, elke build lost afhankelijkheden op uit upstream-pakketrepositories, en elke scantool downloadt bij het opstarten nieuwe kwetsbaarheidshandtekeningen. In een geclassificeerde, air-gapped defensieomgeving gelden geen van deze aannames — en de technische gevolgen reiken tot in elke laag van de toolchain. Deze gids behandelt de architecturale beslissingen, toolchainkeuzes en operationele procedures die continue integratie en levering mogelijk maken zonder internetverbinding, op STIG-geharde infrastructuur, binnen een accreditatiegrens.

Waarom standaard CI/CD faalt in air-gapped defensieomgevingen

Het faalpatroon is niet één ontbrekende functie — het is een cascade van aannames die zijn ingebakken in elk modern CI/CD-tool en die in contact met een air-gapped accreditatiegrens instorten. Als u deze faalpatronen van tevoren begrijpt, voorkomt u verspilde aankooprondes en last-minute architectuuraanpassingen wanneer de ATO-review begint.

Netwerkisolatie. Een geclassificeerde enclave op Secret-niveau en hoger heeft ontwerptechnisch geen uitgaande internettoegang. Runners kunnen geen images ophalen van Docker Hub, Maven Central, npmjs.com of PyPI. Buildtools die bij eerste gebruik plugins of extensies downloaden, falen stil of met cryptische foutmeldingen over onbereikbare hosts. Updatemechanismen in Jenkins, GitLab en de meeste commerciële CI-tools bellen bij het opstarten naar huis — dit verkeer wordt geblokkeerd en genereert vaak ruis in de netwerkmonitoringconsole die de ISSM moet verklaren aan de AO.

Softwaregoedkeuring en accreditatie. Elke softwarecomponent die binnen een DoD-accreditatiegrens wordt ingezet, moet door de Authorizing Official (AO) worden goedgekeurd als onderdeel van het System Authorization Package. Dit omvat niet alleen de CI-server, maar ook elke plugin, elk build-agentimage en elke bibliotheek waarvan de pipeline zelf afhankelijk is. "We gebruiken de nieuwste versie uit het openbare register" is geen aanvaardbaar antwoord in een ATO-context. De goedgekeurde softwarelijst is een gecontroleerd document; het toevoegen van nieuwe pakketten vereist een formeel verzoek, een kwetsbaarheidsscan, een licentiecontrole en — voor pakketten zonder bestaande STIG-dekking — een aanvullende documentatielast voor het engineeringteam. Dit proces duurt doorgaans dagen tot weken per pakket, waardoor ad-hoc afhankelijkheidstoepassingen onverenigbaar zijn met het ontwikkelingstempo dat een moderne CI-pipeline vraagt. De oplossing is het goedkeuringsproces vooraf te laden door elke afhankelijkheid te identificeren voordat de pipeline wordt ingezet, niet daarna.

Toolaanschaf en licenties. Sommige CI-tooling is zonder meer beschikbaar voor overheidsaannemers. Sommige vereist specifieke licentieovereenkomsten voor overheidsgebruik. Sommige vereist een exportcontrolereview (ITAR/EAR-classificatie). Jenkins OSS en GitLab CE vermijden de meeste van deze problemen, wat deels hun dominantie in geclassificeerde omgevingen verklaart. Commerciële CI-platforms die propriëtaire runners, beheerde geheimenservices of cloudgebaseerde analyses bundelen, zijn over het algemeen niet haalbaar binnen een air-gapped enclave zonder significante architectuuraanpassing.

Het nettoresultaat is dat air-gapped CI/CD van de grond af moet worden ontworpen, niet aangepast vanuit een commercieel SaaS-patroon. De bouwstenen zijn beschikbaar en bewezen — ze vereisen alleen expliciete offline provisioning voor elke component die een standaard pipeline dynamisch zou oplossen. Voor het bredere DevSecOps-kader dat deze beslissingen stuurt, zie onze gids over DevSecOps voor defensiepipelines.

Architectuur van offline artefactregisters

Het artefactregister is het supply chain-anker voor een air-gapped buildomgeving. Elke afhankelijkheid — JARs, npm-pakketten, Python wheels, Go-modules, RPMs — moet worden bediend vanuit de enclave. Twee producten domineren deze ruimte in geclassificeerde omgevingen: Sonatype Nexus Repository (OSS en Pro) en JFrog Artifactory (OSS en Pro). Beide zijn te implementeren op RHEL zonder uitgaande verbinding voor de werking; beide ondersteunen de repositoryformaten die een typisch defensiesoftwareproject vereist.

De topologie heeft twee helften. Aan de lage kant (internetverbonden maar niet geclassificeerd) draait een curator-werkstation dezelfde Nexus- of Artifactory-versie als de high-side-instantie. De curator gebruikt de ingebouwde export/import-tooling van de repositorymanager of een gescripte workflow om goedgekeurde artefacten op te halen, hun transitieve afhankelijkheden op te lossen, checksums te verifiëren aan de hand van de gepubliceerde hashes van het upstream-register, en een ondertekend transferpakket samen te stellen. De ondertekeningsstap is kritiek: het transferpakket moet worden ondertekend met de transfersleutel van het programma zodat het high-side systeem de integriteit kan verifiëren voordat er iets wordt geïmporteerd.

# Low-side curator: assemble and sign the transfer bundle
nexus-curator export \
  --format maven \
  --repos approved-central-proxy \
  --output /transfer/bundle-2026-06-24.tar.gz

# Generate SHA-256 manifest
sha256sum /transfer/bundle-2026-06-24.tar.gz \
  > /transfer/bundle-2026-06-24.manifest

# GPG-sign the manifest with the program transfer key
gpg --detach-sign --armor \
  --local-user transfer@program.mil \
  /transfer/bundle-2026-06-24.manifest

# Physical transfer via encrypted removable media or data diode
# ...

# High-side import: verify before extracting
gpg --verify bundle-2026-06-24.manifest.asc \
              bundle-2026-06-24.manifest
sha256sum -c bundle-2026-06-24.manifest
nexus-curator import --file bundle-2026-06-24.tar.gz
            

Aan de high side bedient de Nexus- of Artifactory-instantie alleen gehoste repositories — er zijn geen proxyrepositories die verwijzen naar externe URL's, omdat die URL's onbereikbaar zijn. Configuratiebestanden voor buildagenttool verwijzen alleen naar de interne hostnaam. Een tabel van de configuratiebestanden die aanpassing vereisen:

De curatiecadans is een beleidsbeslissing: doorgaans maandelijks voor beveiligingspatches, kwartaalsgewijs voor nieuwe afhankelijkheidsversies, en direct voor elke CVE met een CVSS-score boven 8,0. Het Configuration Control Board van het programma is eigenaar van de beslissing over elke import.

STIG-geharde CI-server: Jenkins of GitLab op geclassificeerde infrastructuur

De twee meest voorkomende keuzes voor CI-uitvoering op geclassificeerde infrastructuur zijn Jenkins (de al lang dominante optie, wijdverbreid ingezet in DoD-programma's vanaf het midden van de jaren 2010) en GitLab (steeds meer de voorkeur voor nieuwe programma's vanwege de gepubliceerde DISA STIG en de geïntegreerde DevSecOps-functies). Beide kunnen conform worden gemaakt; de inspanning en het residuele risicoprofiel verschillen.

Voor Jenkins is de hardening-basislijn de DISA Application Server SRG gecombineerd met de RHEL 9 STIG voor het onderliggende besturingssysteem. De Jenkins-specifieke hardeningchecklist behandelt de volgende gebieden:

• Schakel de Jenkins CLI via remoting uit (CVE-2024-23897-klasse van kwetsbaarheden); gebruik CLI alleen via SSH indien nodig.
• Schakel Content Security Policy (CSP)-headers in om XSS in buildconsoleuitvoer te voorkomen.
• Schakel toegang tot de Script Console uit voor niet-beheerders; beperk Groovy sandbox-ontsnappingen.
• Configureer matrixgebaseerde beveiliging met het principe van minimale rechten: ontwikkelaars kunnen builds starten, maar kunnen geen agents of referenties beheren.
• Schakel de audit-log-plugin in; stuur logs door naar de enclave SIEM.
• Stel JENKINS_HOME in op een bestandssysteem met toegangscontroles; beperk wereldleesbare rechten op credentials.xml.
• Schakel updatesite-verbindingen uit (hudson.model.UpdateCenter.never=true in jenkins.properties).
• Voer Jenkins uit als een toegewijd niet-root serviceaccount; pas SELinux-contexten toe.

GitLab CE/EE op RHEL profiteert van de DISA GitLab Enterprise Edition STIG (V1R1, gepubliceerd 2022), die controls direct toewijst aan GitLab-configuratie-instellingen. Belangrijke controls zijn onder meer het afdwingen van minimaal TLS 1.2, het uitschakelen van aanmelding en OAuth-providers, het inschakelen van auditgebeurtenissen naar syslog, het beperken van het Git-protocol tot SSH via een bekende poort, en het uitschakelen van auto-DevOps-functies die uitgaande aanroepen doen. De geïntegreerde registry, merge request-workflow en pipeline-YAML-syntaxis van GitLab verminderen het aantal afzonderlijk geaccrediteerde componenten in vergelijking met een Jenkins-centrische stack, wat vaak de doorslaggevende factor is in programma's waar ATO-tijdlijnen beperkt zijn.

In beide gevallen moeten buildagents binnen dezelfde classificatiegrens als de controller draaien. Agentimages worden gebouwd van goedgekeurde basisimages die in het containerregister van de enclave worden bewaard, en worden op een vastgesteld schema herbouwd (doorgaans maandelijks) om OS-patchupdates te verwerken die via de curatiewerkflow worden overgedragen.

Ontkoppeld containerregister

Containerimages in een air-gapped pipeline moeten worden opgeslagen, gescand en ondertekend binnen de enclave. Twee producten zijn het meest gangbaar: Harbor (CNCF-afgestudeerd, veel gebruikt in DoD Platform One-omgevingen) en Red Hat Quay (ondersteund onder de DoD-enterprise Red Hat-overeenkomst, integreert nauw met OpenShift). Beide ondersteunen OCI-beeldondertekening, rolgebaseerde toegangscontrole en kwetsbaarheidsscanning met offline databases.

De initiële vulling van het register volgt dezelfde transferworkflow als het artefactregister: goedgekeurde basisimages (RHEL UBI, geharde Iron Bank-images, goedgekeurde applicatiebasislagen) worden geëxporteerd vanuit de lage kant als OCI-tarballs, overgedragen en geïmporteerd in Harbor of Quay met behulp van skopeo copy:

# Low side: export approved images as OCI tarballs
skopeo copy \
  docker://registry.access.redhat.com/ubi9/ubi:9.4 \
  oci-archive:/transfer/ubi9-9.4.tar \
  --override-os linux

# Generate and sign manifest
sha256sum /transfer/ubi9-9.4.tar >> /transfer/images.manifest
gpg --detach-sign --armor --local-user transfer@program.mil \
    /transfer/images.manifest

# High side: verify and import
gpg --verify images.manifest.asc images.manifest
sha256sum -c images.manifest
skopeo copy \
  oci-archive:/transfer/ubi9-9.4.tar \
  docker://harbor.enclave.mil/base/ubi9:9.4 \
  --dest-creds admin:${HARBOR_TOKEN}
            

Beeldondertekening met Cosign in offlinemodus gebruikt een langlevende ondertekeningssleutel die is opgeslagen in de Vault Transit-engine van de enclave, waarbij het Sigstore-transparantielogboek (dat op internet wordt gehost) wordt omzeild. De ondertekeningssleutel wordt gegenereerd binnen Vault en nooit geëxporteerd; de CI-pipeline roept de Transit API van Vault aan om de beelddigest te ondertekenen en koppelt de resulterende handtekening als OCI-artefact samen met het beeldmanifest in Harbor. Verificatie bij admissietijd wordt afgehandeld door een Kyverno-beleid dat de Cosign-verifier aanroept via Harbor met behulp van de interne PKI-vertrouwensbundel van de enclave.

# Sign image using Vault Transit key (no transparency log)
cosign sign \
  --key hashivault://transit/keys/image-signing-key \
  --no-tlog-upload \
  harbor.enclave.mil/myapp/service:v1.4.2@sha256:abc123...

# Kyverno policy: require valid Cosign signature on every pod
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["harbor.enclave.mil/*"]
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ... (enclave signing public key) ...
              -----END PUBLIC KEY-----
            rekor:
              ignoreTlog: true
            

Kwetsbaarheidsscanning binnen het register gebruikt Trivy of Grype geconfigureerd met een offline databasebundel. De kwetsbaarheidsdatabase (NVD, OSV, RedHat-adviezen) wordt gedownload aan de lage kant, overgedragen naar de hoge kant en geladen in het lokale databasepad van de scanner. Een dagelijkse pipelinetaak vernieuwt de databasebundel via de curatiewerkflow, waardoor de kennis van de scanner actueel blijft binnen de transfercadans.

De softwaretransportworkflow: sneakernet naar beveiligde updateserver

De term "sneakernet" dateert van voor CI/CD, maar het concept is precies wat air-gapped softwarelevering mogelijk maakt: fysiek transport van gegevens tussen netwerken van verschillende classificatieniveaus. In moderne geclassificeerde faciliteiten is dit transport gesystematiseerd in een gedocumenteerde workflow met verplichte gates, auditsporen en bewakingsvereisten die weerspiegelen wat geautomatiseerde supply chain-controls bieden in een verbonden omgeving. De uitdaging voor CI/CD-pipelines is dat de transportcyclustijd — doorgaans gemeten in dagen, niet milliseconden — moet worden ingebakken in het releaseplannigmodel.

De workflow heeft een gedefinieerde structuur:

Low-side workstation (UNCLASSIFIED)
    │
    ├─ [1] Assemble candidate package set
    │      - download, resolve transitive deps
    │      - verify upstream signatures/checksums
    │      - run malware scan (ClamAV / commercial AV)
    │      - run vulnerability scan (Grype offline db)
    │      - license review
    │
    ├─ [2] Generate signed manifest
    │      sha256sum * > manifest.txt
    │      gpg --detach-sign manifest.txt
    │
    ├─ [3] Submit transfer request (CMT/JIRA ticket)
    │      - package name, version, purpose, license
    │      - vulnerability scan results attached
    │
    ├─ [4] ISSO/AO review and approval (Gate)
    │
    ├─ [5] Physical transfer
    │      - encrypted USB (FIPS 140-2 validated)
    │      - OR hardware data diode (one-way)
    │      - transfer log entry created
    │
High-side secure update server (CLASSIFIED)
    │
    ├─ [6] Verify manifest signature
    │      gpg --verify manifest.txt.asc manifest.txt
    │      sha256sum -c manifest.txt
    │
    ├─ [7] Import into Nexus / Harbor
    │
    └─ [8] Log in configuration management tool
            

Pakketondertekening maakt gebruik van GPG met programmaspecifieke sleutels of — in programma's die PKI-gebaseerde tooling hebben geadopteerd — sigstore/cosign tegen de interne Rekor-instantie van het programma. Het sleutelpunt is dat de ondertekeningssleutel die wordt gebruikt voor transfermanifesten verschilt van de sleutel die wordt gebruikt voor het ondertekenen van buildartefacten. De transfersleutel wordt bewaard door de curateurrol, niet door geautomatiseerde buildagents, omdat de transfergoedkeuring een menselijke gate is die niet mag worden geautomatiseerd.

Voor programma's die hoogfrequente patchcycli uitvoeren, automatiseren eenrichtings hardware-datadiodes (zoals die van Owl Cyber Defense of Waterfall Security) de fysieke laag van de transfer terwijl de eenrichtingsgarantie behouden blijft. Gegevens stromen alleen van laag naar hoog; het high-side systeem kan geen enkel verkeer terugsturen. Dit elimineert de goedkeuringsgate niet, maar elimineert wel de stap met fysieke verwijderbare media en kan worden gebruikt om nachtelijke patchbundels op een vastgesteld schema door te sturen. Zie onze bredere behandeling van supply chain-beveiliging voor defensiesoftware voor het beleidskader dat bepaalt wat de transferworkflow binnenkomt.

Automatisering van STIG-naleving in de pipeline

Handmatige STIG-checklists zijn onverenigbaar met een tempo van continue levering. Een build die dagelijks wordt ingezet, kan niet vóór elke release handmatig worden gecontroleerd aan de hand van 300+ STIG-controls. De oplossing is naleving als code: het coderen van de STIG-controls als machinecontroleerbaar beleid, het uitvoeren van het beleid in de pipeline als geautomatiseerde gate, en het genereren van gestructureerd bewijs dat voldoet aan de vereisten voor continue monitoring van de AO.

De primaire toolchain is OpenSCAP met de SCAP Security Guide (SSG). SSG levert XCCDF/OVAL-inhoud voor RHEL 8, RHEL 9 en aanverwante distributies die direct is toegewezen aan DISA-STIGs. In een air-gapped omgeving wordt de SSG-inhoud gebundeld in het buildagentimage in plaats van te worden gedownload tijdens de uitvoering:

# Pipeline stage: STIG scan of a deliverable container image
stages:
  - build
  - stig-scan
  - sign
  - promote

stig-scan:
  stage: stig-scan
  image: harbor.enclave.mil/tools/openscap-runner:latest
  script:
    - |
      # Mount the container image filesystem for scanning
      skopeo copy \
        docker://harbor.enclave.mil/${CI_PROJECT_PATH}:${CI_COMMIT_SHA} \
        oci:./image-under-test

      # Run STIG profile evaluation
      oscap-chroot ./rootfs xccdf eval \
        --profile xccdf_org.ssgproject.content_profile_stig \
        --results stig-results.xml \
        --report stig-report.html \
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

      # Block on any CAT I (high severity) failures
      python3 /tools/parse-stig-results.py \
        --results stig-results.xml \
        --fail-on-severity high \
        --output stig-summary.json

  artifacts:
    paths:
      - stig-results.xml
      - stig-report.html
      - stig-summary.json
    expire_in: 90 days
            

De DISA STIG Viewer-applicatie kan de results.xml-uitvoer van OpenSCAP inlezen en weergeven in het vertrouwde checklistformaat dat AO's en ISSO's gebruiken tijdens reviews. Voor programma's die een dashboard voor continue monitoring beheren (doorgaans gevoed door een SIEM of een GRC-tool), wordt de gestructureerde JSON-uitvoer van het parsescript als pipeline-artefact naar de bewijsrepository gepusht naast de build.

Een veelvoorkomend patroon is het scheiden van STIG-scanning op hostniveau (uitgevoerd door het infrastructuurteam op de buildagentbasisimages op een maandelijkse cadans) van STIG-scanning op imageniveau (uitgevoerd door de applicatiepipeline bij elke build op de te leveren container). Bevindingen op hostniveau beïnvloeden de ATO van de CI-infrastructuur zelf en worden bijgehouden in de POA&M van het systeem. Bevindingen op imageniveau worden bijgehouden op applicatieniveau en vallen onder de verantwoordelijkheid van het ontwikkelteam. Het auditspoor maakt duidelijk onderscheid welk team eigenaar is van welke bevinding, wat belangrijk is wanneer een accrediteur het bewijspakket voor continue monitoring beoordeelt.

Voor SBOM-handhaving in defensiepipelines vult de STIG-scanuitvoer het SBOM aan door bewijs te leveren dat de runtime-omgeving waarin het artefact zal worden uitgevoerd ook conform is — niet alleen de softwarecomponenten van het artefact.

Geheimbeheer zonder internet: HashiCorp Vault in air-gapmodus

Geheimbeheer is de component die het meest waarschijnlijk slecht wordt geïmproviseerd in air-gapped omgevingen. De gebruikelijke improvisatie — het opslaan van referenties in het ingebouwde referentiestore van de CI-server, of in een gedeelde wachtwoordmanager, of in omgevingsvariabelen die zijn ingebakken in agentimages — faalt bij dezelfde auditcontroles die een verbonden omgeving zou falen. De goedgekeurde oplossing is een dedicated geheimbeheersysteem dat binnen de accreditatiegrens is ingezet.

HashiCorp Vault OSS (open-source, niet Enterprise) vereist geen internetverbinding voor de werking. Het is te implementeren op een STIG-geharde RHEL-host binnen de enclave, geïnitialiseerd met een Shamir secret sharing-sleutelsplitsing verdeeld over geautoriseerde sleutelbeheerders:

# Initialize Vault with 5 key shares, threshold of 3
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# Example output (each share goes to a separate custodian):
# Unseal Key 1: AbCdEf...
# Unseal Key 2: GhIjKl...
# Unseal Key 3: MnOpQr...
# Unseal Key 4: StUvWx...
# Unseal Key 5: YzAbCd...
# Initial Root Token: hvs.XXXXXX (use once, then revoke)

# Unseal using 3 of 5 shares (separate operator ceremony)
vault operator unseal  # enter share 1
vault operator unseal  # enter share 2
vault operator unseal  # enter share 3
            

PKI-bootstrapping in een air-gapped omgeving gebruikt de ingebouwde PKI-geheimensengine van Vault om de certificaatinfrastructuur van het programma te beheren. Het proces: genereer een root-CA-sleutel en -certificaat offline (op een air-gapped werkstation, niet binnen Vault), sla de root-CA-sleutel op in een hardware-HSM of versleutelde offlineback-up conform het sleutelbeheerplan van het programma. Importeer het root-CA-certificaat in Vault. Genereer binnen de PKI-engine van Vault een tussenliggende CA-sleutelpaar en CSR, onderteken de CSR met de root-CA (offline stap), importeer het ondertekende tussenliggende certificaat in Vault. Vanaf dit punt geeft Vault alle kortlevende TLS-certificaten uit voor enclavediensten — de CI-server, het artefactregister, het containerregister, de geheimensmanager zelf — zonder enige externe CA-afhankelijkheid.

CI-agentauthenticatie gebruikt de AppRole-authmethode van Vault. Elke buildagent wordt ingericht met een role_id (niet-geheim, kan in agentconfiguratie staan) en een secret_id (kortlevend, geïnjecteerd door de infrastructuurprovider bij het opstarten van de agent). De agent wisselt deze in voor een Vault-token dat alleen is beperkt tot de geheimen die zijn builds vereisen. Tokens zijn kortlevend (standaard 1 uur, verlengbaar tijdens de build) en verlopen automatisch na het voltooien van de build. Dit patroon betekent dat een gecompromitteerde buildagent geen persistente toegang heeft tot geheimen — hij houdt alleen een token dat verloopt, geen referentie die voor onbepaalde tijd blijft bestaan.

Geheimrotatie zonder internettoegang volgt een geplande ceremonie: kwartaalsgewijze rotatie van statische geheimen (API-sleutels, serviceaccount-wachtwoorden), jaarlijkse rotatie van ondertekeningssleutels. De ingebouwde rotatiebeleiden van Vault regelen de timing; de uitvoer van elke rotatie wordt vastgelegd in het auditlogboek van Vault, dat wordt doorgestuurd naar de enclave SIEM. Voor dynamische geheimen — databasereferenties, PKI-certificaten — genereren de dynamische geheimensengines van Vault per-build-referenties met korte TTL's, waardoor rotatie een niet-gebeurtenis wordt omdat elke referentie al ephemeral is.

De operationele discipline die nodig is om deze stack te beheren, is niet triviaal. Curateursfuncties, transfergoedkeuringsprocedures, sleutelbeheerdersceremonies en maandelijkse scancadansen zijn organisatorische verplichtingen, geen eenmalige engineeringbeslissingen. Programma's die investeren in het documenteren van deze procedures als onderdeel van het System Security Plan (SSP) in plaats van als informele stammenkennis zijn aanzienlijk veerkrachtiger bij personeelsverloop — wat, gezien de vereisten voor veiligheidsclearing en de defensiearbeidsmarkt, een reëel operationeel risico is op elk langlopend programma.

Voor de supply chain-beleidslaag die bepaalt wat de pipeline binnenkomt, zie ons artikel over SBOM-handhaving in defensiepipelines. De hier beschreven air-gapped CI-stack is de uitvoeringslaag; SBOM-handhaving en het bredere DevSecOps voor defensiepipelines-kader zijn de beleidslaag die bepaalt wat de pipeline bouwt, scant en bevestigt.