Skenování závislostí

Úvod

Moderní software se skládá z mnoha komponent, z nichž každá má své vlastní závislosti. Není neobvyklé, že projekt má stovky závislostí. Bezpečnostní chyba ovlivňující jednu komponentu může ohrozit celý produkt. Pravidelné aktualizace závislostí zabraňují hromadění technického dluhu a zajišťují bezpečnost uživatelů a jejich dat.

Jak to funguje

Skenery závislostí využívají několik technik k výčtu všech komponent použitých v softwarovém projektu, jako je analýza souborů zámků (např. package-lock.json, poetry.lock, or Cargo.lock) nebo skenování souborového systému a hledání známých binárních souborů nebo git submodulů. Při výčtu softwarových komponent přítomných v kontejneru Docker se vypočítávají také balíčky nainstalované prostřednictvím správce balíčků distribuce.

Výsledný dokument popisující softwarové komponenty se nazývá Software Bill of Materials (SBOM). Existuje několik dobře známých formátů SBOM, jako jsou CycloneDX nebo SPDX, a několik nástrojů, které je generují, jako jsou syft nebo sbom-tool.

Existuje mnoho případů použití SBOM. SBOM lze například použít ke kontrole zastaralých komponent, u kterých chybí opravy zabezpečení. Grype lze použít k snadnému generování zprávy o zranitelnosti ze SBOM (více o tom píšeme v následujících částech).

Bezpečnost: Skenování závislostí v GitLabu

Závislosti by měly být pravidelně a často kontrolovány. Ruční kontrola není proveditelná ani praktická. Z tohoto důvodu se doporučuje zahrnout kontrolu závislostí do stávajících pracovních postupů CI/CD.

GitLab (platí pro Ultimate tier předplatné) má zabudovanou funkcionalitu Dependency Scanning. Pro její aktivaci je nutné přidat pár řádek do souboru .gitlab-ci.yml:

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

Úloha Dependency Scanning generuje SBOM s detekovanými závislostmi. Seznam závislostí se nachází na kartě Security projektu. Zobrazuje závislosti a jejich potenciální zranitelnosti. Přehled detekovaných zranitelností můžete vidět na kartě Vulnerability Report, kde můžete výsledky třídit. Výsledky můžete vidět na obrázcích níže.

Nálezy mají různou závažnost a proto je třeba zacházet s nimi metodicky. Doporučujeme upřednostnit nálezy na základě rizika, které představují pro aplikaci. Většinu zranitelností lze opravit aktualizací zranitelné komponenty na bezpečnou verzi. V některých případech není aktualizace možná a může být nutné zvolit jinou závislost nebo problém zmírnit jinými prostředky.

Funkce Dependency Scanning od GitLabu poskytuje jednoduchý způsob implementace skenování závislostí s příjemným uživatelským prostředím. Úzká integrace s bezpečnostními funkcemi GitLabu je bezkonkurenční. Více informací o funkcích Dependency Scanning od GitLabu najdete v oficiální dokumentaci, kde jsou uvedeny všechny možnosti konfigurace, návody a další užitečné tipy.

GitLab nabízí kromě skenování závislostí i další užitečné bezpečnostní funkce, jako je skenování omylem odeslaných tajných informací, skenování kontejnerů v registru nebo provádění statické analýzy zdrojového kódu za účelem odhalení potenciálních zranitelností. Mnohé z nich jsou stejně snadno konfigurovatelné jako skenování závislostí, proto vám vřele doporučujeme, abyste si je vyzkoušeli!

Aktualizace: Renovate

Jednou z funkcí, která v nástroji Dependency Scanning od GitLabu chybí, jsou oznámení o nových verzích. Koneckonců, je mnohem snazší opravit kritické chyby zabezpečení, pokud jsou verze závislostí aktuální a technický dluh je udržován v rozumných mezích. Renovate pomáhá vývojářům tím, že je informuje o nových verzích softwarových závislostí. Poskytuje také informace o zranitelných místech, proto je nejlepší jej používat společně s nástrojem Dependency Scanning od GitLabu.

