Kaj lahko dejansko dokažete o zadnji izdaji svojega izdelka. Četrti del serije »Ko dobra koda ni več dovolj«.

Ko se pogovor obrne k varnosti, ima marsikatera razvojna ekipa pripravljena dva pomirjujoča odgovora: »pišemo čisto kodo« in »imamo ISO 27001«. Oba sta vredna. Nobeden ne odgovori na vprašanje, ki ga bo zastavil nemški naročnik: kaj natanko je v izdaji, ki ste nam jo dostavili v torek?

Serija »Ko dobra koda ni več dovolj«

01 Nemški naročnik ne kupuje več vaše kode. Kupuje odsotnost vašega tveganja. (4. 8. 2026)
02 O uredbi smo pisali. Smo komu povedali, kaj naj naredi v ponedeljek zjutraj? (11. 8. 2026)
03 Niste zavezanec po NIS2? Vaš naročnik ima morda drugačne načrte. (18. 8. 2026)
04 Clean code vas ne bo rešil. Tudi certifikat ne. (25. 8. 2026)
05 Nemški varnostni vprašalnik: trenutek, ko marketing sreča realnost (1. 9. 2026)
06 Slovenski IT ne potrebuje še enega seminarja o NIS2 (8. 9. 2026)

V tem članku: Dva pomirjujoča odgovora · Veriga od vrstice kode do dostave · Osem mest, kjer se dokaz izgubi · Starejši sistemi · Kaj bi vprašal nemški naročnik? · Pripomoček: minimalen postopek in SBOM

Dva pomirjujoča odgovora

Čista koda je dobra naložba. Berljivo, preizkušeno in modularno kodo je lažje pregledati, ranljivost v njej hitreje najdete in popravek hitreje izdate. Kdor vzdržuje dobro kodo, ima pri varnosti prednost.

Certifikat ISO 27001 pove, da ima podjetje sistem upravljanja informacijske varnosti: politike, odgovornosti, oceno tveganj, notranje presoje. Nemški naročniki ga cenijo in pri marsikaterem odpre vrata.

Ampak oba odgovora govorita o podjetju na splošno. Čista koda ne pove, katera različica knjižnice za razčlenjevanje XML je v izdaji 4.2. Certifikat ne pove, ali je bila izdaja 4.2 zgrajena iz preverjene izvorne kode. Naročnik pa ne kupuje podjetja na splošno. Kupuje izdajo 4.2.

Veriga od vrstice kode do dostave

Kar morate o izdaji dokazati, je veriga štirih členov:

Izvor: katera izvorna koda, kdo jo je spremenil, kdo je spremembo odobril.
Gradnja: iz katere izvorne kode, s katerimi odvisnostmi in na katerem sistemu je izdaja nastala.
Izdelek: kaj je v izdaji (seznam komponent), katere znane ranljivosti ima in kdo je odločil, da so sprejemljive.
Dostava: da je naročnik dobil točno to, kar je nastalo, in ne kaj drugega.

Vsak člen zahteva zapis, ki nastane sam, med delom. Zapis, ki ga sestavite naknadno, ko pride vprašalnik, ni dokaz. Je rekonstrukcija.

Osem mest, kjer se dokaz izgubi

Varnostna arhitektura. Kje se konča zaupanje? Diagram, ki pokaže meje zaupanja, tokove podatkov in mesta preverjanja identitete, je dokument, po katerem naročnik vpraša zgodaj. Nastane pa šele, ko ga kdo nariše.
Razvojni postopek. Pregled kode, ki ga zahteva orodje (ne dobra volja), in testi, katerih rezultati so shranjeni ob izdaji.
Seznam komponent (SBOM). Strojno berljiv seznam vseh komponent z različicami. Nemški BSI v tehnični smernici TR-03183-2 (različica 2.1.0) zahteva zapis CycloneDX 1.6 ali SPDX 3.0.1 ali novejši; CRA v Prilogi I zahteva, da proizvajalec komponente prepozna in dokumentira, med drugim s seznamom komponent.
Odvisnosti. Pravilo, katere vire paketov uporabljate, kdo odobri novo odvisnost in kako hitro posodobite ranljivo.
Identiteta. Osebni računi z večstopenjsko prijavo za ljudi, ločene identitete za storitve, brez skupnih gesel v skriptah.
Dobavna veriga kode. Podpisane izdaje in zapis, iz katerega stanja repozitorija je izdaja nastala.
Cevovod gradnje (CI/CD). Mesto, kjer vse zgornje nastane samodejno. Gradnja na razvijalčevem prenosniku ne pušča dokazov.
Upravljanje ranljivosti. Postopek: zaznava, ocena, popravek, preverjanje, obveščanje. Z roki glede na resnost in zapisom vsakega primera.

Najtežje je pri starejših sistemih

