Docker Hub сделал сброс токенов проверкой подотчётности цепочки поставок контейнеров

Кратко

• Инцидент 2019 года с несанкционированным доступом к Docker Hub стал проверкой подотчётности в цепочке поставок контейнеров: публичные отчёты воспроизвели уведомление Docker пользователям, в котором говорилось, что был получен доступ к одной базе данных Hub, хранившей подмножество нефинансовых пользовательских данных, что данные примерно 190 000 аккаунтов могли быть раскрыты и что в зоне риска оказались токены GitHub и Bitbucket для автоматических сборок Docker.
• Кто фактически контролировал хранение токенов доступа, объём интеграций с репозиториями, уведомление клиентов, отзыв токенов, доверие к автоматическим сборкам и доказательства того, что инцидент в реестре не мог молча превратиться в более широкую компрометацию цепочки поставок ПО?
• Подтверждённая публичная картина, доступная через BleepingComputer по адресуhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/, и сохранённое уведомление пользователям наhttps://news.ycombinator.com/item?id=19763413подтверждают последовательность «раскрытие — сброс — повторное подключение — проверка журналов безопасности», а текущая документация Docker объясняет модель автоматических сборок и токенов.
• Обоснованный вывод состоит в том, что инцидент был не только событием безопасности аккаунтов. Поскольку автоматические сборки Docker Hub связывают Docker Hub с провайдерами исходного кода, раскрытие токенов создало вопрос управления, затрагивающий GitHub, Bitbucket, Docker Hub, CI/CD, публикацию образов и их последующее потребление.
• Остаётся неизвестное: публичные материалы не дают полного форензического отчёта Docker, точной схемы базы данных, объёма прав каждого токена, журналов доступа провайдеров исходного кода, доказательств отсутствия изменений в репозиториях, полного списка уведомлённых пользователей или подтверждения каждого действия клиента по устранению последствий.

Почему этот случай попал в досье рисков и подотчётности

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

Лучшая публичная запись об инциденте — это не действующая страница уведомления Docker. Старый URL поддержки Docker, на который ссылались отчёты 2019 года, больше не является надёжным живым источником. Поэтому публичная картина построена на воспроизведённом тексте уведомления пользователям и современных репортажах. BleepingComputer сообщилисточник: bleepingcomputer.com, что Docker узнал о несанкционированном доступе к базе данных Docker Hub 25 апреля 2019 года и что затронутые данные включали имена пользователей, хешированные пароли небольшой части пользователей, а также токены GitHub и Bitbucket, использовавшиеся для автоматических сборок Docker. В той же статье был воспроизведён текст уведомления пользователям.

Сохранённая публикация на Hacker News по адресуисточник: news.ycombinator.comпоказывает текст уведомления, включая утверждения, что могли быть раскрыты данные примерно 190 000 аккаунтов, что это менее 5 % пользователей Hub и что Docker отозвал токены GitHub и ключи доступа у затронутых пользователей автоматических сборок.

Это подтверждённые факты, на которые опирается статья: сообщалось о несанкционированном доступе к базе данных Docker Hub; в зоне риска оказалось подмножество нефинансовых пользовательских данных; данные примерно 190 000 аккаунтов могли быть раскрыты; среди них были некоторые имена пользователей и хешированные пароли; в зоне риска были токены GitHub и Bitbucket для автоматических сборок Docker; Docker попросил пользователей сменить пароли там, где это уместно; Docker заявил, что отозвал затронутые токены и ключи доступа; Docker попросил пользователей автоматических сборок заново подключить репозитории и проверить журналы безопасности

провайдеров исходного кода.

Security Affairsисточник: securityaffairs.com, The Hacker Newsисточник: thehackernews.comи Help Net Securityисточник: helpnetsecurity.comсообщили о той же базовой последовательности событий.

