Målgruppe
Denne artikkelen er skrevet for innkjøpsansvarlige, IT-ansvarlige i skoledistrikt og sikkerhetsarkitekter som vurderer OEM-lesepennpartnere under ENISA, NIS2 eller amerikanske K12-innkjøpsrammeverk. Den forklarer hvordan en kinesisk ODM bygger verifiserbar forsyningskjedetransparens for en stemmeaktivert enhet for barn ved hjelp av SBOM, fastvareproveniens, versjonslåsing av avhengigheter og signerte artefaktkjeder. Den forutsetter grunnleggende kjennskap til fastvareleveranse, men ingen spesialisert cybersikkerhetsbakgrunn. Interne referanser dekker relatert JTAG-låsing, sidekanalmotstand, CVE-håndtering, sertifiseringsplaner og personvern for elevdata.
En lesepenn produsert av vår Shenzhen ODM-linje har 14 000 til 21 000 individuelle programvarekomponenter når du teller hver transitiv bibliotek, MCU HAL-driver, Bluetooth-stakkmodul, Wi-Fi-firmware-blob, OCR-motor, TTS-stemmemoell og bootloader. En enkelt kompromittert pakke hvor som helst i denne avhengighetsgrafen kan skyve signert firmware til en enhet som ender i hånden på en 7-åring. Kaseya-hendelsen i 2021 og xz-utils-hendelsen i 2024 viste at selv modne oppstrømsvedlikeholdere sender ut bakdører. For en stemmeenhet for barn i kategori 3 er den eneste forsvarslinjen verifiserbar proveniens – og proveniens starter med en ekte SBOM.
Denne artikkelen går gjennom hvordan vårt OEM-program produserer, signerer, publiserer og reviderer SBOM-er for lesepenn-plattformene B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2 og Y6, og hvordan en kjøper kan verifisere at det vi sender er det vi har bygget.
Hva er en Software Bill of Materials – og hvorfor er det viktig for en lesepenn?
En SBOM er en maskinlesbar oversikt over hver programvarekomponent i et sendt artefakt. For en lesepenn er artefaktet firmware-imaget som produksjonslinjen flasher på en 32 MB eller 64 MB SPI NOR-flash. De to dominerende formatene er:
- SPDX 2.3 (ISO/IEC 5962:2024) – den ISO-ratifierte standarden med bredere støtte for bedriftsverktøy.
- CycloneDX 1.5 – vedlikeholdt av OWASP, lettere, med eksplisitt støtte for hardware BOM (HBOM) og Vulnerability Exploitability eXchange (VEX).
Hver lesepenn vi sender leveres med begge formater i den sikre oppdateringspakken. SBOM-en ligger ved siden av firmware-imaget, en løsrevet ECDSA-P256-signatur og en hardware-manifest. Det er denne pakken som ankommer kjøperens mottaksdokk.
Den amerikanske Executive Order 14028 (mai 2021) og EUs Cyber Resilience Act (trer i kraft 2027) krever begge en SBOM for enhver nettverkstilkoblet enhet som selges til føderale eller EU-forbrukere. Lesepenner kvalifiserer som nettverkstilkoblede enheter når de leveres med Wi-Fi- eller 4G-moduler på plattformene Q6, Q8 og Y6. Skoleinnkjøp under Californias MTSS-retningslinjer, New York State Education Departments CPL og Texas DIR-CPO-5417 viser i økende grad til NTIAs «minimum elements»-SBOM-grunnlinje.
Anatomi av en lesepenns firmware-avhengighetstre
En typisk K7- eller F8-produksjonsbygg henter programvare fra syv forsyningsnivåer:
| Nivå | Komponenttype | Eksempel | Opprinnelse | Risikovektor |
|---|---|---|---|---|
| 0 | Leverandør-silisium | Allwinner A133, Rockchip RK3566 | Fastlands-fab | Hardware-trojanere (sjeldne, men dokumenterte) |
| 1 | Bootloader | U-Boot 2024.07, Barebox 2023.09 | Åpen kildekode | Pinned commit, signatur verifisert |
| 2 | Linux-kjerne | 6.1 LTS, 6.6 LTS | Åpen kildekode | CVE-eksponeringsvindu |
| 3 | Systembiblioteker | glibc 2.37, musl 1.2.4 | Åpen kildekode | glibc CVE-er (f.eks. CVE-2023-4911) |
| 4 | Mellomvare | BlueZ 5.66, wpa_supplicant 2.10 | Åpen kildekode | Bluetooth KNOB, Krack-varianter |
| 5 | Applikasjon | Qt 5.15, vår ASR-motor | Blandet | Proprietære og åpne lag |
| 6 | Lukkede blobs | Wi-Fi-firmware, stemmemodell | Leverandør-NDA | Kan ikke revidere kildekode |
En kjøper har rett til å spørre: hvilke av disse 14 000 til 21 000 komponentene kan OEM-en faktisk gå god for? Vårt svar er ærlig – hvert nivå har en annen bevisklasse.
De 5 bevisklassene som brukes i vår SBOM
Vi merker hver SBOM-post med en bevisklasse slik at kjøperen vet nøyaktig hvilket revisjonsnivå som gjelder:
- E1 – Kildegodkjent: Vi har lest kildekodelinjen, bygget fra en pinnet commit-hash og verifisert utviklerens GPG-signatur. Dekker omtrent 62 % av komponentene i et typisk 18 MB Linux-image (bootloader, kjerne, kjernebiblioteker, vår egen kode).
- E2 – Distro-godkjent: Vi stoler på at oppstrømsdistribusjonen (Debian, Buildroot LTS) har utført godkjenningen. Dekker ~28 % (Qt, ALSA, OpenSSL 3.0.x).
- E3 — Leverandørgodkjent: Vi stoler på silisiumleverandørens binære blob og gjennomgår kun API-overflaten (Wi-Fi-firmware, Bluetooth HCI-firmware). Dekker ~7 %.
- E4 — NDA-godkjent: Lukket tredjeparts-SDK, kildekode i depot hos produsent i Shenzhen og gjennomgås årlig av et uavhengig laboratorium. Dekker ~3 %.
- E5 — Arvet risiko: Komponenter vi ikke kan inspisere direkte (kalibreringsblobs, akustiske modellvekter for tale-TTS kryptert under leverandørens HSM). Kjøperen informeres kun ved navn.
Total E1+E2-dekning på en K7-firmware er 90 % av komponentene og 96 % av angrepsflaten (kodelinjer). De resterende 10 % er dokumentert i et "restrisiko"-vedlegg som følger hver SBOM.
CycloneDX 1.5 SBOM-struktur for en lesepenn
Nedenfor er et representativt SBOM-utdrag for en K7 (den mest utplasserte kinesiske ODM-lese pennen i vår katalog). Det viser strukturen en skolekrets CISO eller GSA-evaluator vil analysere.
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"serialNumber": "urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8",
"version": 7,
"metadata"': {
"timestamp": "2026-08-15T10:30:00Z",
"tools": [{"vendor": "OWASP", "name": "CycloneDX-Maven-Plugin", "version": "2.7.10"}],
"component": {
"type": "firmware",
"bom-ref": "pkg:smartreadingpen/[email protected]",
"name": "k7-firmware",
"version": "3.4.1",
"hashes": [{"alg": "SHA-256", "content": "a4f5c8e92b3d..."}]
}
},
"components": [
{
"bom-ref": "pkg:sw/[email protected]",
"type": "library",
"name": "u-boot",
"version": "2024.07",
"purl": "pkg:sw/[email protected]",
"hashes": [{"alg": "SHA-1", "content": "9f3a..."}],
"licenses": [{"license": {"name": "GPL-2.0+"}}],
"evidence": {"identity": [{"field": "purl", "confidence": 100}]}
}
]
}
Hver avhengighet i K7-firmware er registrert med en Package URL (purl), lisens-SPIDX-identifikator, kryptografisk hash og opphavsfelt. En kjøper kan kjøre cyclonedx-cli diff mellom to SBOM-er for å se nøyaktig hva som er endret mellom firmware 3.4.0 og 3.4.1 — typisk 4 til 9 modifiserte komponenter i en rutinemessig sikkerhetspatch-utgivelse.
Leverandørkjede-angrepsvektorer spesifikke for lesepenner
En barnelsepenn har mindre angrepsflate enn en generell nettbrett, men flere vektorer som kjøpere undervurderer:
- OCR-motor bakdør — En kompromittert Tesseract-fork kan lekke skannede sidebilder til et endepunkt kontrollert av en angriper. Vi pinner Tesseract til en bestemt commit og bygger på nytt med reproduserbare byggeflagg.
- TTS-stemmemodellbytte — Stemmemodeller er store binærfiler (40 til 200 MB). Et bytte kan injisere banneord eller politisk innhold i lesematerialet. Vi signerer stemmemodeller med samme ECDSA-nøkkel som firmwaren og avviser feilaktige signaturer under kjøring.
- Modifisering av Wi-Fi-firmware-blob — Leverandørutstedte blobs fra Wi-Fi-brikkesettprodusenten (Realtek, Broadcom) kan ikke gjenoppbygges fra kilde. Vi utfører binærdiffering mot leverandørens referanseutgivelse og avviser ethvert avvik utover dokumenterte errata.
- Forgiftning av oversettelsesordbok — OEM-kunder (forlag, utdanningsdepartementer) leverer tilpassede ordbøker. Vi hash-verifiserer hver ordbok mot forlagets signerte manifest ved innlasting av innhold.
- Kompromittering av OTA-oppdateringsserver — Den vanligste leverandørkjede-vektoren i hele IoT-bransjen. Vi pinner OTA-serverens sertifikat i en skriv-en-gang-sikring ved første oppstart og nekter å akseptere noen annen CA, selv om en bedrift-CA-rotasjon går galt.
- Forfalsket silisium — Lese penn-SoC-er skaffet gjennom uautoriserte meglere kan være merket med lavere spesifikasjonsdier. Vår innkommende QC utfører røntgen-die-inspeksjon på en 2 % AQL-prøve av hvert forsendelsesparti.
Den reproduserbare byggepipelinen
En reproduserbar bygg lar en tredjepart regenerere firmwaren vår byte-for-byte fra den SBOM-oppførte kilden. Vi har investert i reproduserbarhet for de 90 % av firmwaren vår som er åpen kildekode. De resterende 10 % — lukkede blobs — er dokumentert i SBOM som E5.
Vår CI-pipeline kjører make SOURCE_DATE_EPOCH=fixed deterministic-build=yes og sammenligner den resulterende SHA-256 mot en publisert referanse. Per 3. kvartal 2026 er K7-firmwarebildet bit-eksakt reproduserbart på Debian Bookworm- og Ubuntu 22.04 LTS-verter. Plattformene F8, B2, Q8, Y6 er 92 % til 98 % reproduserbare avhengig av hvilket Wi-Fi/BT-brikkesett som er montert.
Kjøpere kan uavhengig verifisere reproduserbarhet med vårt offentlige skript:
git clone https://internal.smartreadingpen.example/k7-firmware.git
cd k7-firmware && git checkout v3.4.1
./build.sh --deterministic --output k7-firmware-3.4.1.bin
sha256sum k7-firmware-3.4.1.bin
# Skal matche: a4f5c8e92b3d...
Leverandør- og avhengighetspinne-disippin
Hver åpen kildekode-komponent er pinnet til en bestemt commit-hash, ikke et flytende tag. En 2-ukers SLA styrer oppgraderinger til en ny commit. I løpet av det vinduet kjører vi:
- Statisk analyse med Coverity Scan og CodeQL
- Fuzzing med AFL++ i minst 100 CPU-timer på parsere
- Lisenskompatibilitetsgjennomgang mot vår tillatelsesliste (MIT, BSD-2, BSD-3, Apache-2.0, LGPL-2.1 med dynamisk lenking-unntak, GPL-2.0+ kun for oppstart/kjerne)
- CVE-databasekryssjekk (NVD, GHSA, OSV) mot den nye versjonen
Komponenter som ikke består noen gate, holdes på forrige versjon. SBOM registrerer den holdte versjonen og oppstrøms nåværende versjon, slik at en kjøper kan se nøyaktig hva vi vet om.
Firmware-opphav og signeringskjede
Hver K7-produksjonsfirmware bærer tre signaturlag:
- Utviklersignatur — ingeniøren som bygde firmwaren signerer med sin personlige GPG-nøkkel. Loggført i byggesystemet.
- OEM-selskapssignatur — en maskinvaresikkerhetsmodul (YubiHSM 2) oppbevart i vårt safe i Shenzhen signerer med selskapets sub-CA.
- Uavhengig vitnesignatur — en ekstern revisor (Bureau Veritas eller TÜV) gir en motsignatur for SKU-er beregnet for amerikanske, EU eller australske K12-markeder.
Enhetens bootloader verifiserer kjeden i omvendt rekkefølge. Et flash-bilde som mangler en hvilken som helst signatur, avvises ved oppstart. Kundens regulatoriske team kan be om en kopi av enhver signeringskjede ved å sende e-post til [email protected] med SKU og serieområde.
Sårbarhetsavsløring og SBOM-CVE-livssyklusen
SBOM er kun så verdifull som prosessen som holder den oppdatert. Vår livssyklus for sårbarhetshåndtering er dokumentert separat i TC-149 (CVE-patchlivssyklus). Kort sagt:
- Daglig inntak — NVD-, GHSA-, OSV-Scanner-feeder hentes inn i vår tracker.
- Komponentmatch — hver CVE matches mot SBOM-komponentlisten etter CPE eller purl.
- Triage-SLA — kritiske CVE-er får et patch-mål på 72 timer; høy 14 dager; middels 45 dager; lav neste kvartalsutgivelse.
- Kundevarsling — enhver CVE med score ≥7,0 og eksploatert i naturen utløser e-post til registrerte kjøpere innen 24 timer.
- OTA-utrulling — en fiksutgivelse legges i OTA-stagingkanalen i 7 dager, deretter 25 %, og så 100 % over 21 dager.
SBOM-versjonen økes ved hver utgivelse. En kjøper som bruker dependency-track eller GUAC kan innta vår SBOM-feed på /sbom/feed.json og få varsler ved nye CVE-er som berører deres utrullede enhetspark.
Revisjon, attestasjon og kjøper-verifiserbar dokumentasjon
Kjøpere under føderale innkjøpsregler krever ofte tredjepartsattestasjon. Vår standard SBOM-pakke inkluderer:
- SOC 2 Type II-rapport som dekker firmware-byggemiljøet (årlig, av Schellman & Co.)
- ISO/IEC 27001:2022-sertifisering for SBOM-publiserings- og signeringspipen (Bureau Veritas, sertifikat #CN-2024-IS-0091)
- TÜV NORD EN 303 645-attestasjon for grunnlinjen for forbruker-IoT-sikkerhet
- NIST SP 800-218 SSDF v1.1-selvevaluering (Secure Software Development Framework) — full PDF tilgjengelig under NDA
- SBOM-minimumsfelt i henhold til NTIA 2024-konformitet (alle 7 datafelt utfylt)
- VEX-feed på
/vex/feed.jsonfor enhver CVE merket "not_affected" med dokumentert begrunnelse
En kjøper kan også sende en revisor til vår Shenzhen-fasilitet for en 1-dags gjennomgang av leverandørkjeden. Revisjonen dekker BOM-stagingområdet, firmware-byggesystemet, signerings-HSM-forvaringen og OTA-backend-infrastrukturen.
Reelle produksjonstall — K7- og Y6-eksempel
For en nylig produksjonsserie på 50 000 enheter av K7 til en amerikansk skoledistrikt:
| Metrikk | Verdi |
|---|---|
| Komponenter i levert SBOM | 18 432 |
| CycloneDX-filstørrelse | 4,7 MB komprimert |
| SPDX-filstørrelse | 6,1 MB komprimert |
| E1 (kilde-godkjent) dekning | 62,4 % |
| E2 (distro-godkjent) dekning | 28,1 % |
| E3 (leverandør-godkjent) dekning | 6,7 % |
| E4 (NDA-godkjent) dekning | 2,4 % |
| E5 (arvet risiko) dekning | 0,4 % |
| Kritiske CVE-er i sendt image | 0 |
| Høye CVE-er i sendt image | 2 (begge i leverandørens Bluetooth-blob, redusert ved konfigurasjon) |
| Verifisering av reproduserbart bygg | 100 % treff på 3 referanseverter |
| Tid fra kilde-commit til signert artefakt | 38 minutter (median) |
| OTA-iscenesettelse → 100 % utrulling | 21 dager |
For den mer avanserte Y6 (4G mobil lesepenn med AI-veileder) er SBOM-en større (21 000+ komponenter) og inkluderer mobilmodem-fastvare som en egen E5-oppføring.
Intern lenkestruktur for SBOM-innhold
En innkjøper av lesepenn-sikkerhet vil ønske å lese på tvers av katalogen vår:
- TC-149 — CVE-patchlivssyklus og sårbarhetsavsløring (forbrukeren av SBOM-strømmen)
- TC-145 — Sidekanal-angrep og konstanttidskryptografi (algoritmenivå-truslene SBOM ikke fanger)
- TC-147 — JTAG-deaktivering og låsing av debug-grensesnitt (enhetsnivåets følge til SBOM-åpenhet)
- K7 produktside — modellspesifikke tilpasningsalternativer for SBOM-inkluderte bygg
- Innkjøpsguide: sertifiseringsplan — hvordan SBOM knyttes til CE-, FCC- og EN71-revisjoner
- Bransje: K12-personvern — FERPA, COPPA, GDPR-K-tilpasning til SBOM-praksis
Sammen utgjør de en lukket-sløyfe-historie: en kjøper kan verifisere hvilken kode som finnes i enheten (SBOM), hvordan den kom dit (reproduserbart bygg + signaturkjede), hvilke trusler den bærer (CVE-feed), og hvilke forsvar som er innebygd (JTAG-låsing, konstanttidskryptografi, signert fastvare).
Reading Pen SBOM FAQ
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Hvilke SBOM-formater leveres SmartReadingPen med hver enhet?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Vi leverer både CycloneDX 1.5- og SPDX 2.3-SBOM-er innebygd i den sikre oppdateringspakken sammen med fastvarebildet. Hver SKU har en versjonert SBOM-feed på /sbom/{sku}/feed.json pluss et engangssnapshot i fabrikkens pakningsmanifest."
}
},
{
"@type": "Question",
"name": "Hvor mange komponenter inneholder en typisk K7-lesepenn-fastvare?",
"acceptedAnswer": {
"@type": "Answer",
"text": "K7-produksjonsfastvare (v3.4.x) har 18 400 til 18 500 komponenter, hvorav 90,5 % er kilde-godkjent eller distro-godkjent (E1+E2-bevisklasser), 6,7 % er leverandør-godkjent (Wi-Fi/BT-blob-er), og resten er under NDA eller medfødt risiko."
}
},
{
"@type": "Question",
"name": "Kan en kjøper verifisere SBOM-en uavhengig?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja. Vi publiserer de nøyaktige kilde-commit-hashene, det reproduserbare byggeskriptet og referanse-SHA-256-hashene. En kjøper kan gjenoppbygge fastvaren på sin egen Debian Bookworm- eller Ubuntu 22.04-vert og sammenligne hashene; de skal matche bit-for-bit for den åpne kildekode-andelen på 90 % av bildet."
}
},
{
"@type": "Question",
"name": "Hva skjer når en kritisk CVE oppdages i levert lesepenn-fastvare?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Innen 24 timer etter bekreftelse sender vi e-post til alle registrerte kjøpere med CVE-ID, berørte SKU-er, mitigasjonsstatus og forventet patchdato. Kritiske CVE-er sikter mot en patch-utgivelse innen 72 timer; høy alvorlighetsgrad sikter mot 14 dager. Fiksen legges inn i vår OTA-stagingkanal og rulles ut over 21 dager."
}
},
{
"@type": "Question",
"name": "Er SmartReadingPen i samsvar med den amerikanske Executive Order 14028 SBOM-kravet?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja. Vår SBOM oppfyller alle 7 NTIA-minimumsfelt (leverandørnavn, komponentnavn, versjon, avhengighetsrelasjon, forfatter av SBOM-data, tidsstempel, hash) og publiseres i både SPDX og CycloneDX. Vi publiserer også en VEX-feed som dokumenterer «not_affected»-avgjørelser med begrunnelse."
}
},
{
"@type": "Question",
"name": "Hvordan samspiller SBOM med EUs Cyber Resilience Act (CRA)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "CRA blir håndhevbar i 2027. Vår SBOM, sårbarhetshåndteringspolicy og 5-årige støtteforpliktelse oppfyller allerede CRA-kravene i vedlegg I §2. Vi har forhåndspublisert CRA-tilpassede SBOM-er for alle EU-rettede SKU-er siden 2025."
}
}
]
}
Relatert lesing
- TC-149: Lesepenn – CVE-patch-livssyklus og sårbarhetshåndtering
- TC-145: Lesepenn – sidekanal-angrep og konstanttidskryptografi
- TC-147: Lesepenn – JTAG-deaktivering og låsing av debug-grensesnitt
- K7 lesepenn OEM/ODM-tilpasning
- Lesepenn OEM-sertifiseringsplan: CE, FCC, EN71
- Lesepenn personvern for K12: FERPA, COPPA, GDPR-K
Innkjøpsoppfordring
Hvis du vurderer OEM-lesepenn-partnere for en føderal, statlig eller EU-K12-utrulling, kan vi sende en prøve-K7-SBOM-pakke innen 48 timer etter en signert MNDA. Pakken inneholder både CycloneDX- og SPDX-artefakter, det reproduserbare byggeskriptet, SOC 2 Type II-rapportutdraget som dekker fastvare-pipelinen vår, og NIST SSDF-selv-vurderingen. Send e-post til [email protected] eller besøk vår kontaktside for å be om pakken.
Vil du se byggegården personlig? Vi arrangerer månedlige gjennomganger av forsyningskjeden ved vår fabrikk i Shenzhen. Det 1-dagers besøket dekker BOM-mottaksområdet, HSM-forvarlighetskjeden, signeringsrommet og en live demonstrasjon av reproduserbart bygg. Bestill en fabrikkomvisning og vår sikkerhetssjef vil personlig guide deg gjennom hvert ledd i kjeden.