Есть еще одна область, в которой нарушения безопасности могут принести такой же ущерб, как и взлом продакшена: это средства работы с исходным кодом и сборки ПО. При этом защищена она обычно хуже, что понятно: разработчики здесь вносят изменения и экспериментируют с кодом, а безопасность, при всей ее важности, может этому мешать.

Тем не менее у многих команд отсутствуют средства защиты, отделяющие среду для разработки и сборки от продакшена. Предпринимаются ли при этом какие-то меры, чтобы в код незаметно не оказалась добавлена вредоносная библиотека или фрагмент кода?

Если пайплайн сборки не защищен, кто-нибудь может внести в него небольшие изменения. Точно так же, если доступ к вашей системе контроля версий не ограничен надлежащим образом или вы используете небезопасный менеджер зависимостей (например, Maven или npm, где не фиксируется конкретная версия библиотек), то вы рискуете задеплоить код, не зная, что на самом деле у него внутри.

Так произошла печально известная атака на ПО SolarWinds, которая оказала огромное влияние на все отрасли, поскольку это программное обеспечение использовалось в крупных организациях как часть системы управления ИТ-инфраструктурой. Хакеры нашли идеального троянского коня: им не пришлось взламывать каждую цель, хватило одного сервиса, которым пользовались все. Затем вредоносный код распространялся как часть обычных обновлений ПО, проникая глубоко во внутренние сети и не вызывая срабатывания средств защиты.

Безопасный подход здесь – считать, что любая часть вашей системы является потенциальной мишенью, и создать как можно больше средств защиты, включая вынесение процесса сборки в отдельное окружение, фиксацию конкретных версий для всех сторонних библиотек (и их обновление только после проверки и подтверждения) и повышенное внимание к внезапным изменениям размеров файлов, которые не связаны с большими изменениями в коде (например, если собранное приложение стало занимать в два раза больше места, чем обычно, должен срабатывать алерт мониторинга).