Понимание структуры кибербезопасности SLSA

Как SLSA помогает защититься от атак на цепочку поставок программного обеспечения

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

Вредоносные атаки на репозиторий коммитов PHP

В марте 2021 года Никита Попов объявил, что злоумышленники попытались атаковать исходный код PHP, создав бэкдор, который позволил бы им получить несанкционированный доступ к платформе кода. В случае успеха атака была бы разрушительной, поскольку на PHP работает около 80% веб-сайтов в Интернете. К счастью, атака была обнаружена вовремя, но этот инцидент по-прежнему показывает, как средства контроля SLSA могут помочь предотвратить подобные атаки в будущем. Следование протоколам SLSA, таким как проверка двумя людьми и двухфакторная аутентификация, защитило бы платформу исходного кода и сделало бы ее гораздо более сложной целью для злоумышленников.

Вредоносное нарушение компилятора Apple

В 2015 году разработчики программного обеспечения, создающие приложения для продуктов Apple, загрузили версию Xcode (инструмент написания кода для устройств Apple) с непроверенной хостинговой платформы. Версия Xcode, известная как XcodeGhost, была заражена вредоносным кодом, который был скрытно перенесен в приложения, созданные с его помощью. Он создал бэкдор для нескольких приложений, которые обходили процесс проверки кода Apple и приложения, предлагаемые в магазине приложений. Платформа SLSA содержит протоколы безопасности, связанные со сборкой, которые могли бы предотвратить подобную атаку или усложнить ее. Одной из таких мер является требование герметичности сборки, которое заставило бы разработчиков декларировать все свои источники, включая используемый ими встроенный инструмент.

Загруженные вредоносные артефакты

1 апреля 2021 года команда Codecov обнаружила атаки, затронувшие ее загрузчики Bash, в том числе Codecov GitHub Action, The Codecov CircleCI Orb и Codecov Bitrise Step. Злоумышленник получил несанкционированный доступ, извлекая ключ HMAC, который обеспечивал доступ к учетной записи службы Google Cloud Storage промежуточного уровня одного из общедоступных образов Docker, размещенных на собственном хостинге Codecov. Этот ключ позволил им модифицировать Bash Uploader для загрузки вредоносных кодов непосредственно конечным пользователям. Платформа SLSA уловила бы это действие, показав, когда артефакты создаются способом, отличным от ожидаемой формы в их исходном репозитории.

Плохая зависимость потока событий

В 2018 году хакеры опубликовали в npm вредоносный пакет Flatmap-stream, который позже был добавлен в качестве зависимости к широко используемому пакету event-stream платформы. После добавления зависимости злоумышленники обновили ее вредоносным поведением. Поскольку обновление не соответствовало коду, отправленному на GitHub, платформа SLSA поймала атаку и предотвратила ее вектор. Отслеживание происхождения вредоносного кода показало бы, что он исходил не с GitHub или от надлежащего разработчика. В любом случае нападение можно было предотвратить.

Четыре уровня безопасности структуры кибербезопасности SLSA

Структура SLSA — это поэтапный и действенный протокол. Он состоит из четырех уровней, причем уровень 4 представляет собой идеальное конечное состояние защищенной системы. Артефакты на самом высоком уровне отвечают всем требованиям, позволяющим завоевать уверенность потребителя в том, что они не были каким-либо образом подделаны и что все их компоненты можно отследить до их источника. Артефакты на более низких уровнях — это те, которые также достигли дополнительных этапов с конкретными гарантиями целостности в зависимости от их ранга.

Уровень 1 — закладка фундамента

Вы можете рассматривать уровень 1 структуры SLSA как своего рода основу для всей структуры для создания безопасного программного обеспечения. На этом этапе разработчики или организации, принимающие SLSA, должны сделать две вещи. Во-первых, им необходимо полностью автоматизировать процесс сборки. Это можно сделать разными способами, но традиционный способ автоматизации сборки — использование make-файла. Действия GitHub также можно использовать для достижения тех же результатов.

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

