Учетные данные, попавшие в отправленный коммит, уже утекли, даже если последующий коммит их удаляет. Система Безопасность находит учетные данные в ваших изменениях и истории, не сохраняет их и считает каждый случай открытым до тех пор, пока кто-то не подтвердит, что они были переустановлены или аннулированы.
Что сканируется
- Каждое изменение: изменения каждого pull request, в рамках проверки
Coroid Security, а также изменения собственных агентов Coroid перед их фиксацией в репозитории. - Ветка по умолчанию: каждая отправка изменений и вся её история целиком. Сканирование истории начинается при подключении репозитория или при включении функции «Утечки секретов».
- Ветки запросов на объединение: учетные данные, отправленные в ветку pull request, также вызывают обнаружение, так как они уже находятся в репозитории.
Ветка, отправленная без pull request, не сканируется.
Сканирование истории считывает каждый доступный коммит, начиная с самого нового, и каждую версию файла — один раз. Оно выполняется частями и возобновляется с того места, где остановилось. Для каждого репозитория установлены ограничения на объем сканируемой истории (количество коммитов, объем данных, время и размер файлов); при их превышении покрытие будет неполным.
Что обнаруживается
Учетные данные поставщиков в их стандартных форматах (ключи доступа AWS, токены GitHub и GitLab, ключи OpenAI и другие), токены авторизации, учетные данные, присвоенные именам вроде password или api_key, закрытые ключи, учетные данные внутри URL-адресов и длинные строки с высокой энтропией. Учетные данные в коде распознаются только если значение задано прямо, а не через переменную или вызов функции.
Coroid никогда не сохраняет значение.
Обнаруженное значение сразу передается от модуля распознавания к брокеру учетных данных Coroid, который возвращает отпечаток с ключом и удаляет само значение. Сохраняется только отпечаток. Он привязан к конкретной организации, поэтому его нельзя сравнить между организациями или угадать вручную.
Везде, где ранее отображался секрет (результаты обнаружения, проверки, комментарии к рецензированию, логи), Coroid показывает только правило, длину и местоположение, например
[redacted secret: named_credential, 40 characters]. Ни одна часть значения не отображается, даже первые символы.
Coroid никогда не пытается проверить найденные учетные данные на работоспособность.
Один учетный данные — один результат обнаружения
Учетные данные, встречающиеся в нескольких коммитах, образуют один результат обнаружения с несколькими вхождениями. Те же учетные данные в двух репозиториях — это два результата, по одному на репозиторий. При подтверждении одного из них система Безопасность покажет остальные с тем же учетными данными, чтобы можно было подтвердить их все сразу. Сама система так не поступает.
Секрет закрывается только после подтверждения
Удаление учетных данных из кода делает их вхождения невидимыми, но результат обнаружения остается открытым: те, кто видел репозиторий ранее, могли их получить. Он закрывается только после того, как владелец или администратор подтвердит предпринятые действия:
- Переустановлены или аннулированы;
- дата выполнения действия;
- необязательная примечание.
Система Безопасность фиксирует, кто и когда подтвердил, и отображает это в результате обнаружения: «Переустановлены 28 октября, подтверждено Алексом 29 октября». Результат обнаружения переходит в статус Ротация подтверждена.
Исправление утечки секретов
Создать задачу в чек-листе создает задачу в проекте со следующими шагами:
- Переустановите или аннулируйте учетные данные у поставщика.
- Переместите их туда, где проект хранит свои секреты.
- Удалите их из кода.
- Подтвердите ротацию в системе Безопасность.
Задача не повторяется и не пытается использовать учетные данные. Она не переписывает историю Git: удаление учетных данных из истории — решение вашей команды, и это не делает утекший секрет безопасным снова.
Настоящие учетные данные или не проблема
При обнаружении секрета владельцы и администраторы отвечают на вопрос Являются ли это настоящими учетными данными?
- Настоящие учетные данные оставляет результат обнаружения открытым до подтверждения.
- Не проблема фиксирует исключение ложноположительного результата, скрывающее этот результат, например для тестового фикстура. Настоящие учетные данные удаляет это исключение снова.
Эти ответы также помогают корректировать параметры модулей распознавания.
Блокировка
Функция «Утечки секретов» работает в режиме наблюдения по умолчанию. Блокировка включается только после того, как модули распознавания пройдут калибровку и будет включено принудительное применение правил. См. Защита и принудительное применение правил.
Организации, у которых ранее была включена функция сканирования секретов в политике организации, продолжают сталкиваться с её блокировкой — из-за версии используемого детектора — до тех пор, пока новые детекторы не пройдут калибровку. Поскольку предыдущее сканирование не создаёт результатов, ни исключение, ни подтверждение не могут отменить действие блокировки.
По умолчанию для организации Блокировать новые секреты и самые крупные обнаруженные изменения отображаются в разделе «Утёкшие секреты».
Уведомления
Результаты сканирования секретов пока не отправляют уведомления. Они отображаются в разделах «Безопасность» → «Результаты» и «Обзор».
GitHub сканирование секретов
Если для репозитория включено собственное сканирование секретов GitHub, система безопасности может импортировать соответствующие оповещения. Оповещение о сканировании секретов GitHub остаётся открытым до тех пор, пока кто-то не устранит проблему непосредственно в GitHub; объединение исправления в код не приводит к закрытию такого оповещения. Подробнее см. GitHub оповещения о безопасности.