Съветът е да се използват споделени данни за киберзаплахи. Присъединете се към ISAC. Свържете общностните канали за данни към вашата система за обработка. Това изглежда като добър съвет и аз съм съгласен с него. Това, което никой не ви казва, е оперативното ръководство за работа, защото осигуряването на достъп никога не е било трудната част. Каналът за данни за заплахи е просто чужда база данни. Нечии чужди процеси са я създали, чужда преценка я е оформила и лошият ден на някой друг се намира в нея в момента, чакайки вашата автоматизация да предприеме действия.

Ръководя екипа, който поддържа Dependabot в GitHub, който към 2026 г. следи над 30 милиона хранилища за уязвими и злонамерени зависимости. Тази година разширихме предупрежденията за злонамерени пакети от npm, където отбелязвахме зловреден софтуер от март, до осем съвкупности от пакети, чрез внедряване на данни от общността от хранилището за злонамерени пакети на OpenSSF. Сигналите за зловреден софтуер са брутален тест за внедряване на канали за данни. Не можете просто да отстраните уязвимостта чрез обновяване, както правите при обикновена уязвимост; изтръгвате злонамерения пакет и след това подменяте всички идентификационни данни, до които е имал достъп процесът по изграждане. А обемът никога не спира. За годината, приключваща през май 2026 г., каталогизирахме средно по 18 нови злонамерени npm пакета на ден.

Има пет урока, които оцеляха в производствена среда, и нито един от тях не се интересува дали обработвате доклади за злонамерен софтуер в пакети, OSV записи или показатели от ISAC. Ако данните от общността захранват вашата автоматизация, те се отнасят и за вас.

Винаги трябва първо да задаваме неудобния въпрос
Не как записите влизат във вашата система, а как излизат от нея. Източниците нагоре по веригата допускат грешки. Даден доклад попада на грешно име на пакет. Изследовател оттегля констатация. Масов импорт се обърква в 2 ч. сутринта. Тъй като това е въпрос на време, а не на вероятност, всеки обработен запись се нуждае от следа обратно до точната промяна в източника, която го е произвела, а импортите трябва да могат да се отменят на партиди, с едно действие, за броени минути.

Проследимостта на произхода принадлежи на един рафт с функционалните флагове и отмяната на промени: това е оперативен контрол, а не просто водене на документация. Когато се появи подозрителен запись, всичко зависи от това дали можете да го проследите до точната външна промяна, която го е внесла. „Отмени всичко, дошло от тази промяна“ е бърза корекция. „Търси в базата данни и се надявай“ е рецепта за лоша седмица.

Ако вашата организация както допринася за, така и консумира данни от общността, рано или късно вашите собствени констатации ще се върнат при вас с чужд времеви отпечатък. Общностните хранилища агрегират доклади от много сътрудници, а агрегирането премахва контекста за това кой какво е открил пръв. Ако обработвате данните наивно, създавате ехо камера, в която вашият собствен доклад влиза отново в системата, маскиран като независимо потвърждение, или се сблъсква с оригинала и задейства дублиращ сигнал за същия пакет.

Решението е скучно. Поставяйте цифрови отпечатъци на това, което предоставяте, проверявайте всеки входящ запись спрямо тези отпечатъци и отхвърляйте собствените си ехота още на вратата. Преди да третира даден запись като потвърждение, потребителят трябва да може да отговори на един въпрос: това от нас ли започна? Екип, който не може да отговори на това, измерва собствения си глас и го нарича консенсус.

Нормализацията е това, за което отива бюджетът

Данните за заплахите са атрактивната част. Реалната работа е свързана с това, че различните среди за разработка не са съгласни за нищо. Един регистър третира имената на пакетите с разлика между главни и малки букви, докато съседният не го прави. Засегнатите версии пристигат като точни стойности в един формат и като отворени диапазони в друг, с гранична семантика, която се различава точно толкова, колкото да навреди. Речниците за степен на сериозност отказват да се уеднаквят. И нищо от това не се проваля шумно. Един грешно картографиран диапазон от версии или известява хиляди хора, които никога не са били засегнати, или мълчи за тези, които са били засегнати — и двата провала изглеждат как работеща система отвътре.

Така че предвидете бюджет за това. Слоят за картографиране и валидация изразходва повечето от нашите инженерни разходи и носи почти целия риск за коректност. Ако вашата оценка за интеграция включва предимно транспорт и съхранение, оценката е погрешна.

Автоматизацията се нуждае от радиус на поражение, а не от проверяващ

При десетки записи на ден в осем среди за разработка, прегледът на всеки запись от човек е просто театър. Той не може да се мащабира, а преструването, че може, просто прехвърля умората от вашите потребители към вътрешна опашка, която тихомълком се натрупва. Нашите предупреждения за злонамерен софтуер се публикуват автоматично. Никой не ги чете едно по едно. Това е дизайнерско решение и аз ще го защитя.

Това, което го прави защитимо, е инженерното проектиране, а не доверието. Ограничение регулира колко предупреждения може да създаде едно стартиране на импорт, така че повредена партида от източника да не може да залее със сигнали, преди човек да забележи. Всяка партида се отменя като една единица. Аномалиите в обема и формата се отбелязват спрямо това как изглежда един обикновен день. Правилният въпрос за всяка автоматизирана система за обработка не е кой одобрява всеки запись. Той е: каква е най-голямата грешка, която тази система може да направи, преди човек да я забележи, и колко бързо можем да я отменим?

Проваляйте се шумно, никога не поправяйте тихомълком

Най-изкушаващото решение при приемане на канали за данни е тихата корекция. Външен запись изпраща неправилно форматиран диапазон от версии, вашият парсер би могъл да предположи намерението и предположението най-вероятно би било правилно. Ре...