Max Home IndustryОтвет Linux Foundation на атаки на цепочки поставок — это предложение бесплатной службы подписи кода для разработчиков с открытым исходным кодом под названием Sigstore. Находясь на правильном пути, он не снижает всех опасностей цепочки поставок. Правда в том, что полностью сделать это невозможно.
Чтобы создать полезное программное обеспечение, мы не изобретаем колесо, но мы основываемся на уже проделанной работе, которая поставляется в виде библиотек. Проблема в том, что даже посредственный проект с открытым исходным кодом может иметь множество таких зависимостей, которые сами зависят от других, формируя Сама по себе проблема не будет, если только вы не нацелены внедрить вредоносный код где-нибудь в этой цепочке. В конце концов, требуется всего одна команда:
npm install <модуль>
заразиться.
Насколько это просто, чудесно описано в статье «Я собираю номера кредитных карт и пароли с вашего сайта». Вот как.
Автор этой статьи описывает процесс:
К счастью для меня, мы живем в эпоху, когда люди устанавливают пакеты npm, как будто готовят обезболивающие.
Итак, npm должен был стать моим методом распространения. Мне нужно было бы придумать какой-нибудь погранично-полезный пакет, который люди установили бы, не задумываясь, — мой троянский конь.
Людям нравятся красивые цвета — это то, что отличает нас от собак, поэтому я написал пакет, который позволяет входить в консоль любым цветом.
Я был в восторге от этого момента — у меня был убедительный пакет — но я не хотел ждать, пока люди медленно его откроют и распространят информацию. Поэтому я начал делать PR для существующих пакетов, которые добавляли мой красочный пакет к своим зависимостям.
Я сделал несколько сотен PR (различные учетные записи пользователей, нет, ни один из них не называется «Дэвид Гилбертсон») для различных пакетов внешнего интерфейса и их зависимостей. «Эй, я исправил проблему x, а также добавил запись в журнал»
Короче говоря, конечный результат состоит в том, что по статистике несколько специалистов по сопровождению клюнут на приманку и внедряют вредоносный код в свою зависимость. Тогда это вопрос времени, когда код начнет захватывать учетные записи кредитных карт и отправлять их на удаленный сервер. .
Как это можно было смягчить? С подписью каждого компонента в цепочке, которая будет доказывать его подлинность, это то, что стремится сделать sigstore, чтобы дать разработчикам программного обеспечения возможность безопасно подписывать программные артефакты, такие как файлы релизов, образы контейнеров и двоичные файлы, которые затем будут храниться в защищенном от несанкционированного доступа публичный журнал — бесплатно.
Это решит проблему взлома учетной записи github (см. Дело о взломе учетной записи Gentoo или HomeBrew) или фальсификации выпуска из-за отсутствия подписи или неправильной подписи. Но что происходит тогда при сценарии npm? уже описал? Ничего особенного; единственное различие, которое это будет иметь, состоит в том, что злоумышленник должен был бы зарегистрироваться, чтобы получить ключ, и, сделав это, он, вероятно, оставил бы следы.
Что Sigstore покрывает первый случай:
Понимание и подтверждение происхождения и подлинности программного обеспечения основывается на зачастую несопоставимом наборе подходов и форматов данных. Существующие решения часто полагаются на дайджесты, которые хранятся в незащищенных системах, которые подвержены несанкционированному вмешательству и могут привести к различным атакам, таким как замена дайджестов или попадание пользователей в жертву целевых атак.
В деталях,
Пользователи генерируют эфемерные короткоживущие криптографические ключи с помощью клиентского инструментария sigstore и используют эти ключи для подписи программного обеспечения.
Служба sigstore PKI предоставит сертификат подписи X.509, сгенерированный после успешного предоставления подключения OpenID. Затем все сертификаты записываются в журнал прозрачности сертификатов, а материалы для подписи программного обеспечения отправляются в журнал прозрачности подписей.
Таким образом, вам не нужно самостоятельно управлять ключами, что также могло бы решить проблему этих ключей, которые много раз заканчивались тем, что записывались внутри самого источника репо, что фактически отменяло процесс подписания.
По сути, тегирование, отслеживание истории и предотвращение взлома — это подходящее место для использования блокчейна, но эта идея была отклонена на том основании, что:
Общедоступные блокчейны со всеми наилучшими намерениями часто заканчиваются использованием централизованной точки входа для канонизации, авторизации и т. Д.
Алгоритмы консенсуса могут быть уязвимы для большинства атак
В настоящее время журналы прозрачности более развиты в этой области, и они способны предоставить именно то, что нам нужно.
Состояние проекта в его нынешнем виде состоит в том, что журнал прозрачности существует, но инструмент для подписи клиента находится в стадии разработки и недоступен для общего использования.
Таким образом, Sigstore — достойная попытка защитить цепочку поставок, уменьшая большинство опасностей, но не все. Более поздний случай npm по-прежнему полагается на сопровождающего вручную и скрупулезно сканирует код PR, процесс, который вполне может не выявить его злонамеренные намерения.