Co všechno v mém projektu stojí na zranitelné součásti: audit závislostí
Vyšla zranitelnost v knihovně, runtime nebo obrazu, který možná používáš. Tenhle prompt vezme tvůj composer.json, package.json, Dockerfile nebo requirements.txt, zjistí, kde se zranitelná součást skrývá i nepřímo, a seřadí, co opravit nejdřív a jak ověřit, že oprava sedí.
Jsi bezpečnostní inženýr. Zjisti, jestli a kde se mého projektu týká tato zranitelnost: [NÁZEV A CVE, NAPŘ. CVE-2026-109618 A CVE-2026-109619 V PHP, OPRAVENO V 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, ZRANITELNÉ VŠECHNY STARŠÍ VERZE OD 5.4] Tady jsou soubory projektu, které určují, co se instaluje a na čem to běží: [VLOŽ composer.json, composer.lock, package.json, Dockerfile, docker-compose.yml, requirements.txt, .github/workflows, konfiguraci hostingu, NEBO CO MÁŠ] Postupuj takto: 1. Najdi každé místo, kde se zranitelná součást objevuje: přímo (verze runtime, obraz v Dockerfile), nepřímo (závislost, která ji vyžaduje), i mimo kód (CI runner, lokální vývojové prostředí, cron na serveru, staging). U každého uveď soubor a řádek. 2. U každého nálezu urči: jakou verzi tam skutečně mám (ne jakou „chci" v constraintu), jestli je zranitelná, a kdo verzi řídí: já, hosting, obraz, nebo distribuce. 3. Seřaď nálezy podle rizika: nejdřív to, co je vystavené internetu bez přihlášení, pak interní, pak vývojové prostředí. 4. Pro každý nález napiš opravu: přesnou změnu v souboru nebo příkaz, a jak ověřit, že se oprava skutečně projevila za běhu (ne jen v souboru). Upozorni na místa, kde změna verze může něco rozbít (zrušené funkce, změněné výchozí hodnoty). 5. Na konci napiš, co jsi nemohl z dodaných souborů zjistit, a jaké příkazy mám spustit, abys to dořešil. Nic nepředpokládej o tom, co „asi" na serveru je. Když to v souborech není, řekni to.
Proč tento prompt funguje
Nejčastější chyba po zveřejnění zranitelnosti je spokojit se s opravou tam, kde ji vidíš. Runtime je přitom typicky na čtyřech místech: v Dockerfile, na produkčním serveru, v CI a na notebooku vývojáře, a každé řídí někdo jiný. Prompt proto hledá i nepřímé a mimokódové výskyty a u každého se ptá, kdo verzi ovládá, protože od toho se odvíjí, jestli stačí commit, nebo e-mail hostingu. Rozlišení „verze v constraintu" vs. „verze, kterou skutečně mám" (lock soubor, obraz s tagem latest) je místo, kde se audity nejčastěji mýlí. Bod 4 chce ověření za běhu: soubor může říkat 8.4.27, a proces na serveru dál běží na staré verzi, dokud ho někdo nerestartuje. Prompt se hodí i preventivně, jako inventura toho, co vlastně provozuješ.