Pri programski opremi, ki teče petnajst let, je vprašanje »katere komponente so v izdaji« pogosto najtežje. Del odvisnosti nima več podpore, del je bil prenesen ročno, gradnja pa poteka po postopku, ki ga pozna en sam sodelavec.

To ni razlog za zamenjavo sistema. Je razlog, da se gradnja najprej prenese v cevovod in da seznam komponent nastane vsaj za tisto, kar se ob gradnji dejansko uporabi. Ko je seznam na mizi, postane vidno, katere komponente je treba posodobiti in katere zamenjati. Takšno postopno posodabljanje je bolj obvladljivo kot velika prenova; več o tem, kako posodabljamo podedovane sisteme.

Kaj bi vprašal nemški naročnik?

„Können Sie uns zu jeder ausgelieferten Version eine Software-Stückliste (SBOM) im Format CycloneDX oder SPDX gemäß BSI TR-03183-2 bereitstellen?“

Prevod: Ali nam lahko za vsako dostavljeno različico zagotovite seznam komponent programske opreme (SBOM) v zapisu CycloneDX ali SPDX skladno z BSI TR-03183-2?

Kaj v resnici želi vedeti? Besedi zu jeder ausgelieferten Version sta pomembnejši od imena zapisa. Naročnik ne želi enkratnega seznama za pogodbo, ampak seznam, ki se ujema z vsako izdajo, ki jo dobi. To je mogoče samo, če seznam nastane samodejno ob gradnji. Sklic na TR-03183-2 pomeni, da bo preveril tudi vsebino: različice, licence, kontrolne vsote in odvisnosti, ne le obstoj datoteke.

Pripomoček Minimalen varnostni postopek v cevovodu gradnje

Najmanjši postopek, s katerim vsaka izdaja pusti dokaze. Ni popoln, je pa začetek, ki ga je mogoče uvesti v enem tednu.

#	Korak	Kaj nastane	Kaj dokazuje
1	Gradnja samo v cevovodu, iz označenega stanja repozitorija	zapis gradnje z oznako izvorne kode	izdaja izvira iz preverjene kode
2	Testi ob vsaki gradnji	shranjeni rezultati testov	izdaja je bila preizkušena
3	Izdelava SBOM	`sbom.cdx.json` ob izdaji	kaj je v izdaji
4	Pregled ranljivosti v SBOM	poročilo; gradnja se ustavi pri visoki resnosti	znane ranljivosti so bile preverjene
5	Podpis izdaje	podpisane datoteke	dostavljeno je enako zgrajenemu
6	Shranjevanje izdaje z vsemi dokazili	en paket na izdajo	vse zgornje je mogoče predložiti

Primer za Azure Pipelines (za GitHub Actions in GitLab CI so koraki enaki). Uporablja odprtokodni orodji syft za SBOM in grype za pregled ranljivosti; obe morata biti nameščeni na agentu za gradnjo.

# azure-pipelines.yml - minimalen varnostni postopek ob vsaki izdaji
trigger:
  tags:
    include: ['v*']

pool:
  vmImage: windows-latest

steps:
- checkout: self

- script: dotnet build MojaResitev.sln -c Release
  displayName: Gradnja

- script: dotnet test MojaResitev.sln -c Release --no-build --logger trx
  displayName: Testi

- script: syft dir:. -o cyclonedx-json=$(Build.ArtifactStagingDirectory)/sbom.cdx.json
  displayName: Seznam komponent (CycloneDX)

- script: grype sbom:$(Build.ArtifactStagingDirectory)/sbom.cdx.json --fail-on high
  displayName: Pregled ranljivosti

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: $(Build.ArtifactStagingDirectory)
    artifact: izdaja-$(Build.SourceBranchName)
  displayName: Shranjevanje izdaje z dokazili

Na kaj paziti:

Preverite, da orodje izdela CycloneDX 1.6 ali novejši, kot zahteva TR-03183-2 v2.1.0.
–fail-on high ustavi gradnjo pri visoki ali kritični resnosti. Izjemo lahko odobri le odgovorna oseba, odobritev pa se zapiše.
Privzeta hramba artefaktov v cevovodih je kratka. Proizvajalec mora po CRA tehnično dokumentacijo hraniti deset let ali ves čas podpore, če je ta daljša. Za izdaje, dostavljene naročniku, nastavite ustrezno hrambo ali paket prenesite v arhiv.
Podpis izdaje (korak 5) je odvisen od vrste izdelka: Authenticode za programe Windows, cosign za vsebnike. V primeru ni prikazan, ker potrebuje vaš ključ.

Naslednji del (1. 9. 2026): Nemški varnostni vprašalnik: trenutek, ko marketing sreča realnost

Če želite postopek uvesti v obstoječ ali starejši sistem gradnje, nam pišite.

Clean code vas ne bo rešil. Tudi certifikat ne.