Утечка в Novo Nordisk выявила риск в цепочке разработки

Что произошло

18 июня 2026 г. - Мир кибербезопасности снова бурлит новостями об утечке в крупной компании. На этот раз в центре внимания Novo Nordisk, датский фармацевтический гигант, известный своими препаратами для лечения диабета и ожирения. Однако эта утечка — не типичная атака программы-вымогателя или взлом базы данных с кражей личных данных миллионов пользователей. Эта рана исходит изнутри, из самого сердца современной разработки программного обеспечения: утекший токен GitHub.

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

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

Какие данные были скомпрометированы

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

Потенциально под угрозой могут быть:

• Исходный код: Чертежи программного обеспечения, приложений и внутренних систем компании. Это одна из самых ценных частей интеллектуальной собственности компании. Для конкурентов или злоумышленников этот код подобен карте сокровищ.
• Конфигурации инфраструктуры: Файлы, определяющие, как настраиваются и управляются серверы, базы данных и облачные сервисы. Злоумышленник, обладающий этой информацией, может легко найти другие слабые места в системе.
• Другие встроенные секреты: Чтобы сэкономить время, разработчики иногда встраивают в код другие «секреты», такие как ключи API, пароли или сертификаты для доступа к другим системам. Первоначальный утекший токен может вызвать цепную реакцию, подобно тому, как один ключ открывает сейф с другим ключом.

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

Как произошла атака

В центре этой атаки не сложный эксплойт или уязвимость нулевого дня. В ее основе лежит «секрет», являющийся краеугольным камнем современной разработки ПО: токен GitHub. Технические детали атаки еще не были обнародованы, но суть инцидента предельно ясна.

Токен GitHub — это строка символов, которая предоставляет пользователю или инструменту автоматизации (например, конвейеру CI/CD) разрешение на доступ к репозиториям кода на GitHub. Он работает как пароль, но часто имеет более широкие полномочия и предназначен для межмашинного взаимодействия. Этот токен был каким-то образом скомпрометирован, например, случайно загружен в общедоступный репозиторий или украден с компьютера разработчика.

Как только злоумышленники получили этот токен, им больше не нужно было «взламывать» систему. Они вошли в систему как законный пользователь или сервис — владелец токена. Именно этот момент превращает инцидент из «проблемы инструментов» в «проблему идентификации».

Большинство организаций подходят к управлению секретами с установкой: «Давайте купим инструмент вроде HashiCorp Vault или AWS Secrets Manager, положим туда наши секреты, и мы в безопасности». Однако настоящая проблема в том, кто может получить доступ к этому хранилищу. Если вы оставите ключ от хранилища (в данном случае токен GitHub) на видном месте, не имеет значения, насколько безопасно само хранилище. Инцидент с Novo Nordisk показывает, что идентификационные данные людей и машин, получающих доступ к этим секретам, так же важны, как и сами секреты. Токен — это не просто пароль; это идентификатор. И когда этот идентификатор украден, злоумышленник становится вами.

Кто пострадал

Последствия этой утечки распространяются волнами.

• Novo Nordisk: Сама компания является главной жертвой. Она может столкнуться с серьезными последствиями, такими как кража интеллектуальной собственности, ущерб репутации, проверки со стороны регулирующих органов и возможные штрафы. Не говоря уже о немедленных инвестициях, которые им придется сделать для обеспечения безопасности своих процессов разработки ПО.
• Инвесторы и партнеры: Опасения по поводу состояния безопасности компании могут привести к колебаниям цен на акции и потере доверия со стороны деловых партнеров.
• Сообщество разработчиков: Этот инцидент служит предупреждением для разработчиков программного обеспечения по всему миру. Это болезненный урок, показывающий, как секрет, случайно добавленный в строку благонамеренного кода, может привести к катастрофическим последствиям.
• Потенциально пациенты и клиенты: Если утечка перерастет в атаку на цепочку поставок ПО, которая приведет к внедрению вредоносного кода в продукты, конечные пользователи продуктов Novo Nordisk также могут оказаться под угрозой. Хотя на данный момент это лишь возможность, это самый пугающий сценарий для подобных утечек.

Что вы можете сделать

Как отдельные разработчики, так и компании должны извлечь уроки из этого инцидента. Итак, что вы можете сделать?

Если вы разработчик:

• Никогда не встраивайте секреты в код: Это первое и самое важное правило. Пароли от баз данных, ключи API, токены... ничему из этого не место в вашем коде. Держите их отдельно.
• Используйте переменные окружения: Самый простой способ отделить секреты от кода — определить их в среде, где выполняется приложение. Это предотвращает хранение секретов вместе с кодом.
• Сканируйте свой код: Перед отправкой кода в репозиторий используйте инструменты, которые обнаруживают случайно добавленные секреты. В этом могут помочь инструменты с открытым исходным кодом, такие как `git-secrets`, или встроенные функции сканирования платформ.
• Принцип наименьших привилегий: Предоставляйте вашим токенам только минимальные разрешения, необходимые для выполнения их работы. Если токену нужно только читать код, не давайте ему права на запись или удаление.

Если вы управляете компанией или работаете в команде безопасности:

• Рассматривайте управление секретами как проблему идентификации: Покупки дорогого хранилища секретов недостаточно. Создайте строгие политики управления идентификацией и доступом (IAM), которые регулируют, кто (человек или машина), когда, откуда и почему получает доступ к этому хранилищу.
• Внедряйте автоматизацию: Настройте системы, которые автоматически сканируют код на наличие секретов перед тем, как разработчики смогут отправить его в репозиторий (интегрируйте это в ваш конвейер CI/CD). Если секрет обнаружен, автоматически блокируйте отправку.
• Регулярно ротируйте секреты: Пароли и ключи не должны быть вечными. Автоматически меняйте ваши секреты через определенные промежутки времени. Таким образом, даже если секрет утечет, окно возможностей для злоумышленника будет очень ограниченным.
• Обучение, обучение, обучение: Постоянно обучайте своих разработчиков безопасным методам кодирования и управлению секретами. Сделайте безопасность частью вашей культуры, где это ответственность каждого.

Что говорит компания

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

Источник

https://www.darkreading.com/cyber-risk/novo-nordisk-breach-exposes-dev-pipeline-risk