Ресурсы · 16
Обеспечение надежности цепочки поставок программного обеспечения: компоненты для выпуска
Связывание компонентов, происхождения, сборок, уязвимостей и обновлений с каждым фактически развернутым релизом.
Обновлено · 2 min
Чего помогает достичь это руководство
- Знайте, какие зависимости фактически поставляются.
- Проверьте происхождение артефакта.
- Приоритизируйте недостатки в контексте.
- Протестируйте замену и откат.
Быстрая проверка
- Соответствует ли спецификация компонентов развернутой версии?
- Включены ли транзитивные зависимости?
- Кто может подписать релиз?
- Доступна ли уязвимость при вашем использовании?
- Можно ли удалить критически важный компонент без импровизации?
Пошаговый метод
- 1
Сопоставьте поставляемые релизы.
Идентифицируйте репозитории, прямые и транзитивные зависимости, инструменты сборки, образы, внешние сервисы и владельцев. Свяжите все это с проверяемым релизом.
Результат: карта продукта, компонента, версии и владельца.
- 2
Создание пригодной для использования спецификации материалов
Создание спецификации материалов для каждого релиза и сравнение ее с фактически выпущенными артефактами. Устранение неточных имен, отсутствующих версий и внутренних компонентов.
Результат: датированная и проверенная спецификация материалов.
- 3
Защита сборки
Ограничение прав публикации, изоляция конфиденциальных этапов и сохранение происхождения, дайджестов и подписей. Проверка этих данных перед развертыванием.
Результат: запись сборки и политика проверки.
- 4
Обработка оповещений
Привязка каждого уведомления об уязвимости к компоненту, версии, степени воздействия и фактическому использованию. Назначение ответственного, крайнего срока, решения и подтверждения закрытия.
Результат: контекстная очередь обработки.
- 5
Репетиция изменений
Замена критического компонента в тестовой среде, проверка бизнес-процессов и репетиция отката. Измерение зависимостей, блокирующих изменение.
Результат: отчет об учениях по замене и резервированию.
- 6
Сохранение доказательств
Анализ компонентов и поставщиков при крупных выпусках и после инцидентов. Сохранение записей в течение периода, необходимого для проведения расследования и устранения неполадок.
Результат: анализ календаря и истории выпусков.
Показатели управления
| Показатель | Что он измеряет | Первое действие |
|---|---|---|
| Покрытие SBOM | Выпущенные релизы с проверенным инвентарем компонентов | Устранение несоответствий перед публикацией |
| Проверка происхождения | Проверка артефактов перед развертыванием | Блокировка релизов, в которых отсутствуют ожидаемые доказательства |
| Время сортировки | Время от соответствующего уведомления до документированного решения | Эскалация уязвимых компонентов |
| Обратимость | Критические замены протестированы с откатом | Удаление блокирующих зависимостей |
Распространенные ошибки
- Путаница между инвентарем репозитория и развернутыми компонентами
- Сохранение SBOM без его обновления
- Оценка уязвимости только по баллам
- Подписание артефакта без проверки происхождения сборки
Часто задаваемые вопросы
Достаточно ли SBOM?
Нет. Он помогает идентифицировать компоненты, но происхождение, целостность, уязвимость и возможность обновления также нуждаются в проверке.
Должна ли каждая уязвимость блокировать выпуск?
Принимайте решения, исходя из фактического использования, степени уязвимости, компенсирующих мер контроля и критичности для бизнеса, и документируйте обоснование.
Какая эталонная структура помогает?
Структура безопасной разработки программного обеспечения NIST предлагает методы безопасной разработки и защиты программного обеспечения на протяжении всего жизненного цикла.
Официальные ссылки
Ссылки подтверждают метод. Адаптируйте проверки к вашему контексту; они не являются сертификацией. Оригинальные названия ссылок и исходные документы могут быть на другом языке.
