Dodavatelský řetězec FiveM resources a proč pořád selhává

Zeptejte se provozovatele, odkud resource pochází, a odpovědí bude většinou jméno platformy. Zeptejte se, jak ví, že soubor, který má, je ten, který platforma vydala, a rozhovor skončí. Tahle mezera je problém dodavatelského řetězce FiveM shrnutý do jedné výměny.

Cesty, kterými kód skutečně putuje

Nejde o to, že některé kanály jsou špatné a jiné dobré. Jde o to, že žádný kanál nedává to, co provozovatel skutečně potřebuje: způsob, jak ověřit, že tenhle archiv je ten, který autor zamýšlel vydat, a že se mezi ním a vámi nic nezměnilo.

Čtyři způsoby, jak se řetězec láme

1. Vstupní kontrola se plete s průběžným auditem

Kontrola na marketplace odpovídá na otázku „má tahle nabídka existovat“ — funguje to, patří to nahrávajícímu, neporušuje to pravidla. To je od marketplace rozumné a je nerozumné to vykládat jako „tenhle kód byl prověřen na škodlivé chování a bude znovu při každé aktualizaci“.

2. Distribuce bez doložitelného původu

Zip v Discord kanálu nemá autora, verzi, kontrolní součet ani historii. Může být identický s vydáním dodavatele. Může mít jeden soubor navíc. Neexistuje mechanismus, kterým byste to poznali, a důvody, proč někdo znovu nahrává placený resource zdarma, nebývají charitativní.

3. Důvěra zděděná forky a přejmenováním

Resources se forkují, přejmenovávají, balí do „packů“ a přeprodávají. Každý krok nese dál reputaci originálu, zatímco se kód rozchází. Za rok si provozovatel nainstaluje něco doporučeného za to, co uměl originál, a spustí kód, který původní autor nikdy neviděl.

4. Neexistuje odvolání

Když se zjistí, že je resource škodlivý, neexistuje mechanismus, který by se dostal na servery, kde už běží. Nabídka může zmizet; kopie běží dál, re-uploady se šíří dál a provozovatelé, kteří to nainstalovali před půl rokem, se to nedozvědí. Tohle je pravděpodobně nejškodlivější mezera ze všech, protože každý incident má neomezený ocas.

Co by to skutečně spravilo

Ty primitivy jsou z jiných ekosystémů dobře známé; tady prostě zatím neexistují.

• Podepsaná vydání. Podpis autora nad archivem, ověřitelný kýmkoli, by otázku „je tohle to, co vydali“ zrušil úplně.
• Zveřejňované kontrolní součty jako norma, aby se re-upload dal alespoň porovnat s originálem.
• Pinování verzí a changelogy, aby provozovatel věděl, co se změnilo, ne jen že se něco změnilo.
• Kanál pro odvolání — nějaký způsob, jak běžícím serverům říct, že verze, kterou mají, je známo špatná.
• Sdílený otevřený detekční obsah, aby nález jedné strany chránil všechny, ne jen její zákazníky.

Ten poslední bod je důvod, proč detekční práci publikujeme otevřeně a proč je Titan Security rámovaný jako sdílená infrastruktura, ne jako funkce produktu. Nález, který zůstane uvnitř zákaznické základny jednoho dodavatele, nechá ekosystém přesně tak vystavený, jak byl.

Co může provozovatel udělat dnes

1. 1

   Zaznamenejte původ při instalaci

   Zdrojová URL, verze, datum, kdo schválil. Pět polí v tabulce. Je to nejhodnotnější návyk, protože všechno ostatní stojí na tom, že víte, co jste nainstalovali.

2. 2

   Nechte si původní archiv

   Je vaší základnou pro porovnání. Bez něj v budoucnu nezodpovíte otázku „změnilo se to?“.

3. 3

   Revidujte nebo skenujte před instalací

   Ruční revize u malých resources, automatická statická analýza u všeho ostatního. Rozhodnutí musí předcházet tomu, aby kód dostal vaše přístupy.

4. 4

   Preferujte kanály s alespoň nějakým doložitelným původem

   Dodavatel s doménou, changelogem a historií podpory poráží anonymní re-upload, i když je soubor identický — protože příště nebude.

5. 5

   Kontrolujte znovu při aktualizaci

   Berte každou aktualizaci jako nový resource z neznámého zdroje, protože z hlediska dodavatelského řetězce přesně to je.

Nic z toho nedělá dodavatelský řetězec důvěryhodným. Dělá to vaši pozici v něm obhajitelnou, což je jiný a dosažitelný cíl. Řetězec se zlepší, až budou existovat podpisy a odvolání; do té doby se ověření musí odehrát na posledním článku — a tím posledním článkem jste vy.