Обоснованный вывод: это было событие управления цепочкой поставок, даже если ни один открытый источник не доказывает компрометацию ниже по цепочке. Текущая документация Docker по автоматическим сборкамисточник: docs.docker.comобъясняет, что Docker Hub может автоматически собирать образы из репозиториев исходного кода и отправлять готовые образы в репозитории Docker. Документация о подключении источникаисточник: docs.docker.comобъясняет, что пользователи подключают провайдеров GitHub или Bitbucket, чтобы Docker Hub мог получать доступ к репозиториям исходного кода. Страница настройкиисточник: docs.docker.comговорит, что автоматические сборки могут создавать образ при отправке кода провайдеру исходного кода.

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

Неизвестное остаётся существенным. Публичные материалы не называют злоумышленника, способ доступа, поля базы данных, все права токенов, не показывают, использовался ли какой-либо токен, был ли изменён какой-либо репозиторий исходного кода, был ли пересобран какой-либо образ с несанкционированными изменениями и как Docker подтвердил отсутствие или наличие злоупотребления. Поэтому статья избегает необоснованных обвинений. Она не утверждает, что образы Docker Hub были отравлены, исходный код изменён или Docker скрыл более крупную компрометацию.

В ней говорится, что раскрытие токенов на платформе автоматических сборок создало обязанность подотчётности: доказать отзыв токенов, объём их прав, действия клиентов и целостность цепочки сборки.

Подтверждённые факты, обоснованные выводы и неизвестное

Подтверждённая публичная хронология начинается 25 апреля 2019 года, когда в уведомлении Docker говорилось, что компания обнаружила несанкционированный доступ к одной базе данных Hub. Текст уведомления, сохранённый по адресуисточник: news.ycombinator.com, гласил, что база данных хранила подмножество нефинансовых пользовательских данных и что Docker вмешался, чтобы защитить сайт. В уведомлении говорилось, что чувствительные данные примерно 190 000 аккаунтов могли быть раскрыты. Эта группа была описана как менее 5 % пользователей Hub. В нём были перечислены такие классы данных, как имена пользователей и хешированные пароли небольшой части пользователей, а также токены GitHub и Bitbucket для автоматических сборок Docker.

Подтверждённая публичная последовательность устранения последствий состоит из трёх слоёв. Во-первых, Docker попросил затронутых пользователей сменить пароль Docker Hub и любой другой пароль аккаунта, который совпадал с ним. Во-вторых, для пользователей автоматических сборок, которые могли пострадать, Docker заявил, что отозвал токены GitHub и ключи доступа, и попросил заново подключить репозитории. В-третьих, Docker попросил пользователей проверить журналы безопасности GitHub и Bitbucket на предмет неожиданных действий.

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

Обоснованный вывод: Docker правильно счёл отзыв токенов более важным, чем один только сброс пароля. Раскрытие пароля угрожает аккаунту Docker Hub. Раскрытие токена провайдера исходного кода угрожает мосту между Docker Hub и репозиторием кода. Этот мост может иметь последствия для чтения или записи в зависимости от прав, предоставленных провайдером, и модели интеграции. Документация GitHub по OAuth по адресуисточник: docs.github.comпредупреждает пользователей о необходимости проверять авторизованные приложения и обращать внимание на широкие права, включая доступ к приватным репозиториям.

Документация GitHub о журнале безопасностиисточник: docs.github.comобъясняет, что пользователи могут просматривать действия, связанные с их аккаунтом. Руководство Bitbucket Cloud по журналу аудитаисточник: support.atlassian.comобъясняет, что журналы аудита рабочего пространства отслеживают ключевые действия. Эти источники подтверждают практическую модель устранения последствий: отозвать, переподключить, проверить журналы и убедиться.

Неизвестное определяет границу суждений. Публичные материалы не включают список затронутых клиентов, полный объём прав токенов, доказательства того, что каждый отозванный токен не использовался, полную корреляцию журналов GitHub или Bitbucket, список сборок, упавших из-за отзыва, или технический отчёт после инцидента. Также из публичных данных неясно, поняли ли все затронутые пользователи разницу между сменой пароля Docker и проверкой репозиториев провайдеров исходного кода.

Этот пробел в коммуникации важен, потому что злоупотребление провайдером исходного кода, если бы оно произошло, было бы видно прежде всего в активности GitHub или Bitbucket, а не обязательно в Docker Hub.

