Суть. Современное приложение на девяносто процентов состоит из сторонних библиотек. Атака через компонент дешевле, чем атака на само приложение, поэтому предметом защиты становится вся цепочка: откуда взялся код, кто его собрал, что вошло в итоговую сборку и можно ли это проверить.
Из чего состоит
| Элемент | Что даёт | Вопрос заказчика |
|---|---|---|
| Опись состава | Полный список компонентов и их версий | «Есть ли у вас уязвимая библиотека X?» |
| Проверка уязвимостей | Известные проблемы в используемых версиях | «Как быстро вы узнаёте о новой уязвимости?» |
| Лицензионная чистота | Совместимость лицензий открытого кода | Обязательный пункт проверки перед крупной сделкой |
| Подпись сборки | Доказательство, что артефакт собран именно вами | «Как мы убедимся, что это ваш дистрибутив?» |
| Защита конвейера | Кто может изменить процесс сборки | Часто самое слабое место |
Почему это стало коммерческим вопросом
Опись состава компонентов перешла из технической практики в требование закупки: её запрашивают крупные заказчики и регулируемые отрасли. Поставщик, у которого она готова, проходит проверку за недели; тот, у кого её нет, собирает список вручную под давлением сроков.
Из чего состоит риск
| Источник | Что может произойти | Что помогает |
|---|---|---|
| Внешние библиотеки | Уязвимость или вредоносный код в зависимости | Перечень компонентов, проверка версий |
| Сборка | Подмена на этапе сборки | Изолированная среда, воспроизводимость |
| Артефакты | Подмена готового пакета | Подписи и проверка при установке |
| Учётные записи | Компрометация доступа к репозиторию | Двухфакторная защита, ограничение прав |
| Поставщики | Уязвимость в чужом продукте внутри вашего | Требования к поставщикам, порядок реагирования |
Практический минимум
- Ведите перечень компонентов: что именно входит в ваш продукт и каких версий. Без него невозможно ответить на вопрос «затронуты ли мы» при очередной уязвимости.
- Автоматически проверяйте зависимости при сборке и не пропускайте сборку с критичными находками.
- Фиксируйте версии зависимостей. Плавающие версии означают, что состав продукта меняется без вашего решения.
- Подписывайте артефакты и проверяйте подписи при установке.
- Заведите порядок быстрого ответа: кто и за сколько часов проверяет, затронут ли продукт.
Где ломается
Опись формируют вручную раз в год. К моменту поставки она устарела. Формируется автоматически при каждой сборке.
Проверяют библиотеки, не проверяют конвейер. Доступ к системе сборки часто шире, чем к рабочей среде.
Находят уязвимости и не обновляют. Отчёт растёт, риск не снижается; нужен процесс обновления с приоритетом по реальной эксплуатируемости.
Перечня компонентов нет. При громкой уязвимости компания тратит дни на то, чтобы понять, касается ли это её.
Проверки есть, находки игнорируют. Список предупреждений растёт, все привыкают, реальная проблема теряется среди шума.
Права на публикацию у многих. Одна скомпрометированная учётная запись позволяет выпустить подменённую версию.
Самый практичный вопрос: за сколько часов вы сможете ответить заказчику, содержит ли ваш продукт уязвимую версию конкретной библиотеки. Ответ «за дни» — это и есть размер проблемы.
Частые вопросы
Связанное
Основной риск здесь не в вашем коде, а в том, что вы принесли внутрь него. Управление начинается с честного перечня.