Создание сценария процесса сборки и демонстрация происхождения программного артефакта таким образом облегчает потребителям принятие обоснованных решений об использовании программного продукта. Хотя проверка SLSA 1 не означает, что программное обеспечение полностью защищено от несанкционированного доступа, она упрощает идентификацию компонентов программного обеспечения. Это первый этап управления уязвимостями.

Уровень 2. Убедитесь, что ваш процесс сборки защищен от несанкционированного доступа.

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

Опять же, это делается в два этапа: первый — с использованием контроля версий, а второй — с использованием размещенной службы сборки для проверки подлинности происхождения. На первом этапе используется GitHub, GitLab или любой другой подобный сервис для хранения кода и записи любых внесенных в него изменений. Отслеживание любых изменений версии таким образом упрощает понимание любых изменений, внесенных в артефакт в процессе его создания.

Хотя для уровня 2 требуется документация о происхождении, как и для уровня 1, разница здесь в том, что программный артефакт должен быть аутентифицирован размещенной службой сборки. Размещенная служба выступает в качестве доверенной третьей стороны, которая может подтвердить точность процесса сборки, подробно описанного в исходном документе о происхождении. GitHub Actions — это тип службы хостинга, который может обеспечить проверку подлинности происхождения.

 Уровень 3 – меры безопасности SLSA.

На уровне 3 вы начинаете реализовывать конкретные меры безопасности, как указано в структуре SLSA. Чтобы достичь этого уровня, платформы исходного кода и сборки для ваших программных артефактов должны соответствовать определенным стандартам, которые гарантируют, что источник доступен для аудита и можно доверять происхождению кода. Уровень SLSA 3 обеспечивает гораздо более надежную гарантию того, что артефакт хорошо защищен от несанкционированного доступа и определенных классов угроз.

Некоторые из конкретных требований уровня 3 включают в себя:

•     История и хранение проверенного исходного кода—История проверки исходного кода гарантирует, что любое изменение, внесенное в исходный код программного обеспечения, сопровождается подтвержденной личностью автора, рецензента или загрузчика, который внес изменение, с указанием конкретных временных меток изменения. Эта история изменений также должна храниться не менее 18 месяцев.
•   Изолированные сборки в эфемерных средах— Чтобы выполнить это требование, сборки программного обеспечения должны быть реализованы в эфемерных средах, где они полностью независимы от любых других экземпляров сборок. Для достижения этой цели вы можете использовать такой сервис, как GitHub Actions, который использует виртуальную машину сборки для создания сборки по требованию.
•     Создается как код—Эти критерии требуют, чтобы вы относились к файлам сборки как к коду. Это означает, что они должны храниться в системе контроля версий, которая позволяет при необходимости воссоздавать процессы сборки.
•     Нефальсифицируемое происхождение—Цель этого требования — предотвратить вмешательство пользователей в документацию о происхождении, созданную службой сборки.

Уровень 4 — Доверие потребителей.

Уровень 4 структуры SLSA предназначен для обеспечения того, чтобы программное обеспечение не было каким-либо образом подделано. Только программные артефакты, отвечающие следующим требованиям, могут достичь уровня 4 структуры:

Проверка всех изменений двумя людьми

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

Герметичный и воспроизводимый процесс сборки

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

Технические требования для соответствия уровням SLSA

Структура SLSA имеет определенные технические требования для разных уровней. Эти требования разделены на пять основных категорий: требования к исходному коду, требования к процессу сборки, общие требования, требования к содержимому источника и требования к созданию источника. Каждая из этих категорий требований выделена ниже.

Исходные требования

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

Требования к сборке

Структура SLSA выделяет требования к сборке, призванные повысить безопасность платформы сборки и поддерживать целостность процесса сборки.

Требования к генерации происхождения

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

Требования к содержанию контента

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

Общие требования

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