Хранение токенов сделало реестр зависимостью от контроля исходного кода

Ключевой вопрос подотчётности — хранение токенов. Реестр, предлагающий автоматические сборки, просит разработчиков подключать провайдеров исходного кода. Это подключение ценно, потому что сокращает ручную работу. Отправка в GitHub или Bitbucket может запустить сборку в Docker Hub, а полученный образ может быть отправлен в реестр для дальнейшего использования. Но то же подключение создаёт обязанность хранения. Docker Hub хранит или контролирует учётные данные, которые могут влиять на доступ к исходному коду и поведение сборки. Когда эти учётные данные раскрыты, инцидент в реестре переходит в риск для контроля исходного кода.

Текущая документация Docker по-прежнему показывает форму этой зависимости. Обзор автоматических сборокисточник: docs.docker.comговорит, что Docker Hub может автоматически собирать образы из исходного кода во внешнем репозитории и отправлять собранный образ в репозитории Docker. Страница подключения источникаисточник: docs.docker.comговорит, что пользователи подключают хостинг исходного кода к Docker Hub, чтобы Docker Hub мог получать доступ к репозиториям исходного кода. Страница настройкиисточник: docs.docker.comназывает GitHub и Bitbucket провайдерами исходного кода.

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

Для разработчика путь автоматизации выглядит нормально. Настроить провайдера исходного кода. Определить правила сборки. Пусть отправки запускают образы. Позже скачать образ. Для аналитика подотчётности этот путь — цепочка хранения. Кто может авторизовать провайдера исходного кода? Какие права запрашиваются? Привязаны ли токены к пользователю, команде или сервисному аккаунту? Хранятся ли они в зашифрованном виде? Ротируются ли они? Можно ли их отозвать массово? Подписаны ли сборки или иным образом подтверждаемы? Изменяемы ли теги образов? Хранятся ли журналы достаточно долго, чтобы восстановить подозрительную пересборку?

Эти вопросы становятся срочными после раскрытия токенов.

Уведомление Docker, воспроизведённое публично, частично ответило на вопросы действиями. Токены были отозваны. Пользователям сказали переподключиться. Были названы журналы безопасности. Было сказано, что дополнительный мониторинг включён. Это заслуживающий доверия первый ответ. Но он не доказал всю цепочку. Он не показал, какие права были у раскрытых токенов, как долго длился несанкционированный доступ, получили ли какие-либо репозитории исходного кода доступ с неожиданных адресов, изменились ли какие-либо результаты сборок и мог ли Docker соотнести каждый токен с активностью провайдера исходного кода.

Именно поэтому событие — не просто история об уведомлении об утечке. Это история о контроле над платформой для разработчиков. Реестр, хранящий токены сборки-интеграции, должен уметь отвечать не только на вопрос «чьи данные аккаунта были раскрыты?», но и на вопрос «могло ли это раскрытие изменить код, изменить образы или изменить то, что развёртывали нижестоящие системы?». Ответ может быть «нет». Но подотчётная запись требует доказательств.

Автоматические сборки превратили удобство в радиус поражения

Автоматические сборки — классическая функция производительности со скрытой ценой для устойчивости. Документация Dockerисточник: docs.docker.comописывает правило ветки или тега, запускающее сборку при изменении исходного кода. Сборка затем создаёт образ и отправляет его в Docker Hub. Это снижает трение ручного релиза. Это также означает, что учётные данные, привязанные к пути автоматизации, могут находиться выше опубликованного артефакта. Если учётные данные имеют слишком широкие права, долго живут, привязаны к пользователю с широкими полномочиями или слабо отслеживаются, компрометация реестра может создать неопределённость в отношении исходного кода и целостности образов.

