Audit google/zx s a bez revizní dovednosti

Skill Bench, část 4 ze 4. Stejný model, stejný prompt, jedna dovednost nainstalovaná nebo ne. Dále v sérii: přistávací stránka, Telegram bot a ladění hry had.

Tři příspěvky v této sérii ukazovaly konzistentní vzor: větev s dovedností dělá více, kontroluje více, spotřebuje více tokenů a produkuje promyšlenější výsledek. Tento příspěvek tento vzor narušuje. Je to jediný případ v celém testu, kdy běh s dovedností byl levnější než základní linie, a zároveň je to jediný případ, kdy větev s dovedností přehlédla největší nález série. Obě věci platí současně a napětí mezi nimi je nejužitečnějším výsledkem, který jsme z tohoto projektu získali.

Proč google/zx

Chtěli jsme úkol auditu kódu se třemi vlastnostmi: skutečný kód, ne syntetický úryvek s uměle vloženou chybou; něco, co by mohl být středně pokročilý vývojář požádán zkontrolovat v úterý; a dostatečně známá kódová základna, aby si čtenáři mohli ověřit naše tvrzení proti skutečnému zdroji, namísto aby nám slepě důvěřovali.

google/zx splňoval všechny tři. Je to knihovna Google pro psaní shell skriptů v JavaScriptu, dostatečně populární, aby na ní závisela významná část nástrojů Node, a dostatečně malá, aby audit jednoho souboru byl spravedlivým úkolem spíše než výzkumným projektem. Vybrali jsme src/core.ts, soubor, který provádí skutečné spouštění procesů a zpracování prostředí, stažený čerstvě z repozitáře. Nic zde není uměle vytvořená zranitelnost. Je to skutečný, aktivně udržovaný soubor a zx je obecně dobře postavený: čistá struktura, rozumné výchozí hodnoty ve většině míst, typ kódu, který projde běžným čtením. To je přesně to nastavení, kde audit buď prokáže svou hodnotu nalezením jedné věci, kterou běžné čtení přehlédne, nebo ne.

Metodika

Dva běhy, stejný model, stejná instrukce: auditovat src/core.ts z google/zx a vytvořit nálezy seřazené P0 až P3, každý s umístěním, popisem, co se porouchá, kdy se porouchá a minimální opravou. Běh jedna dostal tento popis a nic jiného. Běh dva dostal identický popis plus náš vlastní kontrolní seznam pro bezpečnostní a kódovou revizi, ten, který je součástí našeho Security Packu a Developer Toolkitu, přečtený v plném rozsahu před zahájením auditu.

Stejné upozornění jako u každého jiného příspěvku v této sérii: jedná se o jeden běh na větev, jeden model, jeden soubor. Netvrdíme, že se konkrétní počty nálezů replikují při opakovaném spuštění. To, co hlásíme, je to, co se stalo, se skutečnou telemetrií z testovacího prostředí a vzorem v typu věcí, které každá větev zachytí, což se podle nás zobecňuje lépe než samotná surová čísla.

Co našla základní linie

Model, ponechán sám sobě, přečetl core.ts a z vlastní iniciativy si před sepsáním čehokoli stáhl také util.ts a error.ts pro kontext. Nikdo mu to neřekl. Rozhodl se, že soubor nedává smysl izolovaně, a podíval se na jeho sousedy, což se ukázalo jako důležité.

Nejvýznamnější nález základní linie a nález s nejvyšší závažností z celého testu je tento. Na řádku 139 core.ts nastavuje výchozí možnost prostředí na env: process.env. To není kopie prostředí, je to živý odkaz na něj. Jakmile to víte, důsledek je přímočarý: pokud jakákoli cesta kódu provede něco jako $.env.FOO = 'x', nenastavuje proměnnou omezenou na jedno volání shellu. Mutuje process.env pro celou běžící aplikaci, což znamená, že každá jiná část programu, každá jiná knihovna, cokoli, co čte proměnné prostředí po tomto bodě, vidí změnu. Konfigurační úprava určená pro jedno volání podprocesu uniká do globálního stavu. V dlouho běžícím serverovém procesu nebo v jakémkoli skriptu, který rozvětvuje více volání zx s mírně odlišnými prostředími, je to typ chyby, která se neobjeví v rychlém testu a pak o dny později poškodí zcela nesouvisející část systému. Ověřili jsme to přímo proti zdroji, spíše než abychom se spoléhali na slovo modelu, a řádek dělá přesně to, co nález uvádí.

Zbytek seznamu základní linie, hodnocený jako P2 a P3, byl solidní, aniž by byl spektakulární: selhání detekce bash, které je tiše pohlceno a později se objeví jako zavádějící, nesouvisející chybová zpráva namísto skutečné příčiny, a případ, kdy break() vyvolá synchronně zevnitř .catch() handleru, což je typ chyby v řízení toku, který se snadno napíše a je otravný na ladění, protože zásobník volání ukazuje na neužitečné místo.

Celkový součet základní linie: jeden P1, dva P2, čtyři P3.

