Cryptografische stuklijst (CBOM): de sleutel tot het beveiligen van uw software-toeleveringsketen

Kort antwoord: Een cryptografische materiaallijst (CBOM) is een gestructureerde inventaris van elk algoritme, elke sleutel, elk certificaat, elk protocol en elke cryptografische bibliotheek die uw software en infrastructuur gebruiken, gebaseerd op de OWASP CycloneDX-standaard. Dit is belangrijk omdat u niet kunt overstappen van cryptografie die kwetsbaar is voor kwantumaanvallen of compliance kunt aantonen zonder te weten waar deze informatie zich bevindt. Begin met het scannen van uw code, certificaten en runtime-omgevingen om een ​​basislijn vast te stellen.

Aanvallen op de toeleveringsketen zijn divers en treffen zowel bedrijven als overheidsinstanties. Commerciële software en open-sourcepakketten zijn beide doelwitten, waardoor een helder inzicht in alle software en cryptografische elementen in uw ontwikkelings- en implementatieprocessen een basisvereiste is, geen luxe. 

In 2020 bracht de SolarWinds-aanval op de toeleveringsketen duizenden organisaties en meerdere Amerikaanse overheidsinstanties in gevaar nadat aanvallers een backdoor genaamd SUNBURST in de Orion IT-updatetool hadden geïnjecteerd. In februari 2021 hackte beveiligingsonderzoeker Alex Birsan de systemen van Microsoft, Tesla, Uber en Apple met behulp van een techniek genaamd dependency confusion, waarbij interne buildsystemen werden misleid om kwaadaardige openbare pakketten te downloaden in plaats van vertrouwde interne pakketten.

Als reactie hierop vaardigde de Amerikaanse overheid in mei 2021 Executive Order 14028 uit, getiteld "Improving the Nation's Cybersecurity", waarin softwareleveranciers die aan federale instanties verkopen, verplicht worden een Software Bill of Materials (SBOM) te verstrekken. Een SBOM is een machineleesbare lijst van elke module, bibliotheek en externe afhankelijkheid in een softwarepakket, samen met metadata zoals licentie en versie, zodat een beveiliger snel componenten kan identificeren en patchen die getroffen zijn door een aanval in de toeleveringsketen. 

NIST adviseerde vervolgens om de SBOM-praktijk uit te breiden met een Cryptography Bill of Materials (CBOM) als onderdeel van de richtlijnen voor de migratie naar post-quantumcryptografie (PQC), met name in de praktijkhandleiding SP 1800-38 van het National Cybersecurity Center of Excellence van het National Institute of Standards and Technology (NIST) . Deze aanbeveling is inmiddels geformaliseerd: CBOM is nu een integraal onderdeel van de OWASP CycloneDX Bill of Materials-standaard, die in versie 1.6 ondersteuning voor cryptografische assets heeft toegevoegd en is gepubliceerd als de ECMA-424-standaard.

Key Takeaways

• Een CBOM is een gestructureerde inventaris van algoritmen, sleutels, certificaten, protocollen en cryptografische bibliotheken, gestandaardiseerd onder OWASP CycloneDX (nu gepubliceerd als ECMA-424).
• In tegenstelling tot een SBOM, die softwarecomponenten opsomt, geeft een CBOM een overzicht van de cryptografie die die componenten daadwerkelijk gebruiken. Daarmee vormt het het uitgangspunt voor de planning van de migratie naar een post-kwantumtijdperk.
• Het concept-tijdschema van NIST voor IR 8547 stelt voor om RSA, ECDSA, ECDH en eindige-veld Diffie-Hellman na 2030 uit te faseren en na 2035 volledig te verbieden. Dit tijdschema wordt nu voor federale systemen ondersteund door Executive Order 14412 en OMB Memorandum M-26-15.
• Een compleet CBOM-programma gaat verder dan een eenmalige scan: het classificeert activa op basis van risico, past toegangscontroles toe op sleutels, beheert de cryptografische levenscyclus en koppelt bevindingen aan compliancekaders zoals PCI DSS en GDPR.
• CBOM-tools hebben wel degelijk beperkingen, waaronder blinde vlekken voor configuratiegestuurde cryptografie en verouderde binaire bestanden. Beschouw het daarom als een doorlopend proces in plaats van een eenmalige audit.