Инцидент 2019 года публично не доказал вредоносную публикацию образов. Подотчётный момент в том, что такая возможность должна была быть расследована. BleepingComputerисточник: bleepingcomputer.comпредупреждал, что токены могут дать доступ к коду приватных репозиториев и, возможно, к его изменению в зависимости от прав. Это сформулировано как сценарий риска, а не подтверждённый исход. Help Net Securityисточник: helpnetsecurity.comтакже подчёркивала опасность токенов. Дисциплинированная статья должна сохранять эту границу: раскрытие токенов создало риск для цепочки поставок; публичные доказательства не показывают, что риск реализовался.

Требование к устранению последствий жёсткое. Смены пароля недостаточно. Отзыв токенов необходим, но недостаточен. Повторное подключение может восстановить сборки, но может скрыть пропущенную аудиторскую работу, если команды спешат вернуть пайплайны в зелёную зону. Ответственный клиент должен был проверить журналы безопасности GitHubисточник: docs.github.com, проверить авторизованные OAuth-приложенияисточник: docs.github.com, просмотреть журналы аудита Bitbucketисточник: support.atlassian.comи отозвать или заменить скомпрометированные токены доступа, используя такие руководства, какисточник: support.atlassian.com.

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

Это особенно трудно для мейнтейнеров открытого ПО и небольших команд. У крупных предприятий могут быть журналы, интеграция с SIEM, управление репозиториями и плейбуки реагирования на инциденты. Волонтёр-мейнтейнер может иметь личный аккаунт Docker Hub, связанный с репозиторием GitHub, ограниченную видимость журналов и пользователей ниже по цепочке, которые тянут образы без прямого контакта. Экономика инструментов разработчика поощряет удобство и низкое трение. Подотчётность требует относиться к полученному в результате парку токенов как к производственной инфраструктуре.

Уведомление переложило работу по устранению последствий на мейнтейнеров

Уведомление Docker, воспроизведённое публично, сделало больше, чем объявило о раскрытии. Оно распределило работу. Пользователи должны были сменить пароли, где уместно, переподключить провайдеров исходного кода, проверить журналы безопасности и восстановить сломанные автоматические сборки. Это был разумный ответ на инцидент с токенами, но он также перенёс стоимость на мейнтейнеров и организации. Сторона, контролировавшая скомпрометированную базу данных, могла отозвать токены и разослать уведомления. Стороны, контролировавшие репозитории исходного кода, должны были доказать, использовался ли раскрытый мост.

Это важно, потому что возможности мейнтейнеров сильно различаются. Предприятие с контролем аудита организации GitHub, журналами рабочего пространства Bitbucket, администрированием организации Docker и мониторингом CI/CD может собрать файл доказательств. Оно может спросить, кто авторизовал приложение, какие права на репозитории были предоставлены, какие токены были отозваны, какие задания сборки упали и изменились ли какие-либо коммиты исходного кода или теги образов в этом окне. Индивидуальный мейнтейнер может увидеть только сбивающее с толку письмо, сломанную автоматическую сборку и просьбу проверить журналы.

Поэтому один и тот же инцидент создаёт неравное бремя устранения последствий по всей экосистеме.

Бремя устранения последствий также распространяется на нижестоящих пользователей, которые не получали исходное уведомление. Компания, тянущая публичный образ, может не знать, попал ли аккаунт мейнтейнера в Docker Hub в зону риска. Мейнтейнер может не знать каждого нижестоящего потребителя. Платформа реестра может знать раскрытие на уровне аккаунтов, но не каждую развёрнутую копию образа. Это структурная причина, по которой инциденты с токенами на платформах разработчиков заслуживают анализа цепочки поставок. Прямое раскрытие измеряется аккаунтами. Эффект доверия измеряется артефактами, зависимостями и допущениями.

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

Публичная запись показывает, что уведомление Docker действительно называло переподключение и журналы безопасности провайдеров исходного кода. Это сильная сторона. Оставшийся пробел — доказательство закрытия. Публичные читатели не видят, подтвердил ли Docker позже отсутствие злоупотребления токенами, были ли успешно отозваны все затронутые токены, не была ли пропущена какая-то группа клиентов и дошёл ли до клиентов итоговый отчёт. Частное закрытие могло существовать. Его нет в публичной записи, доступной для этой статьи. Эту неопределённость следует фиксировать, а не заполнять предположениями.

