Názory k článku
Zatímco se řešily chyby v PHP, útočníci propašovali malware do oblíbené open-source knihovny

Něco podobného se děje i v node.js. Celkem mi to připomíná období, kdy se začal rozšiřovat internet. Někteří mailoví klienti zobrazovali náhled mailu automaticky a pustili i skripty. No tak to jednoho dne někdo začal zneužívat.
.
Popravdě nechápu, proč se u závislostí má vůbec pouštět nějaký kód. Pokud je to potřeba pro nějakou inicializaci, tak by se to zrovna tak mohlo volat v kódu až když to chce někdo použít. Lidi si holt chtěli ušetřit práci a teď se diví, že se to začíná zneužívat taky. Nebo pokud je to tak nutné (což bude spíš u menšiny závislostí), tak ať se dá někde v konfiguráku říct, které závislosti to mohou dělat a zbytek ať vyhodí chybu při buildu. Vývojář to pak může zkontrolovat a pokud je to nutné, tak konfiguraci upravit. Pak by tohle propašování kódu, co se automaticky pustí už při inicializaci repo, nemohlo fungovat. Pokud tam někdo procpe malware, tak všem při aktualizací závislostí popadají buildy a budou zjišťovat, jestli je to u toho balíčku legitimní a fakt to tam přidali. Pravda, neřeší to situaci, kdy někdo upraví existující funkci a něco se zavolá až během normálního běhu. Ale v tom tyto problémy zatím nebývají.

24. 10. 2026, 12:06 editováno autorem komentáře

tohle je přece principálně špatně a limitně to vždy povede k incidentu. Situace, kdy stačí jedná zranitelnost k tomu, aby byl problém tak už je sama o sobě problémem.

Čím silněji se budou všichni tlačit do co nejrychlejších aktualizací, tím bude vznikat daleko větší prostor právě k napedení přes aktualiazace...

Ale chytrý a rychlý AI agent může identifikovat opravu zranitelnosti a do hodiny udělat exploit, ale pak by měl garantované 23h okno na šíření.
To bylo přesně to, co se teď řešilo s PHP. Pokud se vydá oprava na nějakou vážnou zranitelnost, je otázka několika minut, než začne být zneužívána. Proto se kolem toho tak šaškuje s těmi upozorněními „připravte se, v čase T vydáme opravu kritické chyby, ale nesmíme říct, co je špatně – jen buďte připraveni na značkách a hned aktualizujte“.

Předpokládám, že se tenhle typ starých chyb během pár měsíců ze softwaru odchytá, a nové už tolik vznikat nebudou, protože je AI dokáže zachytit ještě před tím, než se ta chyba dostane do ostrého vydání. Ale určitě si ještě užijeme několik perných měsíců.

To ano, ale já myslel jiný aspekt. Např. Když někdo zveřejní opravu na 10 let starou chybu. Nemusí být lidem zřejmé na první pohled, co ten kód má měnit. Ale chytrý a rychlý AI agent může identifikovat opravu zranitelnosti a do hodiny udělat exploit, ale pak by měl garantované 23h okno na šíření.

A pak je i možné, že ani po 24 hodinách si nikdo nevšimne úmyslné nebo neúmyslné chyby a bude tam třeba tři roky. Ale věřím, že s AI se ta detekce zlepší.

Nevýhoda v tom okamžitém zveřejnění a odložené konzumaci může být, že někdo nechá běžet AI roboty, co budou vyhodnocovat komity na zranitelnosti, tak pak budou mít garantované např. 24h okno pro útok. :-|
Ale o to právě jde. Zveřejní se nová verze balíčku. Pustí se do ní good guys a bad guys a hledají zranitelnosti, škodlivý kód apod. Ale nikdo ty balíčky reálně nepoužívá, protože jsou moc čerstvé. Takže bad guys nemají na koho útočit. Balíčky se začnou na cílových systémech (u vývojářů, v CI/CD buildech) aktualizovat třeba až za 24 hodin – a spoléhá se na to, že pokud by tam byl problém, good guys ho mezi tím najdou a dojde třeba k odstranění balíčku s repozitáře.

Třeba Deno na to má konfigurační volbu minimum-dependency-age, která je defaultně (v novějších verzích) právě těch 24 hodin. npm má min-release-age, bun má minimumRelease­Age.

Možnost to přetížit vždycky je, přinejhoším ten čas nastavíte na nulu. Jenže to se musí udělat ručně. Ale jiná cesta asi nebude.

Ono by bylo také fajn kdyby balíčkovací nástroje měli v defaultu zapnuté toto pozdržení. Ne každému tento problém dojde a žádné llm pokud vím tohle nevynutí..

Jo, v podstatě tak jsem to myslel. Ale lépe jste to popsal.

Já bych si uměl představit, že by tam byl nějaký override, který by tu bezpečnostní dobu mohl eliminovat. Ať už např. nějaký force flag na straně uživatele nebo nějaká nezávislá důvěryhodná třetí strana, která se za to zaručí.

Nevýhoda v tom okamžitém zveřejnění a odložené konzumaci může být, že někdo nechá běžet AI roboty, co budou vyhodnocovat komity na zranitelnosti, tak pak budou mít garantované např. 24h okno pro útok. :-|

Naopak, zpoždění se dělá mezi publikací a konzumací balíčku. Dnes už se v některých nástrojích běžně nastavuje, že balíček musí být publikován X hodin, než ho balíčkovací nástroj v rámci aktualizace stáhne.

Zdržovat publikaci nemá smysl – naopak je potřeba, aby po publikování balíček prohlédly nezávislé nástroje, které jej případně mohou označit za podezřelý nebo vadný.

Ten odklad automatické aktualizace ale samozřejmě komplikuje situace jako byla ta oprava PHP, kde naopak bylo potřeba aktualizovat co nejdřív. Ale doufám, že chyby, jako byla v PHP, se s pomocí AI během pár měsíců nebo let najdou a vyřeší, a další podobné už se podaří odchytávat ještě během vývoje. Ne že by to znamenalo, že bude software bezchybný. Ale snad v něm nebudou chyby, které je schopen někdo zneužít během pár minut.

Nedá se nic dělat. Publikace balíčků nebude moct být okamžitá, ale bude tam poviné zpoždění např. 30-60 minut. Někteří vývojáři už dobrovolně nastavují, aby se sami neinstalovaly balíčky, které jsou veřejné méně, než 24 hodin.

Není to už po několikáté, co se jim to stalo? Očekával bych, že to budou mít od té doby lépe zabezpečené.