Что вам нужно сделать, чтобы достичь уровней SLSA – очень практическое руководство

проверка данных

SLSA (Уровни цепочки поставок для программных артефактов) — это структура безопасности, целью которой является предотвращение несанкционированного доступа, повышение целостности и защита пакетов и инфраструктуры. Основная концепция SLSA заключается в том, что программному артефакту можно доверять только в том случае, если он соответствует трем требованиям:

1. Артефакт должен иметь документ происхождения, описывающий его происхождение и процесс создания (L1).
2. Документ о происхождении должен быть заслуживающим доверия и проверенным в дальнейшем (L2).
3. Система сборки должна быть надежной (L3).

Структура SLSA определяет уровни, которые показывают, насколько безопасна цепочка поставок программного обеспечения. Эти уровни соответствуют уровню реализации этих требований (отмечено выше как L1-L3).

Писец valint slsa Команда может использоваться для создания документов Provenance. Ниже мы опишем, как достичь уровней SLSA с помощью этого инструмента.

Примечание. Здесь мы имеем в виду платформу SLSA V1.0.

СЛСА Л1

Команда большого города, для SLSA L1 включают:

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

Контрольный список для достижения SLSA L1:

• Создайте свое программное обеспечение, используя систему CI. Предпочтительно использовать сценарий сборки с контролем исходного кода.
• Активировать valint slsa как часть сценария сборки для создания документа Provenance. Обратите внимание, что valint slsa  Команда позволяет добавить дополнительную информацию в документ Provenance — вы можете адаптировать содержимое документа Provenance под свои нужды.

СЛСА Л2

Команда большого города, для SLSA L2 включают:

• Требования SLSA L1.
• Сборка выполняется на размещенной платформе сборки, которая сама генерирует и подписывает происхождение.
• Последующая проверка происхождения включает в себя проверку подлинности происхождения.

Контрольный список для достижения SLSA L2:

• Контрольный список SLSA L1.
• Используйте размещенную службу сборки (в отличие от выполнения сборки на компьютере разработчика).
• Создайте подписанный документ Provenance (вместо неподписанного, которого достаточно для SLSA L1). Этого можно добиться, запустив valint slsa ... -o attest. Писец валинт инструмент имеет широкий набор возможностей подписи; для предприятий мы рекомендуем использовать ключи и сертификаты X.509 PKI. 
• Проверьте подлинность последующего документа о провенансе, используя valint verifyкоманда. Проверка может включать в себя подпись и подписавшее удостоверение, а также другие правила проверки, гарантирующие содержание документа SLSA Provenance. Некоторые примеры можно найти в Scribe's. каталог политик.

Примечание. Проверка должна осуществляться потребителем встроенного программного обеспечения; для внутреннего соответствия проверка может выполняться в рамках конвейера тестирования.

СЛСА Л3

Требования SLSA L3

Команда большого города, для SLSA L3 включают:

• Требования SLSA L2.
• Платформа сборки реализует строгий контроль для:
  • Не допускайте влияния запусков друг на друга, даже в рамках одного проекта.
  • Запретите доступ к секретам, используемым для подписи происхождения, на определяемых пользователем этапах сборки.

Кроме того, чтобы доверять платформе сборки, необходимо проверьте платформу сборки. Платформе сборки следует доверять в том смысле, что документ Provenance будет не поддающийся подделке и сборка будет изолированный. Такая проверка вытекает из следующих требований:

• Подтвердите это использование платформы не нарушает невозможность подделки и изоляция запросам наших потенциальных клиентов.
  • Например, проверку изоляции можно выполнить путем оценки использования кэша в конвейере.
  • Чтобы гарантировать невозможность подделки документа Provenance, мы рекомендуем создать и подписать его в специальном конвейере сборки.
• Проверить надежность платформы сборки.
  •  Для CI SaaS необходимо провести проверку у поставщика платформы сборки. В тех случаях, когда за развертывание системы сборки отвечает производитель программного обеспечения, рекомендуется сочетание самоаттестации поставщика и анализа аспектов развертывания.
  • Например, при развертывании локального CI аттестация поставщика должна указывать, как сборки изолированы друг от друга, а анализ развертывания должен проверять права доступа и аудит журналов CI-системы.

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

