Одним из рисков цепочки поставок программного обеспечения является утечка секретов. Цепочка поставок программного обеспечения окружена секретами; разработчикам и конвейерам CI\CD необходимо использовать секреты для доступа к SCM, конвейеру, реестрам артефактов, облачным средам и внешним службам. А когда секреты повсюду, то когда они утекут, это вопрос времени.
Этот риск хорошо известен, и многие структуры цепочки поставок программного обеспечения решают его, требуя сканирования секретов и самоистязания секретов.
Итак, что может пойти не так, если вы, как специалист по безопасности, установили эти ограждения?
На этой неделе, исследуя секретные инструменты сканирования, я наткнулся на один ответ. Ответ прост: поскольку сканеры секретов ищут шаблоны секретов, при изменении формата секрета обнаружение может потерпеть неудачу. И это именно то, что произошло, когда GitHub представил новую функцию безопасности — мелкозернистые токены. Эта бета-функция — один из способов GitHub снизить риски утечки секретов; ограничение разрешений токенов личного доступа также ограничивает риски, если бы эти секреты были раскрыты.
Оказывается, формат новых токенов немного другой, а формат старых токенов был примерно такой:
ghp_123456789012345678901234567890123456
Новый формат токена выглядит следующим образом:
github_pat_123456789012345678901234567890123456789012345678901234567890…
И префикс, и длина секрета различны.
И действительно, некоторые секретные сканеры не могут обнаружить новый формат;
Для эксперимента я создал репозиторий с Dockerfile с секретом и рабочим процессом, запускающим действие Trivy. Вот как выглядит Dockerfile в начале эксперимента:
Ниже приведен снимок сканера секретов GitHub, который обнаруживает вновь отформатированный секрет:
Как мы видим, секретный сканер GitHub обнаруживает секрет, но в разделе «Сканирование кода» никаких предупреждений не появляется.
Чтобы убедиться, что инструменты настроены правильно, я добавлю классический секрет в файл Dockerfile (см. ниже) и снова запущу сканирование. Теперь мы получаем оповещение о сканировании кода (только на классическом секрете!)
Сканер Github, с другой стороны, теперь обнаруживает два секрета:
Я открыл вопрос безопасности для Триви; Команда Триви ответила, что это не уязвимость и не проблема безопасности. Осталось открыть тему.
Этот эксперимент вызывает много опасений;
- Почему пользователь GitHub должен подозревать, что формат токена будет изменен из-за новой функции?
- Учитывая, что секреты должны выглядеть как случайные строки, почему пользователь GitHub вообще должен заботиться о формате секретов?
- Должен ли GitHub нести ответственность за информирование своих клиентов о таких изменениях?
- Является ли этот сбой при обнаружении секрета уязвимостью мелких секретов GitHub, уязвимостью Trivy или, по мнению Aqua Security, вообще не уязвимостью?
- Должна ли компания Aqua Security, стоящая за Trivy, нести ответственность за его обновление?
- Поскольку Trivy — это проект с открытым исходным кодом, поставляемый «как есть», будет ли кто-нибудь нести ответственность, если секреты утекут из конвейера, защищенного Trivy? Кто бы это был? Гитхаб? Аква Секьюрити? Пользователь Триви?
- Чему этот эксперимент учит нас о доверии к инструментам безопасности, установленным для защиты цепочек поставок программного обеспечения?
Я оставлю эти вопросы открытыми.
Однако ясно одно; Защита цепочки поставок программного обеспечения сложна, и нам нужно высокопрофессиональное сообщество, чтобы добиться успеха в решении этой задачи.
Соавтором этого сообщения является Ави Ваксман, стажер Scribe Security
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