Журналы провайдеров исходного кода стали слоем доказательств для клиента

Уведомление Docker просило пользователей проверить действия безопасности GitHub или Bitbucket на предмет неожиданного доступа. Это указание было правильным, но оно также раскрывает предел подотчётности. Docker мог отозвать токены и определить затронутые аккаунты Docker Hub. Доказательства того, был ли доступ к репозиторию исходного кода или его изменение, могли находиться в журналах другой компании и под аккаунтом клиента. Это превращает инцидент одной платформы в межпровайдерное расследование.

Страница журнала безопасности GitHubисточник: docs.github.comобъясняет, что пользователи аккаунта могут просматривать действия, связанные с ними. Страница проверки OAuth-приложений GitHubисточник: docs.github.comговорит пользователям убедиться, что не авторизованы новые приложения с широкими правами. Руководство GitHub по ограничению доступа OAuthисточник: docs.github.comобъясняет, как организации могут контролировать доступ OAuth-приложений к ресурсам организации. Эти средства контроля становятся центральными, когда сторонняя интеграция сборки находится в зоне риска.

Документация Bitbucket по OAuthисточник: support.atlassian.comобъясняет потоки токенов и авторизацию провайдера. Руководство Bitbucket Cloud по журналу аудитаисточник: support.atlassian.comописывает ведение журнала на уровне рабочего пространства. Руководство Bitbucket по отзыву токенаисточник: support.atlassian.comи отзыву токена репозиторияисточник: support.atlassian.comобъясняют, как можно удалить доступ. Эти документы показывают доказательства и работу по устранению последствий, которую клиентам приходилось координировать за пределами Docker.

Задача подотчётности — корреляция. Клиенту нужно связать уведомление Docker о затронутом аккаунте, отзыв токенов Docker, журналы GitHub или Bitbucket, сбои автоматических сборок, активность в репозитории и историю публикации образов. Если клиент не может соотнести эти записи, расследование завершается допущением. Это может быть приемлемо для низкорискового любительского проекта. Это неприемлемо для корпоративной цепочки сборки или широко потребляемого open-source образа.

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

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

Более поздние рекомендации Docker по токенам помогают определить, как должно выглядеть устойчивое устранение последствий. Документация Docker по персональным токенам доступаисточник: docs.docker.comобъясняет создание токенов, срок действия, права и управление. Документация Docker по токенам доступа организацииисточник: docs.docker.comподчёркивает права на репозитории с ограниченной областью, права управления, ротацию, мониторинг использования токенов и безопасное хранение. Блог Docker 2019 года о персональных токенах доступаисточник: docker.comописывал токены как замену паролей и строительный блок для расширенного контроля доступа.

Блог Docker 2021 года о токенах с ограниченной областьюисточник: docker.comсделал направление минимальных привилегий явным.

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

Документация Docker по миграцииисточник: docs.docker.comтакже актуальна, потому что в ней говорится, что Docker Hub Automated Builds устарел и будет выведен из эксплуатации 1 апреля 2027 года. Страница рекомендует миграцию на CI/CD-процессы с созданием токенов и безопасным хранением в менеджерах секретов CI/CD-платформ. Это будущее направление не стирает инцидент 2019 года. Оно усиливает мысль о том, что учётные данные автоматизированных сборок, размещённые в реестре, являются особым предметом управления. Перенос автоматизации в CI/CD не устраняет токенный риск. Он меняет того, кто хранит токен, кто ведёт журнал использования и кто может доказать сборку.

NIST SP 800-218источник: csrc.nist.govрекомендует практики безопасной разработки ПО, которые могут быть интегрированы в жизненные циклы разработки. Форма подтверждения безопасной разработки ПО от CISAисточник: cisa.govотражает тренд государственного сектора в сторону практик безопасной разработки, подтверждённых доказательствами. Памятка OWASP по безопасности CI/CDисточник: cheatsheetseries.owasp.orgрассматривает CI/CD-пайплайны как поверхности атак высокой ценности. Памятка OWASP по управлению секретамиисточник: cheatsheetseries.owasp.orgподчёркивает централизацию, ротацию, аудит и контроль жизненного цикла секретов.

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

