Uporabniška orodja

Barvna shema: Svetla

Imate SBOM? Še vedno morda ne veste, katero kriptografijo uporabljate.

Izdaja 09 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za interne IT-oddelke in razvojne ekipe, ki programsko opremo razvijajo ali vzdržujejo za nemške naročnike.

Vaš cevovod gradnje ob vsaki izdaji izdela popis programskih komponent. Ponosni ste nanj, in upravičeno: nemški naročnik ga je pohvalil. Nato vpraša: »Kateri postopek za dogovor o ključu uporablja vaša aplikacija pri povezavi z nami?« Popis o tem ne pove ničesar.

O čem pišemo: kako v praksi ugotoviti, katere kriptografske knjižnice, nastavitve, potrdila, ključe in protokole vaša programska oprema dejansko uporablja, in zakaj popis komponent (SBOM) za to ne zadošča. Česa ne obravnavamo: izbire konkretnih orodij in zgradbe infrastrukture javnih ključev (izdaja 10).

V tem članku: Kaj SBOM pove in česa ne · Pet mest, kjer se kriptografija odloča · Kaj je CBOM · Kaj je vaše · Primer · Postopek v šestih korakih · Kako popis ohraniti živ · Pasti pri iskanju · Vprašanje za naročnika · Priloga: model CBOM

Kaj SBOM pove in česa ne

Popis programskih komponent (SBOM) našteje, iz česa je programska oprema sestavljena: knjižnice, različice, izvor, licence. Je osnovno orodje za obvladovanje ranljivosti. Z Aktom o kibernetski odpornosti (CRA) bo za proizvajalce izdelkov z digitalnimi elementi od decembra 2027 obvezen.

Ne pove pa, kaj knjižnice v vaši aplikaciji dejansko počnejo. Da je v aplikaciji knjižnica OpenSSL 3.5, ki od aprila 2025 podpira postkvantne postopke ML-KEM in ML-DSA, ne pomeni, da vaša aplikacija te postopke uporablja. Da teče na Javi, ki ima od različice 24 (marec 2025) vmesnike za ML-KEM in ML-DSA, ne pomeni, da jih koda kliče.

SBOM opisuje zmožnosti. Naročnika zanimajo dejstva.

Pet mest kjer se kriptografija odloča

Kriptografija v vaši programski opremi se ne odloči na enem mestu. Odloča se na petih, in vsako zahteva drugačno iskanje:

  1. V kodi. Katere funkcije knjižnic koda kliče: podpis z RSA, dogovor o ključu z ECDH, šifriranje z AES. Najdete jih s pregledom kode in z orodji za statično analizo.
  2. V nastavitvah. Katere skupine TLS so dovoljene, katere šifrirne zbirke, kateri postopki za SSH. Najdete jih v konfiguracijskih datotekah, nastavitvah ogrodja in okoljskih spremenljivkah.
  3. V platformi. Kaj izbere operacijski sistem, izvajalno okolje ali strežnik, kadar koda ne pove ničesar. Privzete vrednosti se spreminjajo z različicami.
  4. Na drugi strani. Kaj podpira strežnik ali odjemalec, s katerim se povezujete. Dogovori se samo tisto, kar podpirata oba.
  5. V ključih in potrdilih. S katerim postopkom so bila ustvarjena, kje so shranjena, kdaj potečejo.

SBOM pokrije prvo točko le napol: pove, katere knjižnice so prisotne, ne pa, katere funkcije se kličejo. Ostalih štirih ne pokrije.

Kaj je CBOM

Kriptografski popis (CBOM, Cryptography Bill of Materials) je razširitev SBOM s kriptografskimi sredstvi. Standard CycloneDX ga podpira od različice 1.6 (2024, standardiziran kot ECMA-424); različica 1.7 iz oktobra 2025 ga je razširila. Evropski načrt za prehod na postkvantno kriptografijo priporoča prav takšen standardiziran format.

CBOM pozna štiri vrste vpisov: algoritme (s funkcijo in parametri), potrdila (z izdajateljem, veljavnostjo, podpisnim postopkom), protokole (z različico in nastavljenimi postopki) in ključe (z vrsto, velikostjo, stanjem in mestom hrambe). Bistvene so povezave: katera komponenta izvaja kateri algoritem, kateri protokol uporablja katere postopke, katero potrdilo pripada kateri storitvi.

