GitHub запустил статический анализ кода на уязвимости
После обширного тестирования GitHub открыл в открытом доступе функцию сканирования кода на уязвимости. Любой желающий может запустить сканер на собственном репозитории и найти уязвимости до того, как они пойдут в продакшн. Сканер действует для репозиториев на C, C++, C#, JavaScript, TypeScript, Python и Go.
Сканер основан на технологии CodeQL, которую разработала компания Semmle, купленная GitHub в прошлом году. CodeQL считается первым в мире сканером на уязвимости. В мае 2020 года началось бета-тестирование на GitHub. Теперь функция доступна для всех.
Сканирование запускается со вкладки Security в репозитории.
Там нажимаем Set up code scanning.
В следующем окне нужно выбрать workflow, который мы хотим использовать для сканирования. Дело в том, что CodeQL поддерживает подключение сторонних движков. Для стандартного движка выбираем «Анализ CodeQL».
В принципе, данный workflow можно настроить: включить сканирование по расписанию, сканирование на каждый push или пул-реквест, использовать собственный конфигурационный файл, запустить дополнительные поисковые запросы при сканировании.
Затем нажимаем кнопку Start commit и пишем название для нового коммита.
Выбираем коммит в главную ветку или создать новую ветку и запустить пул-реквест.
Это всё. В конце нажимаем кнопку Commit new file или Propose new file.
После указания коммита сканер уязвимостей будет анализировать ваш код в соответствии с частотой, указанной в файле workflow.
После активации CodeQL можно смотреть результаты и изменять параметры сканирования.
Движок CodeQL ищет потенциальные уязвимости по словарю из более 2000 запросов. Словарь составлен GitHub и сообществом пользователей, которые тестировали систему. Эта база будет постоянно пополняться, да и каждый может дополнить её в индивидуальном порядке, просто отредактировав конфигурационный файл.
Инструмент сканирования построен по стандарту статического анализа кода SARIF (OASIS Static Analysis Results Interchange Format) и поддерживает подключение сторонних движков, которые будут работать в едином интерфейсе. Также поддерживается экспорт результатов через единые API.
С момента представления в мае 2020 года отсканировано более 12 000 репозиториев (всего 1,4 млн проходов) и найдено более 20 000 проблем безопасности, включая уязвимости удалённого исполнения кода (RCE), SQL-инъекции и межсайтовый скриптинг (XSS).
Разработчики и мейнтейнеры исправили 72% найденных уязвимостей в течение 30 дней после их обнаружений, до слияния кода с основной веткой. Это хороший результат, потому что по статистике менее 30% найденных уязвимостей исправляются в течение месяца после обнаружения.
По итогам бета-тестирования в опенсорсный словарь запросов сделано 132 коммита от сообщества. Чтобы пользователи GitHub могли запускать сторонние инструменты, заключены соглашения с более чем десятком разработчиков систем безопасности и опенсорсных инструментов для статического анализа, сканирования контейнеров и валидации инфраструктуры как кода (Infrastructure-as-Code; IaC) — это подход для управления и описания инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие.
Дополнительно к поиску уязвимостей GitHub также сотрудничает с 24 сторонними сервис-провайдерами, чтобы находить в коде их секреты, которые нельзя публиковать в открытом виде, такие как ключи доступа. Среди партнёров — AWS, Google Cloud, Azure, Dropbox, Slack, Discord, npm, Stripe и Twilio, Сканирование на секреты происходит автоматически и в публичных, и в приватных репозиториях.
Сканирование кода является бесплатным для публичных репозиториев и входит в пакет Advanced Security для GitHub Enterprise (то есть это платная услуга). Некоторые экзотические опции (список разрешённых IP-адресов, поддержка SAML, LDAP и др.) доступны только в платном варианте.
Впрочем, в эту бочку мёда нужно добавить ложку дёгтя. Некоторые авторы опенсорсных программ жалуются (1, 2), что сканирование даёт слишком много ложноположительных срабатываний.
Many of @snyksec’s vulnerability reports are bullshit. They classified all `execa` versions as vulnerable because it exposes `childProcess.exec ()`. Duuh. That’s kinda the point of the package. They also don’t contact maintainers before publishing their reports either. pic.twitter.com/fhvhLasNf6
— Sindre Sorhus (@sindresorhus) May 2, 2019
В теории автоматическая проверка всех репозиториев — это хорошее дело, но на практике не очень приятно постоянно отвлекаться на сообщения о ложных «уязвимостях», особенно в dev-репозиториях или устаревших архивах, которые никогда не пойдут в продакшн. Такое очень быстро надоедает. Некоторые авторы говорят, что в их собственном коде большинство уязвимостей — на самом деле шум или не применимо в конкретном случае.
То есть сканер GitHub может вызвать все симптомы состояния, известного как «усталость от безопасности» (security fatigue). Подробнее об этом состоянии см. в научной статье (doi: 10.1109/MITP.2016.84). Там говорится, что это состояние у человека подкрепляет его нежелание следовать рекомендациям по безопасности и влияет на общий анализ выгоды и затрат.