Renovate není omezen na GitLab, protože podporuje 9 platforem a  sleduje závislosti ve více než 90 správcích balíčků. Renovate obvykle běží pravidelně ve vašem úložišti v rámci CI/CD pipeline. Vytváří issue nazvané Dependency dashboard, který sleduje identifikované závislosti. Je schopen otevírat žádosti o sloučení s aktualizovanými závislostmi, včetně aktualizace zamykacích souborů různých formátů. Je také vysoce konfigurovatelný, aby vyhovoval konkrétním potřebám. Žádost o sloučení vytvořenou Renovate můžete vidět na obrázku níže nebo v Demo Renovate Standalone Project na našem GitLabu.

Existují dvě možnosti, jak nastavit Renovate na GitLabu (a specificky na gitlab.ics.muni.cz):

1. Nastavit Renovate pro celou skupinu
2. Nastavit Renovate pro jednotlivé projekty

V následujících odstavcích popisujeme doporučené nastavení konfigurace.

Jak nastavit Renovate pro skupinu

Nastavení Renovate pro každý nový projekt může být poněkud zdlouhavé. Z tohoto důvodu je velmi výhodné nastavit jej jednou a používat Renovate bot pro celou skupinu. Funkční příklad si můžete prohlédnout na našem GitLabu: Demo Renovate Group.

Nejprve je třeba vytvořit nový projekt ve skupině, která bude hostit konfiguraci Renovate a CI/CD pipeline. Nazvěme jej renovate-bot. Vytvořte soubor renovate.json s následujícím obsahem. Jedná se o výchozí konfigurační soubor rozšířený o přednastavení, které aktualizuje samotného bota Renovate:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "gitlab>renovate-bot/renovate-runner"
  ]
}

Následně nastsavte CI/CD pipeline vytvořením souboru.gitlab-ci.yml s následujícím obsahem.. Nezapomeňte při tom změnit hodnotu proměnné RENOVATE_EXTRA_FLAGS. Tato proměnná je dodatečnou pojistkou, která zajišťuje, že bot Renovate nebude zasahovat do projektů mimo skupinu, ve které jej nakonfigurujete.

# renovate by měl automaticky aktualizovat release tag `v24.0.0` na poslední verzi  
include:
  - remote: https://gitlab.com/renovate-bot/renovate-runner/-/raw/v24.0.0/templates/renovate.gitlab-ci.yml

