GitGuardian известен своим ежегодным отчетом о распространении секретов. В своем отчете за 2023 год они обнаружили более 10 миллионов незащищенных паролей, ключей API и других учетных данных, открытых в общедоступных коммитах на GitHub. Выводы из их отчета за 2024 год не только выявили 12,8 миллиона новых открытых секретов на GitHub, но и некоторое количество в популярном репозитории пакетов Python PyPI.
PyPI, сокращение от Python Package Index , содержит более 20 терабайт файлов, которые находятся в свободном доступе для использования в проектах Python. Если вы когда-либо вводили pip install [название пакета], скорее всего, он извлек этот пакет из PyPI. Многие люди тоже им пользуются. В отчете говорится, что, будь то GitHub, PyPI или другие, "пакеты с открытым исходным кодом составляют примерно 90% кода, запускаемого сегодня в производство." Легко понять, почему это происходит, когда эти пакеты помогают разработчикам избежать ежедневного изобретения миллионов колес.
В отчете за 2024 год GitGuardian сообщила об обнаружении более 11 000 открытых уникальных секретов, причем 1000 из них были добавлены в PyPI в 2023 году. Это немного по сравнению с 12,8 миллионами новых секретов, добавленных на GitHub в 2023 году, но GitHub на порядки больше.
Более печальным фактом является то, что из секретов, представленных в 2017 году, почти 100 все еще действовали 6-7 лет спустя. У них не было возможности проверить все секреты на достоверность. Тем не менее, было обнаружено более 300 уникальных и достоверных секретов. Хотя это слегка настораживает стороннего наблюдателя и не обязательно представляет угрозу для случайных разработчиков Python (в отличие от 116 вредоносных пакетов, о которых ESET сообщила в конце 2023 года), это угроза неизвестного масштаба для владельцев этих пакетов.
Хотя GitGuardian располагает сотнями детекторов секретов, которые он разрабатывал и совершенствовал на протяжении многих лет, одними из наиболее распространенных секретов, которые он обнаружил в своем общем исследовании 2023 года, были ключи OpenAI API, Google API keys и Google Cloud keys. Компетентному программисту нетрудно написать регулярное выражение, чтобы найти единый общий секретный формат. И даже если он выдал много ложных срабатываний, автоматизация проверок для определения их достоверности может помочь разработчику найти небольшую сокровищницу секретов, которые можно использовать.
Теперь общепринятой логикой является то, что если ключ был опубликован в общедоступном репозитории, таком как GitHub или PyPI, его следует считать скомпрометированным. В тестах honeytokens (разновидность "деактивированного" API-ключа без доступа к каким-либо ресурсам) были проверены ботами на действительность в течение минуты после публикации на GitHub. Фактически, honeytokens выступают в роли "канарейки" для растущего числа разработчиков. В зависимости от того, где вы разместили конкретный honeytoken, вы можете увидеть, что кто-то там просматривал, и получить некоторую информацию о нем на основе данных телеметрии, собранных при использовании honeytoken.
Большая проблема, когда вы случайно публикуете секрет, заключается не только в том, что злоумышленник может увеличить ваш счет за облако. Это то, куда они могут пойти дальше. Если произошла утечка токена AWS IAM с чрезмерными правами доступа, что может обнаружить злоумышленник в пакетах S3 или базах данных, к которым он предоставляет доступ? Может ли этот злоумышленник получить доступ к другому исходному коду и повредить что-то, что будет доставлено многим другим?
Независимо от того, передаете ли вы секреты на GitHub, в PyPI, NPM или любую общедоступную коллекцию исходного кода, лучший первый шаг, когда вы обнаружите утечку секрета, - это отозвать его. Помните о крошечном промежутке между публикацией и использованием honeytoken . Как только секрет был опубликован, он, скорее всего, был скопирован. Даже если вы не обнаружили несанкционированного использования, вы должны предположить, что оно теперь у кого-то несанкционированного и злонамеренного.
Даже если ваш исходный код находится в частном репозитории, существует множество историй о злоумышленниках, получающих доступ к частным репозиториям с помощью социальной инженерии, фишинга и, конечно же, утечки секретов. Если из всего этого и можно извлечь урок, так это то, что текстовые секреты в исходном коде в конечном итоге обнаруживаются. Независимо от того, публикуются ли они случайно публично или их находит кто-то, у кого нет доступа, которого у них не должно быть, они обнаруживаются.
Подводя итог, где бы вы ни хранили или публиковали свой исходный код, будь то частный репозиторий или публичный реестр, вы должны следовать нескольким простым правилам:
PyPI, сокращение от Python Package Index , содержит более 20 терабайт файлов, которые находятся в свободном доступе для использования в проектах Python. Если вы когда-либо вводили pip install [название пакета], скорее всего, он извлек этот пакет из PyPI. Многие люди тоже им пользуются. В отчете говорится, что, будь то GitHub, PyPI или другие, "пакеты с открытым исходным кодом составляют примерно 90% кода, запускаемого сегодня в производство." Легко понять, почему это происходит, когда эти пакеты помогают разработчикам избежать ежедневного изобретения миллионов колес.
В отчете за 2024 год GitGuardian сообщила об обнаружении более 11 000 открытых уникальных секретов, причем 1000 из них были добавлены в PyPI в 2023 году. Это немного по сравнению с 12,8 миллионами новых секретов, добавленных на GitHub в 2023 году, но GitHub на порядки больше.
Более печальным фактом является то, что из секретов, представленных в 2017 году, почти 100 все еще действовали 6-7 лет спустя. У них не было возможности проверить все секреты на достоверность. Тем не менее, было обнаружено более 300 уникальных и достоверных секретов. Хотя это слегка настораживает стороннего наблюдателя и не обязательно представляет угрозу для случайных разработчиков Python (в отличие от 116 вредоносных пакетов, о которых ESET сообщила в конце 2023 года), это угроза неизвестного масштаба для владельцев этих пакетов.
Хотя GitGuardian располагает сотнями детекторов секретов, которые он разрабатывал и совершенствовал на протяжении многих лет, одними из наиболее распространенных секретов, которые он обнаружил в своем общем исследовании 2023 года, были ключи OpenAI API, Google API keys и Google Cloud keys. Компетентному программисту нетрудно написать регулярное выражение, чтобы найти единый общий секретный формат. И даже если он выдал много ложных срабатываний, автоматизация проверок для определения их достоверности может помочь разработчику найти небольшую сокровищницу секретов, которые можно использовать.
Теперь общепринятой логикой является то, что если ключ был опубликован в общедоступном репозитории, таком как GitHub или PyPI, его следует считать скомпрометированным. В тестах honeytokens (разновидность "деактивированного" API-ключа без доступа к каким-либо ресурсам) были проверены ботами на действительность в течение минуты после публикации на GitHub. Фактически, honeytokens выступают в роли "канарейки" для растущего числа разработчиков. В зависимости от того, где вы разместили конкретный honeytoken, вы можете увидеть, что кто-то там просматривал, и получить некоторую информацию о нем на основе данных телеметрии, собранных при использовании honeytoken.
Большая проблема, когда вы случайно публикуете секрет, заключается не только в том, что злоумышленник может увеличить ваш счет за облако. Это то, куда они могут пойти дальше. Если произошла утечка токена AWS IAM с чрезмерными правами доступа, что может обнаружить злоумышленник в пакетах S3 или базах данных, к которым он предоставляет доступ? Может ли этот злоумышленник получить доступ к другому исходному коду и повредить что-то, что будет доставлено многим другим?
Независимо от того, передаете ли вы секреты на GitHub, в PyPI, NPM или любую общедоступную коллекцию исходного кода, лучший первый шаг, когда вы обнаружите утечку секрета, - это отозвать его. Помните о крошечном промежутке между публикацией и использованием honeytoken . Как только секрет был опубликован, он, скорее всего, был скопирован. Даже если вы не обнаружили несанкционированного использования, вы должны предположить, что оно теперь у кого-то несанкционированного и злонамеренного.
Даже если ваш исходный код находится в частном репозитории, существует множество историй о злоумышленниках, получающих доступ к частным репозиториям с помощью социальной инженерии, фишинга и, конечно же, утечки секретов. Если из всего этого и можно извлечь урок, так это то, что текстовые секреты в исходном коде в конечном итоге обнаруживаются. Независимо от того, публикуются ли они случайно публично или их находит кто-то, у кого нет доступа, которого у них не должно быть, они обнаруживаются.
Подводя итог, где бы вы ни хранили или публиковали свой исходный код, будь то частный репозиторий или публичный реестр, вы должны следовать нескольким простым правилам:
- Не храните секреты в виде обычного текста в исходном коде.
- Не позволяйте тем, кто узнает секрет, отправляться в экспедицию, строго ограничивая привилегии, предоставляемые этими секретами.
- Если вы обнаружите, что раскрыли секрет, отмените его. Возможно, вам потребуется некоторое время, чтобы убедиться, что в ваших производственных системах есть новый, ранее не раскрывавшийся секрет для обеспечения непрерывности бизнеса, но отмените его как можно скорее.
- Внедряйте автоматизацию, подобную той, что предлагает GitGuardian, чтобы убедиться, что вы не полагаетесь на несовершенных людей в безупречном соблюдении лучших практик управления секретами.
