Атака по веригата на доставки (supply chain): как доверен софтуер става вход за нападателите

Какво е атака по веригата на доставки, как заразени версии на библиотеки, плъгини и обновления стигат до фирмите, примерът с LiteLLM от октомври 2026 г. и мерките за фирми, които разработват или купуват софтуер.

OfSec 6 мин. четене

При атака по веригата на доставки (supply chain attack) нападателят не атакува фирмата пряко. Той компрометира доставчик, софтуерна библиотека, плъгин или процеса, по който се публикуват обновленията, и зловредният код пристига по доверен канал: като редовно обновление, инсталиран пакет или нова версия на плъгин. Защитната стена и антивирусната програма го пропускат, защото идва от източник, на който фирмата има основание да вярва.

Пример от тази седмица: LiteLLM 1.107.0

LiteLLM е популярна библиотека за Python с около 23 милиона изтегляния седмично. На 21 октомври 2026 г. в официалното хранилище PyPI и в Docker Hub се появи версия 1.107.0, съдържаща код за кражба на данни. Според доклада за инцидента на самия проект:

  • нападателят е използвал откраднати токени за GitHub на трима разработчици: с единия е премахнал защитата на процеса за публикуване, с втория е одобрил публикуването, а с третия е изтрил записите за изпълнението;
  • пакетите са изградени от хранилище с почти същото име (Berri-AI/litellm вместо BerriAI/litellm), затова официалният изходен код на версията е чист и прегледът му не би открил нищо;
  • зловредната версия е била достъпна в PyPI 1 час и 44 минути, а Docker образите, включително latest, 2 часа и 34 минути;
  • кодът се е записвал във файловете, които Python изпълнява при всяко стартиране, и е работил дори в програми, които изобщо не използват библиотеката.

Кодът е събирал ключове за облачни услуги, SSH ключове, данни за достъп до Git, Kubernetes и Docker, съхранени пароли от браузъра и историята на командите. Изследователите от Wiz съобщават, че около четири часа и половина по-късно откраднатите ключове за AWS вече са били използвани. Това е второто компрометиране на същата библиотека тази година: при първото, през март, засегнатите организации са близо 2500 според CloudSEK.

Прозорецът от по-малко от два часа е бил достатъчен, защото много системи инсталират „последната версия“ автоматично, без човек да я одобри.

Как стигат до фирмите заразени версии

Компрометиран профил на разработчик

Това е един от най-честите пътища. През септември 2025 г. поддържащ на популярни npm пакети, сред които chalk и debug, получи фишинг писмо за „смяна на двуфакторната защита“ и въведе данните си във фалшив сайт. Нападателите публикуваха версии с код, който подменя адреса на получателя при плащания с криптовалута в браузъра. Пакетите се изтеглят милиарди пъти седмично и бяха изтеглени от хранилището след около два часа. По подобен начин през юни 2024 г. в официалното хранилище на WordPress бяха открити няколко плъгина с вмъкнат код, който създава администраторски профили в сайтовете.

Компрометиран процес на изграждане и публикуване

При LiteLLM кодът на проекта е бил чист, а заразени са били само публикуваните пакети. Същото се случи през 2020 г. със SolarWinds: обновленията на системата за наблюдение Orion съдържаха вратичка, а около 18 000 клиенти ги инсталираха.

Злонамерен поддържащ

През март 2024 г. в библиотеката за компресия XZ Utils, която е част от повечето Linux дистрибуции, беше открита вратичка за отдалечен достъп чрез SSH във версии 5.6.0 и 5.6.1. Беше вмъкната от сътрудник, който в продължение на около две години беше спечелил доверието на поддържащия проекта. Откриха я случайно, преди да стигне до стабилните версии на големите дистрибуции.

Сменен собственик на външна услуга

Сайтовете често зареждат скриптове от чужди адреси. През 2024 г. услугата Polyfill.io смени собственика си, а скриптът ѝ, вграден в над 100 000 сайта, започна да пренасочва част от посетителите към измамни страници. Собствениците на сайтовете не бяха променили нищо.

Пакети с подобни имена

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

Мерки, ако разработвате или поръчвате софтуер

  1. Фиксирайте версиите. Използвайте lock файлове (package-lock.json, poetry.lock, uv.lock) и инсталирайте с npm ci или с проверка на хешовете (pip install --require-hashes). Задавайте Docker образите по digest, а не с етикети като latest.
  2. Не инсталирайте нови версии в деня на публикуването им. Повечето заразени версии се откриват и премахват до часове или дни. Настройки като minimumReleaseAge в pnpm, exclude-newer в uv и периодът на изчакване в Dependabot отлагат автоматичното обновяване.
  3. Пазете профилите и токените на разработчиците като ключове за производствената среда: многофакторна автентикация с физически ключ, кратко валидни токени, никакви токени в логовете.
  4. Ограничете правата в процеса на изграждане (CI/CD). Защитата на клоновете не трябва да може да бъде премахната от един профил, а публикуването изисква одобрение от друг човек. Машините за изграждане не трябва да пазят постоянни ключове за облачни услуги.
  5. Публикувайте с проверим произход: Trusted Publishing в PyPI и npm, подписани Docker образи. Проверявайте произхода и при пакетите, които използвате.
  6. Поддържайте списък на зависимостите (SBOM) и следете бюлетините за сигурност, например OSV и GitHub Advisory Database, за да знаете за часове, не за седмици, дали сте засегнати.

Мерки, ако купувате софтуер и услуги

  • Водете списък на доставчиците, които имат достъп до системите или данните ви: ИТ поддръжка, хостинг, разработчици, счетоводен софтуер. За фирмите в обхвата на Закона за киберсигурността сигурността на веригата на доставки е задължителна мярка по чл. 22, ал. 2, т. 4.
  • Включете в договорите изисквания за сигурност и задължение за уведомяване при инцидент, а след големи инциденти като този питайте доставчиците дали са засегнати.
  • В сайтовете използвайте само плъгини и теми от надеждни източници, премахвайте неизползваните и следете обновленията им. Подробности има в статията за хакнат сайт на WordPress.
  • Избягвайте скриптове, зареждани от чужди адреси. Когато са необходими, използвайте Content Security Policy и проверка на целостта (Subresource Integrity), за да не изпълнява браузърът променен файл.

Ако сте инсталирали заразена версия

Обновяването до чиста версия не е достатъчно, защото зловредният код може вече да се е закрепил в системата, както при LiteLLM, където остава във файловете за стартиране на Python.

  1. Изолирайте засегнатите машини и контейнери от мрежата.
  2. Изградете ги наново от чисти образи, вместо да ги почиствате.
  3. От друга, чиста машина сменете всички пароли и ключове, до които засегнатата машина е имала достъп: облачни услуги, бази данни, токени за GitHub и за публикуване на пакети, SSH ключове.
  4. Прегледайте логовете на облачните услуги за използване на ключовете от непознати адреси след момента на инсталирането.

Ако са изтекли лични данни, това е нарушение на сигурността на личните данни, което в повечето случаи трябва да бъде съобщено на КЗЛД до 72 часа.

Уеб приложенияДоставчици