# místo 'dependency-scanning-demo' použijte název vaší skupiny
variables:
  RENOVATE_EXTRA_FLAGS: '--autodiscover=true--onboarding=false \ 
  --autodiscover-filter=dependency-scanning-demo/*' 

# požadované změny pro zajištění kompatibility (platí pro gitlab.ics.muni.cz)
renovate:
  image:
    pull_policy: if-not-present

Výše uvedená konfigurace zajišťuje, že Renovate zpracovává pouze projekty s souborem renovate.json ve výchozí větvi. To vám umožňuje postupně nastavit Renovate ve vaší skupině. Pokud chcete nastavit Renovate pro všechny projekty ve skupině najednou, nastavte --onboarding=true namísto --onboarding=false. Renovate vytvoří požadavky na sloučení ve všech projektech, ve kterých najde soubor renovate.json. Renovate je nesloučí, to je na vás. Pokud chcete nějaký projekt vyloučit, uzavřete požadavek na sloučení.

Musíme vytvořit přístupový token skupiny pro Renovate. Otevřete nastavení skupiny, přístupové tokeny a vytvořte nový přístupový token s názvem RENOVATE_BOT². Token vyžaduje roli vývojáře s api scope. Dále otevřete dříve vytvořený projekt renovate-bot, přejděte do Nastavení, CI/CD, Proměnné a vytvořte proměnnou CI/CD s názvem RENOVATE_TOKEN s hodnotou dříve vytvořeného přístupového tokenu skupiny. Nastavte pro něj maskovanou a skrytou možnost, aby byl skrytý v protokolech CI/CD.

2. Samozřejmě si můžete vybrat libovolný název. Název tokenu bude použit jako autor GitLab issue, merge requestů a (ve výchozím nastavení) commitů.

Aby Renovate fungoval správně, potřebuje API token pro GitHub, aby mohl kontrolovat vydání a poznámky k vydání veřejných závislostí. Token nevyžaduje žádná oprávnění, takže je bezpečné použít váš osobní účet. Přihlaste se do GitHubu, přejděte do Nastavení, Nastavení vývojáře, Osobní přístupové tokeny a Detailní tokeny. Vytvořte token s názvemRENOVATE_TOKEN s přístupem k veřejným projektům a bez dalších oprávnění. Poté vytvořte v projektu renovate-bot novou proměnnou CI/CD s názvem GITHUB_COM_TOKEN s hodnotou tokenu, který jste právě vytvořili. Nastavte pro něj maskovanou a skrytou možnost, aby byl skrytý v protokolech CI/CD.

CI/CD Renovate běží pouze v naplánovaných pipelinech. Vytvořte plán pipeline, aby se pipeline spouštěla pravidelně. V projekturenovate-bot přejděte do části Build > Pipeline schedules a vytvořte nový plán. Naplánovanou pipeline ihned spusťte.

Pokud vše proběhlo v pořádku, v projektu renovate-bot by se měla zobrazit nová položka s názvem Dependency Dashboard. Dashboard obsahuje seznam všech identifikovaných závislostí, tipy k problémům s konfigurací a seznam otevřených žádostí o sloučení pro aktualizované závislosti.

Pokud jste v proměnné RENOVATE_EXTRA_FLAGS použili --onboarding=true, Renovate by měl automaticky otevřít žádosti o sloučení v projektech ve vaší skupině. Pokud ne, vytvořte soubor renovate.json s výchozí konfigurací v projektech, ve kterých chcete Renovate povolit:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config: recommended"
  ]
}

Jak nastavit Renovate pro jeden projekt

Následující návod popisuje nastavení Renovate pro jeden projekt. Je užitečný pro testování a pro prostředí citlivá na bezpečnost, protože bot je lokální pouze pro samotný projekt a není sdílen se skupinou. Podívejte se na ukázkovém projektu, který jsme vytvořili, abyste si mohli sami prohlédnout konfiguraci.

Otevřete projekt, pro který chcete nastavit Renovate. Vytvořte přístupový token projektu a proměnné CI/CD. Názvy a požadovaná oprávnění jsou stejná jako při nastavení pro skupinu. Nyní vytvoříme novou větev, která bude obsahovat konfiguraci CI/CD. Děláme to proto, abychom oddělili pipeline Renovate od hlavní pipeline (chceme, aby běžel pouze Renovate a přeskočily se ostatní úlohy, které by běžely na výchozí větvi, jako jsou testy a sestavení). Vytvořte novou prázdnou větev:

git switch --orphan renovate-bot

Create .gitlab-ci.yml in the renovate-bot branch with the following contents:

# renovate by měl automaticky aktualizovat release tag `v24.0.0` na poslední verzi
include:
  - remote: https://gitlab.com/renovate-bot/renovate-runner/-/raw/v24.0.0/templates/renovate.gitlab-ci.yml
    
variables:
  RENOVATE_EXTRA_FLAGS: '--autodiscover=true--onboarding=false'

# požadované změny pro zajištění kompatibility (platí pro gitlab.ics.muni.cz)
renovate:
  image:
    pull_policy: if-not-present

Odevzdejte soubory a odešlete větev renovate-bot do GitLabu. Nastavte větev jako chráněnou, protože obsahuje konfiguraci CI/CD s přístupovým tokenem API.

Nyní přejděte do výchozí větve svého projektu (obvykle main nebo master) a vytvořte v ní soubor renovate.json s následujícím obsahem. Je stejný jako výše, pouze s přidáním možnosti baseBranchPatterns. Ve výchozím nastavení se Renovate spouští pouze ve výchozí větvi. Chceme, aby aktualizoval také samotný Renovate runner ve větvi renovate-bot. Proto tato změna.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "gitlab>renovate-bot/renovate-runner"
  ],
  "baseBranchPatterns": ["$default", "renovate-bot"]
}

Commitněte soubor. Nyní vytvořte plán pipeline ve větvi renovate-bot a spusťte pipeline. Měl by se zobrazit panel závislostí.

Pokročilé konfigurace a další zdroje

Další možnosti konfigurace naleznete v dokumentaci. Můžete např. přidat default assignee, přidat merge request štítky, nebo sloučit drobné updaty do jednoho.

Moderní programovací jazyky

Moderní jazyky mají svůj vlastní ekosystém, který obvykle zahrnuje správce balíčků s integrovaným nástrojem pro skenování závislostí. Některé příklady:

• npm audit ayarn audit pro JavaScript a TypeScript
• composer pro PHP
• pip-audit pro Python
• dotnet pro .NET
• govuln pro Golang
• cargo audit pro Rust

Poslední dva ještě nejsou plně integrovány a nejsou tak vyspělé jako ostatní.

Další nástroje

GitHub má vlastní vestavěný nástroj pro skenování závislostí s názvem Dependabot. Jedná se o bota, který automaticky vytváří pull requesty pro aktualizaci závislostí ve vašem repozitáři a zasílá vám oznámení o zranitelnostech ve vašich závislostech.

Syft je nástroj pro vytváření SBOM z softwarových projektů a kontejnerů. Grype je nástroj zaměřený na bezpečnost, který kontroluje zranitelnosti v závislostech, kontejnerech a souborových systémech. Grype podporuje 13 balíčků operačních systémů a mnoho balíčků specifických pro programovací jazyky. SBOM můžete buď vygenerovat pomocí Syftu a předat jej Grype, nebo jednoduše spustit Grype, který SBOM generuje interně. Integrace mezi Syftem/Grype a CI/CD pipeline chybí, proto je nejlepší je používat lokálně. Níže uvádíme několik běžných případů použití:

# zkontroluje závislosti
syft .

# uloží SBOM do souboru
syft . -o cyclonedx-json > sbom.json

# sken SBOM na zranitelnosti
grype sbom:sbom.json

# sken projektu v lokálním adresáři pomocí Grype
grype .

# sken kontejneru
grype docker:docker.io/debian:latest --only-fixed

Trivy je alternativou k výše zmíněnému Grype a plní podobnou funkci. Kromě zranitelností je také schopen skenovat odhalené tajné informace a běžné nesprávné konfigurace v repozitářích infrastruktury jako kódu (IaC). Zde jsou příkazy:

# sken projektu v lokálním adresáři
trivy filesystem .

# sken kontejneru
trivy image docker.io/debian:latest --ignore-unfixed

OSV-Scannner od Google a Dependency-Check od OWASP jsou další nástroje, které mohou být použity pro dependency scanning.

Shrnutí

V tomto průvodci jsme představili nástroj GitLab Dependency Scanning, který se velmi snadno nastavuje a poskytuje upozornění na zranitelné softwarové komponenty v určitých projektech. Poté jsme se věnovali nástroji Renovate, jehož první nastavení je o něco složitější, ale který pokrývá mnohem více jazyků a pomáhá snadno aktualizovat závislosti. Na závěr jsme představili několik dalších ručních nástrojů, které stojí za zvážení.

Máte-li jakékoli dotazy týkající se tutoriálu nebo potřebujete-li pomoc s jeho konfigurací, neváhejte nás kontaktovat na adrese csirt@muni.cz.