Prednost: CycloneDX v isti datoteki dovoli SBOM in CBOM. Če SBOM že gradite s CycloneDX, lahko kriptografske vpise dodajate postopoma.

Kaj je vaše in česa ne morete vedeti

Kot razvijalec ali vzdrževalec programske opreme za nemškega naročnika poznate kodo in, če jo upravljate, tudi nastavitve. Teh podatkov naročnik nima in jih ne more dobiti drugje kot pri vas. Zato je ta del popisa vaš, brez izgovora.

Česar ne morete vedeti: kaj je nastavljeno na naročnikovi strani povezave, kaj podpira njegov izenačevalnik obremenitve ali portal. To morate vprašati. Razmejitev je jasna: vi opišete svojo kodo in svoje nastavitve, naročnik svoje okolje. Popoln popis povezave nastane šele skupaj.

Če razvijate za naročnika, ki aplikacijo sam upravlja, velja enako: vi poveste, kaj koda kliče in kaj je mogoče nastaviti, on pove, kaj je nastavil.

Primer ekipa dveh aplikacij

Ekipa šestih razvijalcev v Ljubljani, recimo, vzdržuje dve aplikaciji za nemškega distributerja: spletni portal v Javi in storitev za izmenjavo dokumentov v .NET. Obe imata SBOM iz cevovoda gradnje. Ko naročnik vpraša po kriptografiji, ekipa en teden posveti popisu:

Kaj Po SBOM Dejansko (po pregledu)
Prijava v portal Java 21, knjižnica za JWT žetoni podpisani z RSA-2048; algoritem izbran v kodi, na treh mestih
TLS portala – (ni v SBOM) končan na naročnikovem izenačevalniku obremenitve; ekipa nanj nima vpliva
Izmenjava dokumentov .NET, knjižnica za PDF dokumenti podpisani s potrdilom naročnikove CA; ključ v datoteki na strežniku
Povezava na naročnikov SAP knjižnica HTTP-odjemalca TLS 1.2 z naročnikovim strežnikom; dogovorjena skupina klasična
Šifriranje prilog v bazi – AES-256, ključ zaščiten z RSA, shranjen v nastavitvah aplikacije

Ekipa ugotovi dve stvari. Prvič: algoritem za podpis žetonov je izbran neposredno v kodi, na treh mestih. Zamenjava bo zahtevala spremembo kode, ne nastavitve. Kdo ga je tja zapisal, ni bilo več mogoče ugotoviti; verjetno vsi po malem. Drugič: dve vrstici sploh nista njeni. TLS portala in povezavo na SAP določa naročnik. Odgovor naročniku tako vsebuje tri točke, ki jih ekipa uredi sama, in dve vprašanji zanj.

Postopek v šestih korakih

  1. Začnite pri povezavah z naročnikom. Tam je tveganje največje in tam vas bodo najprej vprašali.
  2. Preglejte kodo za klice kriptografskih funkcij. Orodja za statično analizo pomagajo; vsak zadetek preverite.
  3. Zberite nastavitve: konfiguracijske datoteke, nastavitve ogrodij, privzete vrednosti platforme.
  4. Izmerite, kaj se dogovori. Pri vsaki povezavi enkrat zapišite dejansko dogovorjene postopke.
  5. Popišite potrdila in ključe z mestom hrambe in rokom veljavnosti.
  6. Zapišite v CBOM ali vsaj v register iz izdaje 04, z virom vsakega podatka (koda, nastavitev, meritev).

Kako popis ohraniti živ

Popis, ki ga naredite enkrat za naročnikov vprašalnik, bo čez pol leta zastarel. Nova različica knjižnice, nova nastavitev strežnika, nova protistranka. Zato ga vključite v delo, ki ga že opravljate:

  • Ob gradnji. Cevovod, ki že izdela SBOM, lahko z orodjem za statično analizo doda kriptografske vpise iz kode. Novi klic RSA v kodi se tako pokaže v pregledu sprememb, ne šele ob vprašalniku.
  • Ob namestitvi. Skripta po namestitvi zapiše dejanske nastavitve TLS in potrdila na strežniku.
  • Ob spremembi povezave. Ko se poveže nova protistranka ali se spremeni naročnikov portal, enkrat izmerite, kaj se dogovori.
  • Letno. Pregled celotnega popisa z odgovorno osebo, ki odgovarja tudi naročniku.

