🟡 Intermediate

Supply Chain Security — Bezpečnosť softvérového dodávateľského reťazca

Moderný softvér sa neskladá len z kódu, ktorý napíšete. Typická aplikácia obsahuje stovky open-source závislostí, build nástroje tretích strán, CI/CD pipeline a container base images. Každý z týchto komponentov je potenciálny vektor útoku. Supply chain security sa zaoberá ochranou celého reťazca — od zdrojového kódu cez build proces až po produkčné nasadenie.

Prečo je to dôležité?

Útočníci si uvedomili, že namiesto priameho útoku na dobre zabezpečenú aplikáciu je jednoduchšie kompromitovať niektorú z jej závislostí. Jeden infikovaný balíček v npm, PyPI alebo Maven Central môže zasiahnuť tisíce projektov súčasne.

Podľa Sonatype State of the Software Supply Chain reportu sa počet supply chain útokov medzi rokmi 2020 a 2025 zvýšil o viac než 700 %. Nejde o teoretické hrozby — ide o reálne incidenty s miliardovými škodami.

Najznámejšie supply chain útoky

SolarWinds (2020)

Útočníci (pravdepodobne štátom sponzorovaná skupina) kompromitovali build systém spoločnosti SolarWinds a vložili backdoor do aktualizácie produktu Orion. Infikovaná aktualizácia bola distribuovaná 18 000+ organizáciám vrátane amerických vládnych agentúr. Útok ostal neodhalený mesiace.

Poučenie: Aj digitálne podpísaný softvér môže byť kompromitovaný, ak je napadnutý samotný build proces.

Log4Shell / Log4j (2021)

Kritická zraniteľnosť (CVE-2021-44228) v knižnici Apache Log4j umožňovala vzdialené spustenie kódu. Log4j bol tak rozšírený, že zraniteľnosť zasiahla milióny aplikácií — od Minecraftu po enterprise systémy. Mnohé organizácie ani nevedeli, že Log4j používajú.

Poučenie: Bez SBOM (Software Bill of Materials) neviete, čo sa nachádza vo vašom softvéri.

xz-utils (2024)

Sofistikovaný útok, kde útočník strávil dva roky budovaním dôvery ako maintainer open-source projektu xz-utils. Následne vložil backdoor do kompresnej knižnice, ktorá sa používa v OpenSSH. Útok bol odhalený náhodou — vďaka vývojárovi, ktorý si všimol nezvyčajnú latenciu.

Poučenie: Sociálny inžiniering v open-source komunite je reálna hrozba. Dôvera sa nedá automatizovať.

SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts, vyslovované „salsa") je bezpečnostný framework od Google, ktorý definuje stupne zrelosti pre ochranu softvérového dodávateľského reťazca.

Úrovne SLSA

Úroveň Požiadavky
Build L0 Žiadne záruky
Build L1 Dokumentácia build procesu, generovanie provenance
Build L2 Hosted build platforma, podpísaná provenance
Build L3 Hardened build platforma, izolované buildy, non-falsifiable provenance

Kľúčové koncepty

  • Provenance — kryptograficky overiteľný záznam o tom, kto, kde a ako artefakt vznikol
  • Build platform — izolované a auditovateľné prostredie pre build (napr. GitHub Actions, Google Cloud Build)
  • Source integrity — overenie, že zdrojový kód nebol manipulovaný
# Príklad GitHub Actions workflow s SLSA provenance
jobs:
  build:
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/attest-build-provenance@v2
        with:
          subject-path: './dist/my-app'

Sigstore — Podpisovanie a overovanie artefaktov

Sigstore je open-source projekt, ktorý dramaticky zjednodušuje kryptografické podpisovanie softvérových artefaktov. Skladá sa z troch hlavných komponentov:

Cosign

Nástroj na podpisovanie a overovanie container images a iných OCI artefaktov.

# Podpísanie container image pomocou keyless signing
cosign sign ghcr.io/my-org/my-app:v1.2.3