Co našla větev s kontrolním seznamem

Běh řízený dovedností se řídil naším kontrolním seznamem pro revizi kódu, stejným, který je popsán v našem přehledu bezpečnostních dovedností, a četl se jako úplně jiný recenzent: stejný soubor, stejný přístup, objevila se zcela odlišná sada problémů.

Jeho nejlepší nález bylo neošetřené odmítnutí promise: místa volání pro break() a timeout() vyvolávají kill() bez await, takže odmítnutí z tohoto volání nemá kam dopadnout a může shodit proces mimo jakýkoli try/catch, který volající napsal. Také zachytil TypeError, který se objeví, když se něco pokusí asynchronně iterovat ProcessPromise poté, co již byla zastavena, což je skutečný okrajový případ, který se objeví pouze při specifické sekvenci volání. A upozornil, že ZX_PREFIX a ZX_POSTFIX jsou vkládány přímo do každého volání shellu bez sanitizace, což si zaslouží pozornost správce, pokud některá z těchto hodnot může pocházet zvenčí důvěryhodného autora skriptu.

Jedná se o skutečné, dobře formulované nálezy, nikoli výplň. Zpráva větve s kontrolním seznamem byla také použitelnější z obou dokumentů sama o sobě: jednotná struktura, konzistentní jazyk závažnosti, každý záznam sledující stejný formát umístění-dopad-oprava, aniž by model musel tento formát vymýšlet za běhu.

Celkový součet kontrolního seznamu: dva P2, pět P3. Žádné P1, a pozoruhodně, žádný nález týkající se process.env.

Překryv a jak malý byl

Seřaďte oba seznamy a překryv je téměř nulový. Šest nálezů základní linie, sedm nálezů kontrolního seznamu, celkem třináct, a ani jeden z nich nepojmenovává stejnou hlavní příčinu. Mutace process.env. Pohlcení detekce bash. Synchronní vyvolání v catch. Nečekané kill(). TypeError zastaveného iterátoru. Nesanitizované vložení prefixu/postfixu. Každý jednotlivý je jiná cesta kódu.

To je větší překvapení než kterýkoli jednotlivý seznam. Dva kompetentní recenzenti, kteří se dívají na stejných zhruba 300 řádků TypeScriptu, jeden vedený strukturovaným kontrolním seznamem a druhý ne, a dospějí k téměř zcela odlišným sadám problémů. Kdybyste nám předem řekli, že běh s kontrolním seznamem v podstatě dvakrát zkontroluje seznam základní linie a přidá vylepšení, věřili bychom tomu. To se nestalo. Kontrolní seznam neupřesnil stejné hledání, provedl jiné hledání.

Čísla

	Základní linie (bez dovednosti)	Větev s dovedností (kontrolní seznam pro revizi kódu)	Delta
Použité tokeny	87,899	81,743	−7%
Nálezy P1	1	0	−1
Nálezy P2	2	2	0
Nálezy P3	4	5	+1
Celkem nálezů	7	7	0
Proaktivně přečtené sousední soubory	Ano (util.ts, error.ts)	Ne	—
Nález s nejvyšší závažností	mutace process.env (ověřeno)	—	—

Každý jiný příspěvek v této sérii ukázal, že větev s dovedností stála více tokenů za disciplinovanější výsledek. Toto je jediná výjimka: větev s kontrolním seznamem byla o 7 % levnější. Naše interpretace je, že kontrolní seznam zužuje prostor pro hledání, a užší prostor pro hledání je levnější na provedení, i když je to také ten, který uzavírá některé cesty, kterými by se volný průchod mohl vydat.

Spodní vs. horní hranice

Toto je to nejostřejší, co jsme se naučili napříč všemi čtyřmi příspěvky, a nejjasněji se to projevuje zde. Kontrolní seznam zlevnil audit a dal mu přísnější, konzistentnější formát. Co však neudělal, bylo nalezení chyby process.env, protože tento nález nepocházel z žádné kategorie v kontrolním seznamu. Vzešel z toho, že základní linie si všimla, že core.ts samotný byl těžko pochopitelný, rozhodla se sama stáhnout util.ts a error.ts a následovala tento instinkt někam, kam struktura kontrolního seznamu nikdy neukazovala.

Kontrolní seznam zvyšuje spodní hranici. Zaručuje minimální standard pokrytí: každá kategorie je zkontrolována, každý nález je sepsán stejným způsobem a neztratíte snadný úlovek kvůli špatnému dni. Nezvyšuje horní hranici. Nejlepší možný nález v daném souboru může ležet mimo každou kategorii, kterou kontrolní seznam uvádí, a proces, který prochází pouze kontrolním seznamem, ho s jistotou přejde, v pěkně formátované zprávě.

To není argument proti kontrolním seznamům. Žádný ze sedmi nálezů kontrolního seznamu nebyl špatný a dva z nich byly takové, které zaneprázdněný lidský recenzent pravděpodobně přehlédne pod časovým tlakem. Je to argument pro to, abychom věděli, k čemu kontrolní seznam slouží. Je to nástroj pro zvýšení spodní hranice, nikoli horní, a považovat ho za obojí je způsob, jak skutečný P1 proklouzne recenzí, která jinak vypadá důkladně.