Tako popis ne nastaja kot dodatno delo, ampak kot stranski proizvod razvoja. In ko naročnik vpraša, odgovor pripravite iz popisa v urah, ne v tednih.

Pasti pri iskanju

  • »Knjižnica podpira, torej uporabljamo.« Podpora ni uporaba. Preverite klic in nastavitev.
  • »Privzeto je varno.« Privzete vrednosti se z različicami spreminjajo. Zapišite, kaj velja v vaši različici.
  • »Kriptografija je samo v knjižnicah.« Lastne izvedbe, kopirani deli kode in skripte za gradnjo zlahka uidejo pregledu.
  • »Ključi niso del kode.« Res, a ključ v nastavitvah aplikacije je del vaše odgovornosti, ne naročnikove.

Vprašanje za nemškega naročnika

„Auf unserer Seite haben wir die kryptografischen Verfahren der Anwendung dokumentiert. Welche Verfahren sind auf Ihrem Lastverteiler und Ihren Gegenstellen eingestellt, und planen Sie dort Änderungen?“

Prevod: Na naši strani smo popisali kriptografske postopke aplikacije. Kateri postopki so nastavljeni na vašem izenačevalniku obremenitve in na vaših protistrankah ter ali tam načrtujete spremembe?

Zakaj tako? Ker ste svoj del opravili in ga lahko pokažete. Vprašanje obrne pogovor: ne zagovarjate se vi, ampak skupaj ugotavljata, kaj velja na obeh straneh.

Nemška izdaja te teme se obrača na revizijo in arhitekte pri naročnikih: „Eine Software-Stückliste ist noch kein Kryptoinventar“ (v nemščini). Prejšnja izdaja: PQC v pogodbi: ste prevzeli odgovornost, ki je ne morete izpolniti?

Priloga podatkovni model CBOM in primer

Poenostavljen podatkovni model po vzoru CycloneDX 1.6/1.7. Pokaže, katere podatke potrebuje kriptografski popis; natančna imena polj določa specifikacija. V nemški izdaji je vsebinsko enak.

Vrsta vpisa Obvezni podatki Koristno za načrtovanje PQC
Algoritem ime, funkcija (podpis, dogovor o ključu, šifriranje, zgoščevanje), nabor parametrov klasična raven varnosti, ocena odpornosti na kvantne napade, izvedba
Potrdilo imetnik, izdajatelj, veljavnost od/do, podpisni algoritem, ključ izdajateljski CA, uporaba (TLS, koda, dokument)
Protokol vrsta (TLS, IKEv2, SSH …), različica, nastavljeni postopki izmerjeni dogovor, protistranke
Ključni material vrsta (zasebni, javni, skrivni), algoritem, velikost, stanje mesto hrambe (HSM, datoteka), nastanek, potek, odgovorna oseba
Povezava komponenta izvaja algoritem; protokol uporablja postopek; storitev uporablja potrdilo odvisnost od tretjih (proizvajalec, naročnik)

Primer vpisa (poenostavljen, za ponazoritev):

{
  "type": "cryptographic-asset",
  "name": "Podpis prijavnih žetonov portala",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "signature",
      "parameterSetIdentifier": "2048"
    }
  },
  "properties": [
    { "name": "algoritem", "value": "RSA (PKCS#1 v1.5, SHA-256)" },
    { "name": "izbran.v", "value": "koda, 3 mesta" },
    { "name": "spremeni.lahko", "value": "razvojna ekipa (sprememba kode)" },
    { "name": "stanje", "value": "2026-02-20" }
  ]
}

Kako brati: polja pod properties so lastni dodatki za načrtovanje in odgovornost. CycloneDX takšne lastnosti dovoli; za izmenjavo z naročnikom se o imenih dogovorite vnaprej.


Vse objavljene izdaje serije: pregled »Postkvantna varnost v dobavni verigi«

Naslednja izdaja (6. 4. 2026): »Postkvantna PKI: zakaj zamenjava certifikata ne zadostuje«

Viri (stanje 2. 3. 2026): CycloneDX Specification 1.6 (ECMA-424, 1. izdaja junij 2024) in 1.7 (oktober 2025); OpenSSL 3.5 Release Notes (april 2025); JEP 496 in 497 (JDK 24, marec 2025); Uredba (EU) 2024/2847, Priloga I, del II.

Če imate SBOM in bi radi do CBOM brez velikega projekta, nam pišite.