Composer update вече не е рутина: как PHP екипите да се пазят от supply chain атаки

Допреди няколко месеца обновяването на библиотеките и пакетите, на които стъпва един PHP проекта беше почти механично действие. Избираш ден, пускаш composer update и npm update, минават тестовете, commit-ваш и продължаваш.

Днес това вече не е толкова спокойно. Една на пръв поглед нормална версия може да донесе зловреден код, да източи токени от CI/CD средата, да стигне до production и да повлече целия ефект. Поредната такава случка ме накара да пусна този текст, който отлежава вече няколко месеца. За справка, тръгнах да го пиша през май, когато бяха компрометирани няколко пакета от семейството laravel-lang/*. При него стотици исторически версии бяха пренасочени към зловреден код чрез пренаписване на git tag-ове. За PHP екипите това е важен сигнал: composer.lock помага, но сам по себе си вече не е достатъчна защита.

И тази сутрин се събудих от поредната новина по темата, този път от платен WordPress плъгин, който ползвахме някога – Monsterinsights (тракинг на потребителско поведение). Накратко, посредством supply-chain атака, продукционен сървър на компанията е  станал инструмент в друга supply-chain атака, засягаща клиентите ѝ. Цитирам: „Подправена версия на плъгина беше разпространена […], а нападателите използваха имейл адресите на клиентите, [които откраднаха от базите ни], за да изпращат фишинг имейли, призоваващи хората да „актуализират“ до тази злонамерена версия.“ Чиста работа.

Проблемът не е update-ът. Проблемът е сляпото доверие

Да сме наясно, редовното обновяване продължава да е номер едно security tip. Остарелите зависимости носят уязвимости, които са „световно известни“, доста често – и вече експлоатирани. Рискът идва от другата страна: прекалено бързото приемане на нови версии, без проверка кой ги е публикувал, кога са излезли и какво изпълняват при инсталация.

За един PHP (а и не само PHP) разработчик (vibe или не) това е особено практична тема. Много Laravel, WordPress и custom PHP проекти се поддържат от малки екипи, които работят бързо, често с автоматизиран deployment и достъп до чувствителни среди. Един компрометиран пакет може да засегне не само сайта, а и ключове, бази данни, cloud акаунти и клиентски данни.

Започнете с актуален package manager

Парадоксално, първата добра стъпка е да се обновят самите инструменти. Composer 2.10 добавя malware policy, която блокира версии, маркирани като зловредни. npm вече има min-release-age настройка, с която нова версия може да “отлежи” няколко дни преди да бъде инсталирана.

min-release-age=3

Тази пауза дава време на security общността да засече и свали злонамерени release-и, преди те да стигнат до проекта.

Освен това, при composer update:

• Проверявайте името на пакета — typosquatting атаки често разчитат на една объркана буква.
• Дръжте composer.lock в git и преглеждайте всяка промяна в него.
• Пускайте audit в CI, а не само ръчно от време на време.
• Използвайте --no-scripts и --no-plugins, когато сваляте код само за преглед.
• Избягвайте global require и root изпълнение, защото така компрометираният пакет получава много по-широк достъп.

Най-важният въпрос

В крайна сметка защитата от supply chain атаки започва преди командата ред. Въпросът е прост: наистина ли ни трябва този пакет?

Понякога 50 реда собствен код са по-лесни за преглед от още една зависимост с хиляди редове, scripts, plugins и непозната история. Update-ите остават задължителни, но вече заслужават същото внимание, което даваме на production промяна.

В този ред на мисли, дори когато използвате Claude или друг агент за програмиране, задължително винаги проверявайте каква библиотека ви предлага. Може да ви спести доста главоболия.