Если вы дочитали эту статью до сюда и решили, что SLSA L3 — то, что вам нужно, засучите рукава — вот наша рекомендация по контрольному списку:

Контрольный список для достижения SLSA L3:

• Контрольный список SLSA L2.
• Оцените систему CI. Цель – ответить на следующие вопросы:
  • При каких условиях неавторизованный объект может обойти систему сборки?
  • При каких условиях сборки могут влиять друг на друга?

Получив ответ – управляйте оставшимися рисками.

• Изолируйте генерацию документа Provenance:
  • Выделите создание документа Provenance в другой конвейер, желательно в отдельный сервис сборки.
    • Предоставляйте этому конвейеру только секреты, используемые для подписи документа Provenance.
    • Либо создайте, либо проверьте содержимое документа Provenance в этом конвейере. В случае проверки проверьте все возможные поля документа Provenance, созданного в конвейере, с данными, собранными непосредственно с платформы сборки или из других надежных источников.
• Изолируйте и проверьте изоляцию конвейера сборки от других запусков конвейера:
  • Проверьте использование кэшей и общих томов.
  • Убедитесь, что секреты, используемые совместно с другими конвейерами, не позволяют конвейерам влиять друг на друга.
  • Убедитесь, что запуски конвейера не могут влиять друг на друга.
    • Например, не допускайте, чтобы установки, выполненные через один конвейер, влияли на другие участки конвейера. Это можно сделать с помощью эфемерных средств запуска сборки (например, контейнера, который создается для каждой сборки) или путем проверки того, что средства запуска сборки каждый раз запускаются из заранее определенного состояния.

Чтобы достичь SLSA L3 с помощью инструментов Scribe, мы рекомендуем следующее:

• Инструментируйте конвейер сборки для создания всех аттестаций, которые потребуются для заполнения документа Provenance. Например, вы можете решить, что вам нужен список зависимостей, установленных во время сборки. Этот список может быть создан с помощью valint bom dir:команда. Кроме того, создайте аттестацию Provenance в конвейере, используя valint slsa команда.
• Создайте отдельный конвейер генерации доверенного происхождения, который будет выполнять следующие действия:
  • Создайте доверенный документ Provenance на основе документа, созданного в конвейере сборки;
    • Соберите данные из службы сборки и используйте их для проверки и обновления документа Provenance.
    • Проверьте содержимое аттестаций, созданных в конвейере сборки. Например, проверьте содержимое средства сборки, сравнив аттестацию SBOM из конвейера сборки с аттестацией SBOM, выбранной отдельно.
    • Используйте подтверждения, полученные из конвейера сборки, для обновления документа Provenance.
    • Обновление документа происхождения можно выполнить с помощью valint slsa команда.
  • Убедитесь, что сборка была изолирована, оценив данные, собранные из службы сборки. Например – проверить использование тайников и секретов.

Для сбора и оценки таких данных Scribe предоставляет инструменты, которые создают аттестации для запуска сборки и выполняют необходимые проверки.

---

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

Статьи по теме

Отравление кэша GitHub

Знаете ли вы, что происходит под капотом вашего CI? Без глубокого понимания вы можете быть уязвимы для инновационных атак на цепочки поставок. В этой статье описывается такая атака.

Непрерывное обеспечение: неотъемлемая практика обеспечения безопасности цепочки поставок программного обеспечения

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

От хаоса к ясности: как защитить цепочку поставок с помощью аттестаций

Поскольку все становятся все более осведомленными, защита цепочек поставок программного обеспечения должна стать жизненно важной частью стратегии кибербезопасности каждой организации. Одной из основных трудностей в создании комплексной стратегии по снижению угроз в цепочках поставок программного обеспечения является сложность и разнообразие цепочек поставок. Каждая цепочка поставок уникальна, и ее элементы […]