Принцип минимальных привилегий полезен, только если он наблюдаем

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

Для автоматических сборок Docker Hub полезные вопросы конкретны. Мог ли токен читать приватные репозитории? Мог ли он записывать ключи развёртывания или вебхуки? Мог ли он менять содержимое репозитория? Мог ли он запускать сборки? Мог ли он читать секреты сборки? Мог ли он отправлять образы? Был ли он привязан к одному репозиторию, одной организации или широкому доступу одного пользователя? Использовался ли он из неожиданного сетевого расположения в окне раскрытия? Могли ли Docker и провайдер исходного кода соотнести идентификаторы токенов, не раскрывая секреты? Публичная запись не отвечает на эти вопросы. Устойчивая модель контроля должна.

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

Более поздние материалы Docker о токенах доступаисточник: docs.docker.comиисточник: docs.docker.comуказывают на более подотчётную модель, поскольку подчёркивают права, управление, мониторинг и безопасное хранение. Та же идея присутствует в организационных средствах контроля GitHub и Bitbucket. Недостаточно дать пользователям возможность создавать токены. Платформы должны делать область токена понятной до создания, видимой во время использования и восстанавливаемой после раскрытия.

Для экосистем CI/CD и реестров наблюдаемый принцип минимальных привилегий должен стать контрактным ожиданием. Поставщик, хранящий учётные данные сборки, должен уметь идентифицировать класс учётных данных, область действия, владельца, время создания, последнее использование, защиту хранения, состояние ротации и состояние отзыва. Клиент должен иметь возможность экспортировать достаточно журналов для расследования, не полагаясь только на тикеты поддержки. Нижестоящие пользователи должны иметь возможность закреплять дайджесты образов или проверять происхождение там, где это поддерживается процессом. Результат — не идеальная безопасность.

Это меньшее и лучше проверяемое поле неопределённости.

Контейнерные образы несут доверие ниже по цепочке

Инцидент имел значение, потому что контейнеры — это артефакты ниже по цепочке. Docker-образ может быть скачан на ноутбук разработчика, в CI-задание, кластер Kubernetes, облачный сервис, тестовую среду или продакшен-хост. Он может быть закреплён по тегу, закреплён по дайджесту, зеркалирован внутри организации, просканирован, пересобран или скачан напрямую из Docker Hub. Если раскрытие токена выше по цепочке создаёт неопределённость в отношении исходного кода или целостности образа, нижестоящий потребитель может не знать, какое допущение проверять.

Академические работы усиливают общий контекст риска. Исследование 2020 года об уязвимостях образов Docker Hubисточник: arxiv.orgизучало тысячи образов и описывало Docker Hub как крупный репозиторий образов. Исследование 2023 года о секретах в контейнерных образахисточник: arxiv.orgобнаружило, что раскрытые секреты в контейнерных образах могут иметь реальное влияние: сертификаты, секреты API, хосты. Эти исследования ничего не доказывают об инциденте 2019 года с базой данных Docker Hub. Они показывают, почему реестры образов и контейнерные артефакты являются поверхностями высоких последствий для цепочек поставок ПО.

Ключевое различие — между компрометацией платформы и риском, созданным пользователем. Инцидент 2019 года касался данных аккаунтов и интеграций Docker Hub. Проблема секретов в образах часто касается пользователей, случайно запекающих учётные данные в образы. Оба риска встречаются в реестре. Платформа должна защищать данные аккаунтов и токенов. Пользователи должны избегать публикации секретов и проверять происхождение образов. Нижестоящие потребители должны решать, каким образам доверять. Зрелая экосистема реестров поддерживает все три роли средствами контроля и доказательствами.

