Statická analýza kódu (Static code analysis)

Příklady z praxe

1. 01

   Odhalení SQL injection v datovém toku

   Bezpečnostní analyzátor sleduje hodnotu z HTTP parametru (zdroj) až do místa, kde se skládá SQL dotaz (sink). Protože mezi nimi není žádná sanitizace ani parametrizace, nahlásí kritickou zranitelnost ještě před merge pull requestu. Oprava spočívá v přechodu na parametrizovaný dotaz, který nástroj rozpozná jako bezpečný.

   # Nález: nedůvěryhodný vstup končí v SQL dotazu
   query = "SELECT * FROM users WHERE email = '" + request.args["email"] + "'"
   db.execute(query)
   
   # Po opravě analyzátor mlčí
   db.execute("SELECT * FROM users WHERE email = %s", (request.args["email"],))

2. 02

   Postupné zavedení linteru do staršího projektu

   Tým převzal pět let starý Node.js projekt bez linteru. Po zapnutí doporučené sady pravidel ESLint vypsal přes osm tisíc varování, což by zablokovalo veškerou práci. Řešením bylo vygenerovat baseline soubor se současnými nálezy, nastavit CI tak, aby padalo jen na nových porušeních, a odbourávat starý dluh po adresářích při běžném refactoringu.

   # CI kontroluje jen soubory změněné vůči hlavní větvi
   git diff --name-only origin/main...HEAD -- '*.ts' | xargs npx eslint --max-warnings=0

Časté omyly

MýtusKdyž projde statická analýza bez nálezu, kód je bezpečný.

Ve skutečnostiStatická analýza pokrývá jen vzory, na které má pravidla, a u dynamických konstrukcí je nutně nepřesná. Chyby v obchodní logice, špatné oprávnění nebo zneužití platné funkcionality nezachytí. Bezpečnost potřebuje i testy, dynamickou analýzu a review.

MýtusStatická analýza je jen kontrola formátování a odsazení.

Ve skutečnostiFormátování řeší formatter (Prettier, gofmt). Statická analýza nad tím staví typové kontroly, detekci nedosažitelného kódu, úniků prostředků, race conditions i celé datové toky od nedůvěryhodného vstupu k nebezpečné operaci.

MýtusFalešně pozitivní nálezy znamenají, že nástroj je k ničemu.

Ve skutečnostiUrčitý podíl falešných poplachů je daní za to, že analyzátor uvažuje o všech možných průbězích programu. Řešením je vyladit sadu pravidel na projekt, ne nástroj vypnout. Trvale hlučné pravidlo je lepší vypnout cíleně než ignorovat všechna.

Časté dotazy

Kdy statická analýza nestačí a je potřeba dynamické testování?

Statická analýza nestačí všude, kde na výsledku rozhoduje běhové prostředí. Chování pod souběžnou zátěží, skutečné odpovědi externích API, konfigurace nasazení, výkonnostní regrese a správnost obchodních výpočtů se ze zdrojového kódu spolehlivě odvodit nedají. Tyto oblasti pokrývají jednotkové a integrační testy, dynamická analýza za běhu, profilování a penetrační testování. Rozumná sestava kombinuje obojí: statická analýza chytá levné a časté chyby okamžitě, dynamické metody ověřují, že složený systém opravdu dělá to, co má.

Jak nastavit statickou analýzu, aby ji tým nezačal ignorovat?

Klíčem je malá a ostrá sada pravidel místo maximálního nastavení. Doporučený postup: začít s doporučeným presetem nástroje, vypnout pravidla, která v daném projektu generují převážně šum, zafixovat existující nálezy jako baseline a blokovat build jen na nově zavedených porušeních. Nálezy musí být rychlé a musí se zobrazovat přímo v editoru a v pull requestu, ne až v nočním reportu. Pravidlo, které se soustavně potlačuje komentářem, patří k revizi nebo k vypnutí.

Zpomaluje statická analýza CI pipeline?

Statická analýza přidává do pipeline čas, ale rozsah se velmi liší. Lintery a moderní nástroje psané v Rustu zvládnou střední repozitář v jednotkách sekund. Typová kontrola trvá desítky sekund až minuty a hluboká bezpečnostní analýza s datovými toky může u velké kódové báze běžet i desítky minut. Běžná strategie je pouštět rychlé kontroly na každý push a nákladnou bezpečnostní analýzu jen na hlavní větev nebo v noci, případně analyzovat inkrementálně pouze změněné soubory.

Nahradí statická analýza code review?

Statická analýza code review nenahradí, protože každý řeší jinou třídu problémů. Nástroj spolehlivě odhalí mechanické chyby: nepoužité proměnné, nekontrolované návratové hodnoty, nebezpečné datové toky, porušení konvencí. Recenzent naopak posuzuje, zda řešení odpovídá zadání, zda je návrh srozumitelný a udržitelný a zda nezavádí zbytečnou složitost. Praktický přínos je v tom, že automatická kontrola z review odstraní nudné výtky k formě, takže lidský čas zbyde na architekturu a smysl změny.

Zdroje

1. Source Code Analysis Tools(otevře se v novém okně)OWASP Foundation
2. Static program analysis(otevře se v novém okně)Wikipedia
3. TypeScript Documentation(otevře se v novém okně)Microsoft
4. Source Code Security Analyzers(otevře se v novém okně)NIST

Související pojmy

• CI/CDCI/CD je sada postupů a automatizací, které průběžně integrují změny kódu, ověřují je testy a připravují nebo provádějí nasazení aplikace. Cílem je zkrátit cestu od commitu k bezpečnému vydání, snížit ruční práci a rychle odhalit chyby v build procesu, konfiguraci nebo samotném kódu.
• Code reviewCode review je systematická kontrola změn ve zdrojovém kódu jiným vývojářem nebo týmem před jejich začleněním do hlavní větve. Pomáhá najít chyby, bezpečnostní rizika, nejasný návrh i odchylky od týmových pravidel, ale zároveň slouží ke sdílení znalostí a sjednocování stylu práce.
• LinterLinter je nástroj statické analýzy, který kontroluje zdrojový kód bez jeho spuštění a upozorňuje na porušení pravidel, podezřelé konstrukce nebo nekonzistentní styl. Pomáhá zachytit chyby dřív než při testování či code review a často se spouští v editoru, před commitem nebo v CI pipeline.
• Technický dluhTechnický dluh je stav, kdy software nese následky rychlejšího nebo kompromisního rozhodnutí, které zjednodušilo dodání, ale ztížilo budoucí změny. Dluh může být vědomý i nechtěný; projevuje se složitějším kódem, chybějícími testy, zastaralými knihovnami, křehkou architekturou nebo dražším provozem a postupně vytváří „úrok“ v podobě pomalejšího vývoje.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.