Цели 17-го процесса ГОСТ Р 56939-2024:
Создание условий для снижения рисков внедрения вредоносного ПО посредством воздействий на ПО или механизмы его доставки до получения ПО конечными пользователями и недопущение компрометации данных (информации) или информационной системы, использующей такое ПО.
Для этого требуется (п.5.17.2.1):
Осуществлять контроль зависящих от сторонних поставщиков элементов разработки (процессов; компонентов инфраструктуры разработки ПО, зависящих от сторонних поставщиков; компонентов, являющихся частью разрабатываемого ПО, которые поставляются или заимствуются от сторонних поставщиков).
А иначе "Красивая иконка оказалась приманкой. Разработчик Ethereum потерял всё за один клик". Причём есть прогноз, что подобный обходной путь атаки будет набирать популярность.
Здесь SCA (см. процесс 16) не помощник, кроме случаев, когда поставка представляет собой открытый код, которым пользуется большое количество других разработчиков. Поэтому необходимо полагаться на собственные силы по анализу качества, надёжности и безопасности внешних компонентов.
Думаю, могут быть уместны всё те же меры, которые описаны в стандарте: статический и динамический анализ, функциональное тестирование и т.д.
Однако в 17-м процессе делается упор на договорные обязательства стороннего поставщика. Это логично. Если вы заказали качественное ПО, вы его и должны получить. Cм. артефакты в разделе 5.17.3. При это всегда помним: доверяй, но проверяй.
Из всех артефактов мне непонятен только п.5.17.3.5:
Результаты анализа кода ПО, полученного через цепочки поставок, на предмет внедрения вредоносного программного обеспечения должны содержать, как минимум, отчеты сканирования средств антивирусной защиты.
Если бы речь шла о поставке скомпилированных модулей/библиотек, то их проверка антивирусом мне понятна. Но я не понимаю, как связан антивирус и исходный код. Что надо им поверять? Возможно, формулировка неудачная, и буду рад, если кто-то пояснит в комментариях.
Ещё интересно, вот здесь про SBOM речь? П.5.17.3.3:
Сведения о критичных и вероятных с точки зрения внедрения недекларированных возможностей элементах инфраструктуры (компонентах инфраструктуры разработки ПО, зависящих от сторонних поставщиков) должны содержать следующую информацию:
- перечень элементов инфраструктуры разработчика, воздействие на которые может повлиять на возникновение недекларированных возможностей в ПО;
Дополнительные ссылки:
1. Атаки на цепочки поставок: как защитить своё программное обеспечение?
2. Open software supply chain attack reference (OSC&R).
3. AppSec Каталог - OSA.
4. Supply-Chain Фаервол.
5. Впервые цепочки поставок ПО были атакованы с использованием открытого кода (2023).
6. Ошибка в обработчике GitHub Actions привела к публикации вредоносных релизов Ultralytics.
7. Атака s1ngularity взломала 2180 GitHub-аккаунтов и раскрыла тысячи секретов.