Для Docker Hub вопрос подотчётности после раскрытия токенов был не только «сброшены ли пароли?». Он звучал так: «может ли мейнтейнер доказать, что исходный код и вывод образов не были изменены в окне раскрытия?». Такое доказательство может потребовать журналов репозитория, журналов сборок, дайджестов образов, подписанных тегов, проверок коммитов исходного кода, анализа зависимостей и решений о повторном развёртывании ниже по цепочке. Если команды не могут предоставить такого доказательства, им, возможно, придётся пересобрать и переопубликовать образы из доверенных источников.

Эта стоимость не должна быть невидимой. Прямое число в публичном уведомлении — примерно 190 000 аккаунтов. Косвенное число невозможно узнать из публичных данных: проекты, образы, CI-системы и развёртывания ниже по цепочке, затронутые этими аккаунтами. Небольшая затронутая группа в процентном отношении к платформе всё равно может иметь значение, если некоторые аккаунты сопровождают широко используемые образы или приватные корпоративные сборки.

Что клиенты должны были иметь возможность проверить

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

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

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

В-четвёртых, клиентам нужно было проверить гигиену учётных данных. Сброс пароля важен, если в зоне риска были хешированные пароли. Но OAuth-токены провайдеров исходного кода, токены доступа Docker Hub, секреты CI/CD, ключи развёртывания, секреты вебхуков и учётные данные реестра имеют разные жизненные циклы. Памятка OWASP по управлению секретамиисточник: cheatsheetseries.owasp.orgполезна здесь, потому что рассматривает управление секретами как хранение, предоставление, аудит, ротацию и контроль жизненного цикла, а не разовый сброс.

В-пятых, клиентам нужно было проверить будущее управление. Ограничения доступа OAuth для организаций GitHubисточник: docs.github.comмогут предотвратить неуправляемый доступ OAuth-приложений. Токены доступа организации Dockerисточник: docs.docker.comмогут быть ограничены репозиториями и действиями управления. Права токенов на уровне репозитория Bitbucketисточник: support.atlassian.comмогут ограничить полномочия токена. Эти средства контроля уменьшают радиус поражения при раскрытии следующей интеграции.

Что должно доказывать устойчивое устранение последствий

Устойчивое устранение последствий после инцидента с токенами в реестре разработчиков должно доказать шесть вещей. Во-первых, масштаб. Провайдер должен знать, какие аккаунты, классы токенов, провайдеры исходного кода и репозитории были затронуты, и должен различать подтверждённое и возможное раскрытие. Если точное доказательство недоступно, эта неопределённость должна быть названа.

Во-вторых, отзыв. Инвалидация токена должна фиксироваться с указанием времени, цели, провайдера и статуса успеха. Если отзыв не удался для какого-либо провайдера или клиента, исключение должно быть видимым. «Мы отозвали токены» полезно, но клиентам нужно знать, был ли отозван их токен и нужно ли им предпринять дополнительные действия.

В-третьих, анализ злоупотреблений. Провайдер должен сохранить и проанализировать доступные доказательства того, использовались ли раскрытые токены во время или после несанкционированного доступа. Поскольку часть доказательств находится у провайдеров исходного кода, провайдер должен предоставить клиентам достаточно идентификаторов и временных окон для самостоятельной проверки. Публичная запись по Docker Hub не показывает полного анализа злоупотреблений. Это остаётся неизвестным.

В-четвёртых, целостность цепочки сборки. Для платформ автоматических сборок восстановление должно включать журналы сборок, корреляцию коммитов исходного кода, проверку дайджестов образов, историю тегов и сверку упавших сборок. Если выводы образов не могли быть затронуты из-за ограниченной области токенов, это должно быть объяснено. Если выводы образов могли быть затронуты, клиентам нужен путь пересборки и уведомлений.

В-пятых, коммуникация с клиентами. Уведомление должно разделять подтверждённые факты, действия клиента, действия провайдера, неизвестное, следующие обновления и каналы поддержки. Оно также должно разъяснять, что переподключение провайдеров исходного кода восстанавливает функциональность, но не заменяет проверку журналов исходного кода. Уведомление Docker, как оно воспроизведено, перечисляло действия и указывало на журналы GitHub и Bitbucket. Более сильная публичная запись включала бы итоговое заявление о закрытии.