Jak provést dvoufázový audit sami

Vzhledem k tomu, co jsme zjistili, naše skutečné doporučení není „použijte kontrolní seznam“ nebo „vynechejte kontrolní seznam“. Je to provést obojí, na všem, na čem záleží.

Začněte volným průchodem. Nasměrujte model na soubor, dejte mu popis auditu a nechte ho číst cokoli dalšího, co chce. Nedávejte mu rubriku. Toto je průchod, který má největší šanci zachytit věc, kterou nikdo nepomyslel zařadit na seznam, protože není omezena seznamem.

Poté proveďte druhý, samostatný průchod se strukturovaným kontrolním seznamem, naším nebo vaším vlastním. Toto je průchod, který zaručuje pokrytí: kategorie, které je nudné kontrolovat ručně, ale snadné přeskočit, když se řídíte instinktem, sanitizace, zpracování chyb, uvolňování zdrojů, jsou vždy zkontrolovány.

Porovnejte obě zprávy, než některou z nich budete považovat za konečnou. Pokud se naše číslo překryvu potvrdí na vašem kódu stejně jako na zx, očekávejte, že se oba seznamy budou shodovat v méně než polovině nálezů. Považujte to za očekávaný výsledek, nikoli za známku selhání některého z průchodů. Úplný testovací protokol podrobněji popisuje, jak strukturovat tento typ párového běhu, včetně toho, jak kontrolujeme, aby model nečetl svůj vlastní předchozí výstup.

Pokud máte rozpočet pouze na jeden průchod, naše upřímná rada založená na tomto výsledku zní: nejprve spusťte volný průchod. Je to ten, který s větší pravděpodobností najde nález, který jste nevěděli, že máte hledat. Poté, pokud to čas dovolí, doplňte ho kontrolním seznamem, abyste se ujistili, že nic nudného nebylo přehlédnuto. Pro širší pohled na to, které dovednosti zvládají tento typ revize dobře, se podívejte na náš přehled nejlepších kódovacích dovedností.

Často kladené otázky

Je nález process.env skutečnou zranitelností v zx? Jedná se o skutečné chování, které si zaslouží pozornost správce, nikoli zveřejněnou CVE a nic, co bychom označovali za aktivní exploit. zx je celkově dobře postavená, aktivně udržovaná knihovna, a toto je designové rozhodnutí, živý odkaz namísto kopie, které má skutečný mutační důsledek pro jakoukoli cestu kódu, která zapisuje do $.env. Řádek jsme si sami ověřili proti zdroji, spíše než abychom důvěřovali zprávě modelu, což je přesně důvod, proč se cítíme komfortně označit to za nejvýznamnější nález celého testu.

Proč zde větev s dovedností stála méně, když všude jinde v této sérii stála více? Naše nejlepší vysvětlení je rozsah. Designová dovednost v příspěvku o přistávací stránce vybízí k iteraci: zkontrolujte výstup, revidujte, zkontrolujte znovu. Kontrolní seznam pro revizi funguje jinak. Definuje pevnou sadu kategorií, které se projdou jednou, což zužuje hledání namísto jeho rozšiřování. Užší hledání, méně tokenů. Je to věrohodný mechanismus, nikoli prokázaný, jelikož se jedná o jediný běh.

Mám věřit AI revizi kódu řízené kontrolním seznamem, že zachytí vše? Ne, a to je hlavní zjištění zde. Kontrolní seznam je nástroj pro zvýšení spodní hranice: zaručuje konzistentní minimální pokrytí známých kategorií. Není to nástroj pro zvýšení horní hranice a největší nález v celém tomto testu pocházel z průchodu, který se jím neřídil. Použijte kontrolní seznam pro pokrytí a konzistenci. Nepoužívejte ho jako jediný průchod u kódu, na kterém skutečně záleží.

Co to znamená pro výběr dovednosti Claude pro revizi kódu v praxi? Nepovažujte „kterou dovednost“ za jediné rozhodnutí. Považujte „kolik průchodů“ za důležitější. Dobrá dovednost s kontrolním seznamem, jako je ta v našem seznamu kontrolních seznamů pro revizi kódu, stojí za instalaci pro konzistenci a kategorie, které zaručuje. Spárujte ji s alespoň jedním neřízeným průchodem na čemkoli, co byste skutečně nasadili, a přečtěte si naše pokrytí bezpečnostních dovedností o tom, jak vážíme revizní dovednosti proti sobě v katalogu.

To je celá série. Čtyři úkoly, čtyři upřímné verdikty a společná nit napříč všemi je stejná: dovednost mění to, co model kontroluje, nikoli to, zda je schopen práci vykonat. Zda se tato výměna vyplatí, závisí zcela na tom, co stavíte a jak pečlivě se na to bude kdokoli dívat poté.