Wat is een cryptografische stuklijst (CBOM)? 

Een cryptografische stuklijst (CBOM) is een machinaal leesbare inventaris die alle cryptografische componenten in een systeem catalogiseert: algoritmen en hun parameters (sleutelgroottes, modi), sleutels, digitale certificaten, cryptografische bibliotheken en de protocollen die deze gebruiken. CBOM is geformaliseerd als een uitbreiding van de OWASP CycloneDX-standaard, hetzelfde full-stack stuklijstformaat dat wordt gebruikt voor SBOM, SaaSBOM en hardware-BOM. Waar een SBOM aangeeft welke softwarecomponenten en -versies u gebruikt, geeft een CBOM aan welke cryptografie die componenten daadwerkelijk gebruiken, informatie die een SBOM alleen niet vastlegt.

CBOM versus SBOM: Wat is het verschil?

Een SBOM inventariseert softwarecomponenten: bibliotheken, afhankelijkheden, en hun versies en licenties. Een CBOM inventariseert de cryptografie binnen en rondom die componenten. De twee zijn complementair, en de eigen PQC-migratierichtlijnen van NIST beschouwen CBOM als een uitbreiding van de SBOM-praktijk in plaats van een vervanging ervan.

Aspect	SBOM	CBOM
Tracks	Softwarecomponenten, versies, licenties	Algoritmen, sleutelgroottes, certificaten, protocollen
Primaire bestuurder	Uitvoeringsbesluit 14028 (2021), risico's in de toeleveringsketen	NIST PQC-richtlijnen voor migratie na kwantummigratie
Standaard formaat	CycloneDX, SPDX	CycloneDX cryptografie-uitbreiding (ECMA-424)
antwoorden	Welke software gebruik ik?	"Welke cryptografie gebruikt die software, en is die kwantumveilig?"

Wat moet een CBOM-inventaris bevatten? 

Een complete CBOM vult een standaard SBOM-inventaris (besturingssysteem, web-/applicatieservers, SSL/TLS-bibliotheken zoals OpenSSL, configuratie- en logbeheertools) aan met de specifieke cryptografische details waarop die componenten gebaseerd zijn. In de praktijk betekent dit dat zes categorieën van assets worden vastgelegd.

Categorie	Voorbeelden	Waarom dit zo belangrijk is
Algoritmen	RSA, ECDSA, AES, SHA-2/SHA-3	Identificeert welke algoritmen kwetsbaar zijn voor kwantumberekeningen en welke kwantumveilig zijn.
Keys	Sleutelgrootte, -type, opslaglocatie	Vlaggen die te klein zijn of waarvan het sleutelmateriaal onjuist is opgeslagen.
Certificaten	X.509-certificatenvervaldatums	Het systeem detecteert verlopende of zwak ondertekende certificaten voordat ze een storing veroorzaken.
protocollen	TLS / SSL versies, SSH, VPN-configuraties	Onthult dat verouderde protocolversies nog steeds in productie zijn.
Bibliotheken en modules	OpenSSL, BoringSSL, taalspecifieke cryptografische bibliotheken	Koppelt bekende CVE's rechtstreeks aan de systemen die ze gebruiken.
Hardware	HSM'sIoT en ingebedde apparaten	Vergroot het inzicht niet alleen in de software, maar ook in de hardware die het vertrouwen schept.

Een cryptografisch governancekader bouwen rondom uw CBOM

Een CBOM is slechts zo nuttig als het governanceprogramma dat erop is gebouwd. Zodra je elk algoritme, elke sleutel en elk certificaat in je omgeving kunt zien, is de volgende stap bepalen wat je met elk ervan wilt doen: hoe je het classificeert, of je de gegevens erachter versleutelt of tokeniseert, wie er toegang toe heeft, hoe de levenscyclus ervan wordt beheerd, hoe je herstelt als het faalt, hoe je het in de toekomst monitort en hoe het aansluit op de compliance-frameworks waaraan je moet voldoen.

Cryptografische activa classificeren op basis van risico

Niet elke vermelding in een CBOM heeft dezelfde urgentie. Classificatie betekent dat elk algoritme en elke sleutel wordt beoordeeld op basis van de kwetsbaarheid voor kwantumkwetsbaarheden en de gevoeligheid of bewaartermijn van de gegevens die het beschermt. Zo kunt u prioriteit geven aan migratie in plaats van een inventaris van 5,000 regels als een platte takenlijst te behandelen.

