61. Základy DevSecOps a "shift-left" bezpečnost

Úvod a kontext

V tradičním modelu byla bezpečnost samostatný tým, který aplikaci
prověřil až těsně před nasazením do produkce — často formou ručního
penetračního testu trvajícího týdny. Problém: chyba nalezená týden
před release je mnohem dražší a stresovanější opravit než chyba
nalezená při psaní kódu. DevSecOps je odpověď na tento problém —
integrace bezpečnostních praktik do celého životního cyklu vývoje
a provozu, ne jako oddělená brána na konci.

Teorie

Co znamená "shift-left"

Pokud si představíte životní cyklus softwaru jako časovou osu zleva
doprava (návrh → vývoj → build → test → nasazení → provoz),
"shift-left" znamená posouvat bezpečnostní kontroly co nejvíce
doleva — co nejblíž k okamžiku, kdy vývojář píše kód, místo aby
byly nalepené jako poslední krok před produkcí. Čím dřív se chyba
najde, tím levněji a rychleji se opraví: chyba odhalená lintrem
v editoru vývojáře stojí sekundy, stejná chyba odhalená až
v produkci může stát hodiny incidentu a reputaci firmy.

DevSecOps není jen nástroj, je to praxe

DevSecOps se často mylně redukuje na "přidejte security scanner do
pipeline". Nástroje jsou nutná, ale ne dostačující podmínka. Skutečná
DevSecOps kultura znamená:

• Sdílená odpovědnost — bezpečnost není jen práce
  "bezpečnostního týmu", je součástí práce každého vývojáře a
  DevOps inženýra, podobně jako testování už dávno není jen práce
  QA týmu.
• Automatizace namísto ručních bran — automatizované kontroly
  v pipeline (viz další lekce) nahrazují pomalé ruční review, které
  se stejně často provádí povrchně kvůli časovému tlaku.
• Rychlá zpětná vazba — vývojář se o problému dozví během minut
  (při buildu), ne za týdny (při ročním auditu).
• Bezpečnost jako výchozí nastavení (secure by default) —
  šablony projektů, základní Docker image a Terraform moduly by měly
  být bezpečně nakonfigurované už od začátku, ne až po dodatečném
  zásahu.

Vrstvy bezpečnostních kontrol v pipeline

Typický DevSecOps pipeline přidává kontroly na několika úrovních,
každá chytá jiný druh problému:

1. Statická analýza kódu (SAST) — hledá zranitelné vzory přímo
   ve zdrojovém kódu (SQL injection, hardcoded hesla) bez spuštění
   aplikace.
2. Kontrola závislostí (SCA — Software Composition Analysis) —
   kontroluje, zda použité knihovny/balíčky neobsahují známé
   zranitelnosti (CVE).
3. Skenování kontejnerových image — kontroluje, zda base image
   a nainstalované balíčky v Docker image neobsahují zranitelnosti
   (podrobně příští lekce).
4. Dynamická analýza (DAST) — testuje běžící aplikaci zvenčí,
   simuluje útoky jako skutečný útočník.
5. Kontrola infrastruktury jako kódu — skenuje Terraform/Ansible
   definice na nebezpečné nastavení (např. otevřený port 22 pro
   celý internet) ještě před terraform apply.

Princip nejmenších oprávnění

Napříč celým DevSecOps je klíčový princip least privilege
(nejmenší nutná oprávnění): každý proces, kontejner, uživatel nebo
CI job by měl mít jen ta oprávnění, která nutně potřebuje pro svou
konkrétní práci, ne víc. CI pipeline, která nasazuje jen do jednoho
Kubernetes namespace, by neměla mít credentials s právy admina
celého clusteru — pokud unikne token, škoda je omezená jen na to,
k čemu měl přístup.

Praktický příklad

Ukázka, jak "shift-left" vypadá konkrétně v GitHub Actions pipeline —
bezpečnostní kontroly proběhnou hned při každém pull requestu, dřív
než kód vůbec dorazí k mergi, natož do produkce:

name: security-checks
on: pull_request

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Statická analýza (Bandit pro Python)
        run: |
          pip install bandit
          bandit -r ./app -ll   # -ll = hlásit jen střední a vysokou závažnost

  zavislosti:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Kontrola zranitelných závislostí
        run: |
          pip install pip-audit
          pip-audit -r requirements.txt

  iac-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Skenování Terraform konfigurace (tfsec)
        uses: aquasecurity/tfsec-action@v1.0.3
        with:
          working_directory: ./terraform

Pokud kterýkoliv z těchto jobů selže (najde zranitelnost vysoké
závažnosti), pull request nelze mergnout — bezpečnostní kontrola se
tak stává stejně samozřejmou branou jako testy, ne volitelným krokem
navíc na konci.

Shrnutí

DevSecOps posouvá bezpečnostní kontroly co nejblíž k okamžiku psaní
kódu ("shift-left"), protože chyba nalezená brzy je řádově levnější
opravit než chyba nalezená v produkci. Klíčové je pochopit, že jde
především o kulturu sdílené odpovědnosti a automatizaci, ne jen
o přidání jednoho nástroje. Pipeline typicky kombinuje statickou
analýzu kódu, kontrolu závislostí, skenování kontejnerů, dynamické
testování a kontrolu infrastruktury jako kódu, vždy s ohledem na
princip nejmenších oprávnění.

Kontrolní otázky

1. Co konkrétně znamená pojem "shift-left" v kontextu bezpečnosti a
   proč to snižuje náklady na opravu chyb?
2. Jaký je rozdíl mezi SAST a SCA kontrolou — jaký druh problému
   odhalí každá z nich?
3. Proč princip "least privilege" platí i pro CI/CD pipeline, ne jen
   pro lidské uživatele?
4. Mini cvičení: navrhněte, do kterého kroku vašeho vývojového
   procesu (commit, pull request, build, nasazení) byste zařadili
   SAST, SCA a skenování infrastruktury jako kódu, a zdůvodněte proč
   právě tam.