В-шестых, будущий принцип минимальных привилегий. Хранение токенов должно двигаться в сторону ограничения области, коротких сроков жизни, сервисных аккаунтов, прав на уровне репозитория, ротации, мониторинга и централизованного управления секретами. Более поздняя документация Docker по токенам с ограниченной областью и токенам организации отражает это направление. Подотчётный стандарт не в том, что каждый контроль 2019 года уже соответствовал будущим рекомендациям. Он в том, что инцидент с токенами должен производить устойчивое движение к минимальным привилегиям и проверяемому использованию.

Ответственность следует за учётными данными, а не только за аккаунтом

Окончательное распределение должно следовать пути учётных данных. Docker контролировал базу данных Hub, среду хранения токенов, уведомление пользователей и отзыв токенов. GitHub и Bitbucket контролировали авторизацию провайдеров исходного кода, журналы и механизмы отзыва на своей стороне. Клиенты контролировали репозитории, определения сборок, организационные политики и уведомления ниже по цепочке. Пользователи и развёртывающие контролировали, закрепляли ли они образы, проверяли ли дайджесты, пересобирали ли из исходного кода или продолжали тянуть изменяемые теги.

Это распределение точнее, чем «Docker отвечал за всё» или «клиенты отвечали за всё». Docker имел лучший обзор инцидента с базой данных и популяции раскрытых токенов. Клиенты имели лучший обзор активности в репозиториях и использования образов. Провайдеры исходного кода имели лучший обзор активности токенов внутри своих систем. Нижестоящие пользователи имели наименьшую видимость и наибольшую зависимость от доказательств мейнтейнеров. Цепочка работает, только если каждая сторона может предоставить доказательства, которые она уникально контролирует.

Подотчётность по пути учётных данных также меняет то, как следует называть инциденты. Назвать событие утечкой аккаунтов — точно, но неполно. Назвать его инцидентом хранения токенов полезнее, потому что это направляет внимание на мосты между системами. Раскрытие одних и тех же имени пользователя и пароля может быть ограничено одной платформой. Раскрытие токена может по замыслу достичь другой платформы. Чем сильнее интеграция, тем больше ответ должен следовать за учётными данными.

Для цепочек поставок ПО этот урок остаётся актуальным даже по мере ухода Docker Hub Automated Builds в прошлое. CI/CD-системы, пакетные реестры, репозитории артефактов, облачные развёртывания, хостинги исходного кода, сервисы сканирования и автоматизация релизов используют учётные данные для соединения сервисов. Каждая удобная интеграция создаёт вопрос хранения. Где хранятся учётные данные? Кто может их использовать? К чему они имеют доступ? Как их отзывают? Какие доказательства подтверждают отсутствие злоупотреблений? Инцидент в реестре 2019 года всё ещё важен, потому что эти вопросы стали только более центральными.

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

Контрфактуал не «инцидента не было», а «не было молчаливого пути в цепочке поставок»

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

Инцидент с Docker Hub в 2019 году показывает, как быстро проблема реестра становится проблемой контроля. Docker контролировал базу данных Hub, уведомление пользователей, отзыв токенов и интеграцию автоматических сборок. GitHub и Bitbucket контролировали свои журналы, OAuth-контроль и механизмы отзыва токенов. Клиенты контролировали репозитории исходного кода, конфигурацию сборки, публикацию образов и уведомление ниже по цепочке. Нижестоящие пользователи контролировали загрузку, закрепление и решения о развёртывании. Инцидент в реестре прошёл через все эти слои, потому что интеграционные токены связывали их.

Это распределение не поддерживает необоснованных обвинений. Публичная запись не доказывает, что репозитории исходного кода Docker Hub были изменены или образы скомпрометированы. Она доказывает, что хранение интеграционных токенов Docker создало более широкую обязанность подотчётности, чем обычное событие с паролями. Правильный вопрос не «был ли подтверждён каждый худший сценарий?». Правильный вопрос: «какие доказательства закрыли каждый сценарий и кто мог их увидеть?»

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