Algoritme of sleuteltype	NIST IR 8547 conceptstatus	Aanbevolen actie
RSA-2048, ECC P-256 (~112-bits beveiliging)	Voorgesteld, na 2030 afgeschaft.	Plan de migratie nu; geef prioriteit aan gegevens met een lange vertrouwelijkheidsperiode.
RSA-3072, ECC P-384 (varianten met hogere sterkte)	Voorstel niet toegestaan ​​na 2035	Migreer vóór 2035; grotere sleutelgroottes geven je tijd, maar geen vrijstelling.
ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Definitieve NIST-normen, augustus 2024	Doelalgoritmen voor nieuwe implementaties en migratie
AES-256, SHA-2, SHA-3	Niet opgenomen in het schema voor het uitfaseren van publieke sleutels van IR 8547.	Geen gedwongen migratie; blijf de belangrijkste beheerpraktijken controleren.

NIST IR 8547 is medio 2026 nog steeds een eerste openbaar concept, dus beschouw deze data als een indicatie van de toekomstige ontwikkeling en niet als een definitieve regelgeving. Desondanks hebben Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks", ondertekend op 22 juni 2026, en OMB Memorandum M-26-15, uitgegeven op 24 juni 2026, de horizon van 2030 van IR 8547 al omgezet in een bindend migratieplan in vijf fasen voor waardevolle federale activa en systemen met een grote impact, waarbij de migratieplannen van de agentschappen in oktober 2026 moeten worden ingediend. De order definieert zelfs een nieuwe rol als "PQC migration lead", die expliciet verantwoordelijk is voor het agentschapsbrede beheer van de cryptografische inventaris, precies waarvoor een CBOM is opgericht.

Kies tussen encryptie en tokenisatie.

Uw CBOM (Content-Based Operations Model) laat u zien waar gevoelige gegevens een bepaald algoritme kruisen, en dat is precies de informatie die u nodig hebt om de juiste beveiligingsmaatregel te kiezen. Gebruik encryptie wanneer de applicatie de oorspronkelijke waarde moet kunnen herstellen of wanneer gegevens worden verplaatst tussen systemen waarover u geen volledige controle hebt. Gebruik tokenisatie wanneer u gevoelige waarden (betaalkaartnummers zijn een klassiek voorbeeld) volledig uit een systeem wilt verwijderen en de compliance-eisen van dat systeem wilt verlagen, aangezien een token geen wiskundige relatie heeft met de oorspronkelijke waarde en niet kan worden teruggedraaid zonder de aparte kluis die het heeft uitgegeven.

Handhaaf toegangscontroles op sleutels en certificaten.

Elke sleutel en elk certificaat dat uw CBOM beschikbaar stelt, heeft een eigenaar en een toegangsbeleid nodig. Dat betekent rolverdeling tussen de mensen die sleutels aanvragen en de mensen die ze goedkeuren of uitgeven, opslag in een hardwarebeveiligingsmodule in plaats van platte bestanden of broncode, en geplande rotatie van referenties in plaats van sleutels die jarenlang ongewijzigd blijven. Een CBOM zonder toegangsbeheer documenteert alleen het probleem; het lost het niet op.

Beheer de levenscyclus van cryptografische activa.

Elke vermelding in een CBOM doorloopt een levenscyclus: uitgifte, rotatie, verlenging, intrekking en verwijdering. Governance houdt in dat wordt gedefinieerd wie elke fase activeert en hoe dit wordt vastgelegd, zodat een verlopend certificaat of een algoritme dat wordt uitgefaseerd, wordt ingepland voor werkzaamheden in plaats van als een storing te worden geregistreerd.

Plan je herstel voordat je het nodig hebt.

Een CBOM (Certificate Business Operations Management) identificeert welke sleutels en certificeringsinstanties de belasting van uw bedrijf dragen. Dit is precies de lijst die u nodig hebt voor een rampenherstelplan. Dat betekent procedures voor sleutelbeheer en back-ups van encryptiesleutels, een gedocumenteerd herstelpad voor een gecompromitteerde of niet-beschikbare certificeringsinstantie en periodieke hersteltests, en niet alleen een back-up die nooit is teruggezet.

