GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

Пользователей GitHub.com предупреждают о смене закрытого ключа RSA, который используется для защиты Git-операций, выполняемых через SSH. Причиной замены является его компрометация: секрет кратковременно был доступен в публичном репозитории, куда попал по недосмотру.

Меры предосторожности были приняты сегодня, 24 марта, в 05:00 UTC (в восемь утра по Москве). В противном случае злоумышленники смогли бы сымитировать хостинг-сервис или отслеживать операции юзеров, использующих SSH.

«Данный ключ не предоставляет доступ к инфраструктуре GitHub или клиентским данным, — пояснил глава ИБ-службы хостера Майк Хэнли (Mike Hanley). — Изменения коснутся лишь Git-операций, выполняемых по SSH с использованием RSA».

Входящий веб-трафик GitHub.com и Git-операции через HTTP не затронуты. Те, кто использует ключи ECDSA и Ed25519, изменений не заметят, и никаких действий от них не потребуется.

В тех случаях, когда при подключении к сайту по SSH отображается такое сообщение, следует удалить прежний ключ RSA и добавить новый:

 

Для удаления ключа нужно выполнить команду:

 

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

 

Работы по обновлению всех тегов еще не завершены, поэтому пользователи GitHub Actions, включившие опцию ssh-key, могут столкнуться с отказом actions/checkout. Свидетельств злонамеренного использования попавшего в паблик ключа не обнаружено.

По словам Хэнли, это случайный слив, а не результат компрометации систем GitHub либо клиентской информации, как два месяца назад. Тогда злоумышленникам удалось украсть сертификаты подписи кода для macOS-клиента GitHub и редактора Atom.

38% крупных компаний делают свой ИИ, но защищать его умеют единицы

Российский бизнес всё активнее развивает собственные ИИ-сервисы, однако с их безопасностью дела обстоят заметно хуже. К такому выводу пришли эксперты К2 Кибербезопасность и «Лаборатории Касперского», опросившие специалистов более чем из 200 крупных компаний из сфер ИТ, финансов, телекоммуникаций, торговли, строительства и фармацевтики.

Исследование показало, что 38% крупных организаций уже имеют собственные команды, разрабатывающие ИИ-решения для внутренних процессов.

При этом в 75% случаев такие проекты полностью или частично не соответствуют практикам MLSecOps — подходу, который отвечает за безопасность систем искусственного интеллекта на всех этапах их жизненного цикла.

В целом компании не делают ставку на какой-то один инструмент. Более половины респондентов (59%) одновременно используют несколько типов ИИ-сервисов: отечественные и зарубежные решения, собственные разработки и продукты, созданные на заказ.

Наиболее востребованными остаются российские ИИ-сервисы — их используют 75% компаний. Зарубежные решения применяют 60% участников исследования. Такой расклад аналитики связывают с требованиями законодательства и политикой импортозамещения.

Однако внедрять ИИ бизнес научился быстрее, чем обеспечивать его безопасность. По данным исследования, лишь 18% компаний могут говорить о наличии управляемых процессов защиты собственных ИИ-разработок. Зрелые практики MLSecOps внедрены всего у 7% организаций.

Особенно тревожно выглядит другая цифра: в 60% случаев безопасность ИИ-проектов обеспечивают исключительно разработчики, без участия специалистов по информационной безопасности. Это увеличивает риск ошибок, утечек данных и появления новых уязвимостей.

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

RSS: Новости на портале Anti-Malware.ru