# Overenie podpisu
cosign verify ghcr.io/my-org/my-app:v1.2.3 \
  --certificate-identity=ci@my-org.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Fulcio

Certificate Authority, ktorá vydáva krátkodobé certifikáty na základe OIDC identity (GitHub, Google, Microsoft). Eliminuje potrebu spravovania dlhodobých podpisových kľúčov.

Rekor

Transparentný, immutable log všetkých podpisových operácií. Funguje podobne ako Certificate Transparency logy pre TLS certifikáty — každý podpis je verejne zaznamenateľný a auditovateľný.

Prečo je to revolučné? Pred Sigstore bolo podpisovanie artefaktov zložité a vyžadovalo správu GPG/PGP kľúčov. Sigstore priniesol keyless signing — identita sa overí cez existujúceho OIDC providera a krátkodobý certifikát sa vytvorí automaticky.

SBOM — Software Bill of Materials

SBOM je kompletný zoznam všetkých komponentov vo vašom softvéri — závislosti, licencie, verzie. Je to „zoznam ingrediencií" pre softvér.

Štandardné formáty

  • SPDX (Linux Foundation) — ISO štandard
  • CycloneDX (OWASP) — zameraný na bezpečnosť

Generovanie SBOM

# Syft — generovanie SBOM z container image
syft ghcr.io/my-org/my-app:latest -o cyclonedx-json > sbom.json

# Trivy — skenovanie zraniteľností z SBOM
trivy sbom sbom.json

📌 Viac o legislatívnych požiadavkách na SBOM nájdete v článku SBOM a legislatíva.

Best Practices pre Supply Chain Security

1. Dependency Management

  • Lockfiles — vždy commitujte package-lock.json, poetry.lock, go.sum
  • Pinning — používajte presné verzie, nie rozsahy (1.2.3, nie ^1.2.0)
  • Automated scanning — Dependabot, Renovate, Snyk na automatické aktualizácie
  • Audit — pravidelne spúšťajte npm audit, pip-audit, govulncheck

2. Build Security

  • Reprodukovateľné buildy — rovnaký vstup musí produkovať identický výstup
  • Izolované build prostredie — buildy v ephemeral kontajneroch
  • SLSA provenance — generujte a overujte build provenance
  • Minimal base images — distroless, scratch, Alpine

3. Artifact Verification

  • Podpisovanie images pomocou Cosign/Sigstore
  • Admission controllers — Kyverno alebo OPA Gatekeeper na vynútenie podpísaných images v Kubernetes
  • Verified publishers — preferujte oficiálne a overené base images

4. Runtime Protection

  • Immutable infrastructure — kontajnery sú read-only
  • Network policies — segmentácia sieťovej komunikácie
  • Runtime monitoring — Falco, Tetragon na detekciu anomálií

5. Organizačné opatrenia

  • SBOM pre každý release — automaticky generovaný a archivovaný
  • Incident response plán — čo robiť pri kompromitovanej závislosti
  • Vendor assessment — hodnotenie bezpečnosti dodávateľov

Praktická implementácia v CI/CD

Kompletný supply chain security pipeline by mal obsahovať:

Source → Lint/SAST → Build (SLSA) → SBOM → Sign (Cosign) → Scan → Deploy (Verify)
  1. Source — overenie integrity kódu, podpísané commity
  2. Build — SLSA L2+ provenance, izolované prostredie
  3. SBOM — automatické generovanie pri každom builde
  4. Sign — podpísanie artefaktu pomocou Sigstore
  5. Scan — kontrola zraniteľností pred nasadením
  6. Deploy — admission controller overí podpis pred spustením

Záver

Supply chain security nie je luxus — je to nevyhnutnosť. Útoky ako SolarWinds a xz-utils ukázali, že aj tie najlepšie zabezpečené organizácie sú zraniteľné cez svoje závislosti. Frameworky ako SLSA a nástroje ako Sigstore dávajú DevOps tímom konkrétne prostriedky na ochranu. Začnite s generovaním SBOM a podpisovaním artefaktov — to sú najdôležitejšie prvé kroky.