Continue monitoring is essentieel, niet alleen tijdens audits.

Een CBOM die eenmaal per jaar wordt gegenereerd, is verouderd op de dag dat een nieuwe afhankelijkheid wordt uitgebracht. Continue monitoring betekent dat er bij elke build of implementatie opnieuw wordt gescand, dat er een waarschuwing wordt gegeven bij het verlopen van certificaten voordat dit tot downtime leidt, en dat er een afwijking wordt gesignaleerd wanneer nieuwe code een algoritme of sleutelgrootte introduceert die buiten de goedgekeurde basislijn valt.

Koppel bevindingen aan nalevingsvereisten

Een actuele CBOM (Cryptography-Based Operations Manual) is direct bewijs voor de cryptografiegerelateerde controles in PCI DSS, HIPAA, GDPR en ISO/IEC 27001 Annex A, en wordt ook steeds relevanter voor EU-specifieke verplichtingen: de EU Cyber ​​Resilience Act en DORA verhogen beide de druk voor verifieerbare, volledige zichtbaarheid van de cryptografie die is ingebed in producten en systemen in de financiële sector. Door elke CBOM-vermelding te koppelen aan de specifieke controle waaraan deze voldoet, wordt een inventarislijst omgezet in auditbewijs.

Hoe bouw je een CBOM: een proces in vier stappen?

Het opbouwen van een CBOM is een iteratief proces, geen eenmalige scan. Deze vier stappen omvatten de ontdekking tot en met automatisering.

