Разработчики Google представили "СЛСА" (Уровни цепочки поставок для программных артефактов), цель которого - заботиться о защита инфраструктуры развития атак, осуществленных на этапах кодирования, тестирования, сборки и распространения продукта.
Разработчики упомянуть, что процессы разработки становятся все более сложными и зависят от сторонних инструментов, что создает благоприятные условия для продвижения атак, связанных не с выявлением и использованием уязвимостей в конечном продукте, а с вовлечением самого процесса разработки.
О SLSA
Упоминается, что SLSA фокусируется на следующих двух фундаментальных принципах:
Не односторонний - Ни одно лицо не может изменять программный артефакт где-либо в цепочке поставок программного обеспечения без явной проверки и одобрения хотя бы одним другим «доверенным лицом». [^ 1] Цель - предотвращение, сдерживание или раннее обнаружение рисков / плохих изменений.
Возможность аудита - программный артефакт можно безопасно и прозрачно проследить до исходных, удобочитаемых источников и зависимостей. Основная цель - автоматический анализ источников и зависимостей, а также специальные расследования.
Чтобы заблокировать помеченные угрозы, SLSA предлагает набор руководств и инструментов для автоматизации создания метаданных для аудита.. SLSA обобщает общие методы атак и вводит понятие уровней защиты.
Каждый уровень имеет определенные требования к инфраструктуре для обеспечения целостности артефактов, используемых при разработке, т. Е. чем выше поддерживаемый уровень SLSA, тем больше защит будет реализовано и инфраструктура будет лучше защищена от типичных атак.
SLSA уровня 1
На этом уровне требует, чтобы процесс сборки был полностью автоматизирован и генерировал метаданные («Происхождение») о том, как собираются артефакты, включая информацию об источнике, зависимостях и процессе сборки (для действий GitHub предоставляется образец генератора метаданных для аудита). SLSA 1 не включает элементы защиты от вредоносных изменений.Он только определяет код самым простым способом и предоставляет метаданные для управления уязвимостями и анализа рисков.
SLSA уровня 2
Здесь первый уровень расширен, требуя использования системы управления версиями и создания сервисов, которые генерируют аутентифицированные метаданные. Использование SLSA 2 позволяет отслеживать происхождение кода и предотвращает несанкционированные изменения в вашем коде, в случае использования надежных сервисов сборки.
SLSA уровня 3
С этого моментаили подтверждается, что исходный код и платформа сборки соответствуют требованиям стандартов для обеспечения возможности аудита кода и гарантии целостности предоставленных метаданных. Аудиторы должны иметь возможность сертифицировать платформы на соответствие требованиям стандартов.
SLSA уровня 4
Это самый высокий уровень, и он также дополняет предыдущие уровни, добавляя гораздо более строгие требования, среди которых обязательная проверка всех изменений двумя разными разработчиками, а также всех этапов компиляции, кода и зависимостей. Они должны быть полностью объявлен, все зависимости должны быть проверены и проверены отдельно, а процесс сборки должен выполняться в автономном режиме.
Использование повторяемого процесса компиляции также дает возможность повторить процесс компиляции и гарантировать, что исполняемый файл скомпилирован из предоставленных источников.
В дополнение к этому данный фреймворк учитывает 8 типов атак связанные с угрозами злонамеренных изменений на этапе разработки, компиляции, тестирования и распространения кода продукта.
Учитываемые типы атак Они заключаются в следующем:
1.- Включение в исходный код изменений, содержащих бэкдоры или скрытые ошибки, ведущие к уязвимостям.
2.- Обязательства платформы управления версиями.
3.- Внести изменения на этапе переноса кода в систему компиляции или непрерывной интеграции (собирается код, не соответствующий коду репозитория).
4.- Обязательство строительной платформы
5.- Продвижение вредоносного кода через некачественные зависимости.
6.- Загрузка артефактов, не созданных в системе CI / CD.
7.- Взлом репозитория пакетов.
8.- Замешательство пользователя при установке неправильного пакета.
В конце концов если вы хотите узнать об этом больше, вы можете проверить подробности По следующей ссылке.