Проверьте, что входит в релиз

Выясните, нужна ли зависимость

Агент может предложить пакет, который, по-видимому, решает задачу. Такое предложение не подтверждает, что пакет существует или подходит. До установки проверьте точный реестр, издателя, название пакета и версию.

В вымышленном примере экспорта CSV среда выполнения может уже предоставлять нужное поведение. Новый пакет всё ещё может быть оправдан, но он добавляет работу по сопровождению и новые пути выполнения. Сравните трудозатраты на реализацию с постоянными обязанностями по сопровождению зависимости.

Проверьте лицензию и поддерживаемую среду выполнения. Изучите активность сопровождения и соответствующие сообщения об уязвимостях. Знакомое название может обозначать другой пакет в другом реестре. Успешная установка подтверждает только завершение установки.

Изучите поведение при установке и сборке

Зависимости могут выполнять код во время установки или сборки. Ограничьте учётные данные и сетевой доступ в этих средах. Не передавайте секреты production заданию, которое обрабатывает недоверенный pull request.

Используйте сохранённый в репозитории lockfile, если экосистема его поддерживает. Требуйте, чтобы сборка строго следовала данным, зафиксированным в этом файле. Проверяйте его изменения вместе с изменением исходного кода, включая неожиданные транзитивные пакеты. Фиксация версий улучшает воспроизводимость, но не делает уязвимую версию безопасной.

SSDF от NIST охватывает защиту программ и практики разработки на всём жизненном цикле. Учитывайте этот более широкий подход при проектировании среды сборки. Описание SSDF.

Отличайте состав программы от её происхождения

Перечень компонентов программы, или SBOM, фиксирует компоненты, входящие в программу. Он помогает найти затронутые релизы, если с компонентом возникает проблема. Сам по себе он не подтверждает безопасность компонентов.

Сведения о происхождении, или provenance, описывают, как был создан артефакт. SLSA определяет формат этих сведений о сборке и её входных данных. Проверка должна связать их с доверенным создателем и артефактом, который вы собираетесь использовать. Файла с названием «provenance» недостаточно. Provenance в SLSA.

Для сервиса экспорта зафиксируйте цепочку, которую можно проверить:

1. Проверенный commit определяет принятый исходный код.
2. Сборка указывает свои входные данные и среду выполнения.
3. У артефакта есть стабильный digest.
4. Проверки указывают, какой артефакт или исходный код они исследовали.
5. Запись о развёртывании указывает артефакт, помещённый в целевую среду.

Не пересобирайте программу другим способом после согласования без определённого процесса проверки. Изменяемый тег, например latest, позднее может указывать на другой образ.

Определите значение найденной проблемы

Для оценки уязвимости нужен контекст: затронутая версия, возможность выполнения уязвимого кода, доступность для атаки, имеющееся исправление и последствия. Запишите основания для любого временного исключения. Назначьте владельца, срок действия и условие пересмотра.

Не отключайте весь сканер из-за одной неприменимой находки. Не заявляйте об отсутствии проблем, если сканирование не завершилось. Тайм-аут, неподдерживаемый пакет или недоступная лента сообщений об уязвимостях означают отсутствие свидетельств.

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

Перейдите к уроку о постоянном управлении уязвимостями, чтобы связать повторные сканирования с проверенными исправлениями в production.