1. Ontdek de cryptografische entiteiten:

   Identificeer cryptografische entiteiten in uw systeem: applicaties van derden (databases, configuratiebeheer en automatiseringstools), broncode, data in rust (configuratiebestanden, digitale certificaten , wachtwoorden en sleutels), data in beweging ( SSL/TLS -protocollen en VPN-configuraties) en hardware ( HSM's en IoT-apparaten).

2. De inventaris genereren en bijhouden:

   Bepaal wanneer je inventarisatie moet genereren in elke fase van ontwikkeling en implementatie. Elke fase moet de vorige aanvullen, zodat de link tussen de introductie en het gebruik van een component behouden blijft. Op die manier kun je kwetsbaarheden traceren en verhelpen. Verschillende belanghebbenden hebben verschillende behoeften: een productteam is doorgaans geïnteresseerd in broncode, afhankelijkheden en applicatieconfiguratie, terwijl IT-operations een breder perspectief nodig heeft dat software, PKI , SaaS, netwerk, data en hardware omvat.

3. Regelmatig controleren en evalueren:

   Plan regelmatige audits in om te bevestigen dat cryptografische entiteiten nog steeds voldoen aan de huidige beveiligingsnormen en om eventuele afwijkingen op te sporen: kwetsbare sleutelgroottes, zwakke algoritmen, certificaten die aan vernieuwing of intrekking toe zijn.

4. Automatiseer en integreer in CI/CD:

   Handmatige scans op een specifiek tijdstip zijn niet schaalbaar voor meer dan een handvol repositories. Open-source tools, gebaseerd op het CycloneDX CBOM-schema, kunnen samen met commerciële scanners automatisch cryptografische metadata extraheren uit broncode, containers en infrastructure-as-code templates. Door CBOM-generatie te integreren in je CI/CD-pipeline, wordt het geen jaarlijkse audit, maar een live, versiebeheerd artefact.

Hoe verbetert CBOM uw beveiligingsniveau? 

Een CBOM (Computer-Based Object Management) biedt uw organisatie gedetailleerd inzicht in de cryptografische activa die gekoppeld zijn aan elk commercieel en open-source component dat u gebruikt. Dit verbetert uw beveiligingspositie op drie concrete manieren. Ten eerste versterkt het de crypto-flexibiliteit: u kunt proactieve stappen ondernemen tegen aanvallen op de toeleveringsketen en sneller reageren wanneer er een aanval plaatsvindt, omdat u al weet welke componenten getroffen zijn. Ten tweede vermindert het de operationele en financiële gevolgen van een inbreuk; zonder een CBOM is het identificeren van alle blootgestelde activa na een incident een traag en handmatig proces, en die vertraging is kostbaar. Ten derde ondersteunt een actuele CBOM-inventaris direct de afstemming op wettelijke kaders zoals de NIST-richtlijnen, ISO 27001 en de AVG (Algemene Verordening Gegevensbescherming).

Omdat een CBOM een gedetailleerd overzicht geeft van uw cryptografische activa, is het ook de input voor de planning van de migratie van kwantumkwetsbare algoritmen zoals RSA , DSA, ECDSA en ECDH naar de door NIST gestandaardiseerde post-kwantumalgoritmen: ML-KEM (FIPS 203), ML-DSA (FIPS 204) en SLH-DSA (FIPS 205), die allemaal in augustus 2024 worden afgerond. U kunt een migratie niet plannen als u deze niet kunt overzien, en een CBOM maakt die planning mogelijk.

Wat zijn de beperkingen van een CBOM? 

Een CBOM is een noodzakelijk hulpmiddel, geen complete oplossing, en het is de moeite waard om realistisch te zijn over de tekortkomingen ervan.

• Naamgevingsambiguïteit: Verschillende scantools kunnen hetzelfde algoritme onder verschillende namen of parametergroeperingen rapporteren, wat vergelijkingen tussen tools bemoeilijkt.
• Configuratiegestuurde cryptografie: Cipher suites en algoritmekeuzes die tijdens de uitvoering of via configuratie in plaats van code worden geselecteerd, zijn moeilijker te detecteren door middel van statische analyse alleen.
• Aanbod versus consumptie: Een CBOM moet onderscheid kunnen maken tussen een component die cryptografie implementeert en een component die slechts de implementatie van een andere bibliotheek aanroept, en dat onderscheid is niet altijd duidelijk uit de broncode.
• Dekkingslacunes: Gecompileerde binaire bestanden, firmware en oudere systemen zonder toegang tot de broncode zijn moeilijker te scannen dan moderne applicaties waarvan de broncode wel beschikbaar is.
• Het probleem met momentopnamen: Een CBOM is alleen accuraat op het moment dat deze is gegenereerd. Zonder continue scanning raakt de informatie net zo snel verouderd als bij uw volgende implementatie.

Een praktijkvoorbeeld: het migreren van een verouderde certificeringsinstantie.

Hier is hoe de bovenstaande onderdelen in de praktijk samenkomen. Een CBOM-scan van een interne certificeringsinstantie brengt duizenden actieve certificaten aan het licht die nog steeds zijn uitgegeven met 2048-bits RSA-sleutels. Door deze bevinding te vergelijken met de bovenstaande classificatietabel, wordt RSA-2048 aangemerkt als een certificering die na 2030 zal worden uitgefaseerd volgens de concept-IR 8547-tijdlijn van NIST. Het beveiligingsteam kent hier vervolgens een migratieprioriteit aan toe op basis van hoe lang de beschermde gegevens van elk certificaat vertrouwelijk moeten blijven. Certificaten die gekoppeld zijn aan langlevende gegevens (ondertekende firmware, archiefgegevens) worden als eerste ingepland; kortlevende, frequent geroteerde certificaten worden als laatste ingepland. Het team gebruikt vervolgens een PKI-as-a-Service-platform om hybride certificaten uit te geven die de bestaande RSA-handtekening combineren met een ML-DSA-handtekening, zodat gebruikers die nog geen post-kwantumalgoritmen ondersteunen, tijdens de overgang kunnen blijven werken. De CBOM wordt na elke migratiegolf opnieuw gescand om te bevestigen dat het aantal RSA-2048-gevallen daadwerkelijk daalt, in plaats van ervan uit te gaan dat het plan op schema ligt.

Hoe kan Encryption Consulting u helpen? 

CBOM Secure is het platform van Encryption Consulting voor het ontdekken en inventariseren van cryptografie. Het scant uw omgeving op algoritmen, sleutels, certificaten en protocollen, bouwt een op CycloneDX gebaseerde CBOM en markeert zwakke of kwantumkwetsbare cryptografie, zodat uw team prioriteit kan geven aan migratie op basis van bewijs in plaats van giswerk.

Zodra uw CBOM is opgebouwd, zetten de PQC Advisory Services van Encryption Consulting deze inventaris om in een stapsgewijs migratieplan: een gedetailleerde risicobeoordeling van uw on-premises, cloud- en SaaS-omgevingen, een strategie en stappenplan om de kwantumkwetsbare cryptografie die de CBOM aan het licht brengt te beperken, en praktische ondersteuning bij de implementatie van de technologieën en processen die u naar een kwantumbestendige omgeving leiden. Ondersteund door ISO/IEC 27001:2022 en SOC 2-gecertificeerde werkwijzen.

Lees voor meer informatie hoe een cryptografische inventaris bijdraagt ​​aan een bredere crypto-flexibiliteitsstrategie , waar kopers op moeten letten bij post-quantum-ready PKI-as-a-Service en waar CBOM past in het vijfstappenmodel voor PQC-volwassenheid van Encryption Consulting.

Conclusie

Het identificeren en beheren van de software- en cryptografische activa van uw organisatie via respectievelijk SBOM en CBOM vormt de basis voor de verdediging tegen zowel aanvallen op de softwareleveringsketen als cryptografische aanvallen. Een CBOM die eenmaal is opgezet en verder ongemoeid wordt gelaten, is slechts marginaal beter dan helemaal geen CBOM; de waarde zit hem in de combinatie met classificatie, toegangscontrole, lifecycle governance, herstelplanning, continue monitoring en compliance mapping, en vervolgens in het actueel houden ervan naarmate uw systemen veranderen en de deadlines voor post-quantummigratie dichterbij komen.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen een CBOM en een SBOM?

Een SBOM (Software Bill of Materials) geeft een overzicht van de softwarecomponenten, bibliotheken en afhankelijkheden in een applicatie, samen met metadata zoals versie en licentie. Een CBOM (Cryptographic Bill of Materials) geeft een overzicht van de cryptografische middelen die deze componenten gebruiken: algoritmen, sleutelgroottes, certificaten en protocollen. NIST beschouwt CBOM als een uitbreiding van de SBOM-praktijk, specifiek voor de planning van de migratie naar cryptografie na het kwantumtijdperk.

Welk formaat moet een CBOM gebruiken?

Het meest gebruikte formaat is OWASP CycloneDX, dat in versie 1.6 native ondersteuning voor cryptografische activa heeft toegevoegd en nu is gepubliceerd als de ECMA-424-standaard. Door een standaardformaat te gebruiken in plaats van een eigen spreadsheet, werkt uw CBOM met het groeiende ecosysteem van open-source en commerciële CycloneDX-tools.

Wie is binnen een organisatie verantwoordelijk voor het onderhouden van een CBOM?

De verantwoordelijkheid wordt doorgaans verdeeld op basis van de reikwijdte: product- en applicatiebeveiligingsteams beheren de CBOM voor broncode en applicatieafhankelijkheden, terwijl IT-operations of een speciale cryptografische governancefunctie de bredere inventaris beheert, inclusief PKI, netwerk, cloud en hardware. Federale instanties formaliseren dit nu via Executive Order 14412, waarmee een specifieke PQC-migratieleider is aangesteld die verantwoordelijk is voor het beheer van de cryptografische inventaris binnen de gehele instantie.

Hoe ondersteunt een CBOM de migratie naar cryptografie na kwantumtechnologie?

Een CBOM (Content-Based Operations Map) identificeert precies waar kwantumgevoelige algoritmen zoals RSA en ECDSA worden gebruikt. Hierdoor kunt u migratie prioriteren op basis van gegevensgevoeligheid en bewaartermijn, in plaats van systemen in een willekeurige volgorde te migreren. Deze prioritering maakt het mogelijk om deadlines te halen zoals de door NIST voorgestelde uitfasering in 2030 en het verbod in 2035 voor klassieke publieke-sleutelalgoritmen.

Kan een CBOM geautomatiseerd worden, of zijn handmatige controles nodig?

Beide. Geautomatiseerde tools, gebouwd op het CycloneDX CBOM-schema, kunnen cryptografische metadata extraheren uit broncode, containers en infrastructure-as-code-templates als onderdeel van een CI/CD-pipeline, waardoor de inventaris actueel blijft. Periodieke handmatige audits blijven echter belangrijk om configuratiegestuurde cryptografie en verouderde systemen op te sporen die geautomatiseerde scanners niet volledig kunnen bereiken.