Download_Link
New member
После обширного тестирования GitHub открыл в открытом доступе функцию. Любой желающий может запустить сканер на собственном репозитории и найти уязвимости до того, как они пойдут в продакшн. Сканер действует для репозиториев на C, C++, C#, JavaScript, TypeScript, Python и Go.
Сканер основан на технологии CodeQL, которую разработала компания Semmle,. CodeQL считается первым в мире сканером на уязвимости. В мае 2020 года началось бета-тестирование на GitHub. Теперь функция доступна для всех.
Как включить
Сканирование запускается со вкладкиSecurityв репозитории.
Там нажимаемSet up code scanning.
В следующем окне нужно выбратьworkflow, который мы хотим использовать для сканирования. Дело в том, что CodeQL поддерживает подключение сторонних движков. Для стандартного движка выбираем «Анализ CodeQL».
В принципе, данныйworkflowможно настроить: включить сканирование по расписанию, сканирование на каждыйpushили пул-реквест, использовать собственный конфигурационный файл,при сканировании.
Затем нажимаем кнопкуStart commitи пишем название для нового коммита.
Выбираем коммит в главную ветку или создать новую ветку и запустить пул-реквест.
Это всё. В конце нажимаем кнопкуCommit new fileилиPropose new file.
После указания коммита сканер уязвимостей будет анализировать ваш код в соответствии с частотой, указанной в файлеworkflow.
После активации CodeQL можно смотреть результаты и.
Движок CodeQL
Движок CodeQL ищет потенциальные уязвимости по словарю из более 2000 запросов. Словарь составлен GitHub и сообществом пользователей, которые тестировали систему. Эта база будет постоянно пополняться, да и каждый может дополнить её в индивидуальном порядке, просто отредактировав конфигурационный файл.
Инструмент сканирования построен по стандарту статического анализа кода(OASIS Static Analysis Results Interchange Format) и поддерживает подключение сторонних движков, которые будут работать в едином интерфейсе. Также поддерживается экспорт результатов через единые API.
С момента представления в мае 2020 года отсканировано более 12000 репозиториев (всего 1,4млн проходов) и найдено более 20000 проблем безопасности, включая уязвимости удалённого исполнения кода (RCE), SQL-инъекции и межсайтовый скриптинг (XSS).
Разработчики и мейнтейнеры исправили 72% найденных уязвимостей в течение 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 и др.) доступны только в платном варианте.
В теории автоматическая проверка всех репозиториев— это хорошее дело, но на практике не очень приятно постоянно отвлекаться на сообщения о ложных «уязвимостях», особенно в dev-репозиториях или устаревших архивах, которые никогда не пойдут в продакшн. Такое очень быстро надоедает. Некоторые авторы, что в их собственном кодебольшинствоуязвимостей— на самом деле шум или не применимо в конкретном случае.Впрочем, в эту бочку мёда нужно добавить ложку дёгтя. Некоторые авторы опенсорсных программ жалуются (,), что сканирование даёт слишком много ложноположительных срабатываний.
То есть сканер GitHub может вызвать все симптомы состояния, известного как «усталость от безопасности» (security fatigue). Подробнее об этом состоянии см. в(doi: 10.1109/MITP.2016.84). Там говорится, что это состояние у человека подкрепляет его нежелание следовать рекомендациям по безопасности и влияет на общий анализ выгоды и затрат.
Сканер основан на технологии CodeQL, которую разработала компания Semmle,. CodeQL считается первым в мире сканером на уязвимости. В мае 2020 года началось бета-тестирование на GitHub. Теперь функция доступна для всех.
Как включить
Сканирование запускается со вкладкиSecurityв репозитории.
Там нажимаемSet up code scanning.
В следующем окне нужно выбратьworkflow, который мы хотим использовать для сканирования. Дело в том, что CodeQL поддерживает подключение сторонних движков. Для стандартного движка выбираем «Анализ CodeQL».
В принципе, данныйworkflowможно настроить: включить сканирование по расписанию, сканирование на каждыйpushили пул-реквест, использовать собственный конфигурационный файл,при сканировании.
Затем нажимаем кнопкуStart commitи пишем название для нового коммита.
Выбираем коммит в главную ветку или создать новую ветку и запустить пул-реквест.
Это всё. В конце нажимаем кнопкуCommit new fileилиPropose new file.
После указания коммита сканер уязвимостей будет анализировать ваш код в соответствии с частотой, указанной в файлеworkflow.
После активации CodeQL можно смотреть результаты и.
Движок CodeQL
Движок CodeQL ищет потенциальные уязвимости по словарю из более 2000 запросов. Словарь составлен GitHub и сообществом пользователей, которые тестировали систему. Эта база будет постоянно пополняться, да и каждый может дополнить её в индивидуальном порядке, просто отредактировав конфигурационный файл.
Инструмент сканирования построен по стандарту статического анализа кода(OASIS Static Analysis Results Interchange Format) и поддерживает подключение сторонних движков, которые будут работать в едином интерфейсе. Также поддерживается экспорт результатов через единые API.
С момента представления в мае 2020 года отсканировано более 12000 репозиториев (всего 1,4млн проходов) и найдено более 20000 проблем безопасности, включая уязвимости удалённого исполнения кода (RCE), SQL-инъекции и межсайтовый скриптинг (XSS).
Разработчики и мейнтейнеры исправили 72% найденных уязвимостей в течение 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 и др.) доступны только в платном варианте.
В теории автоматическая проверка всех репозиториев— это хорошее дело, но на практике не очень приятно постоянно отвлекаться на сообщения о ложных «уязвимостях», особенно в dev-репозиториях или устаревших архивах, которые никогда не пойдут в продакшн. Такое очень быстро надоедает. Некоторые авторы, что в их собственном кодебольшинствоуязвимостей— на самом деле шум или не применимо в конкретном случае.Впрочем, в эту бочку мёда нужно добавить ложку дёгтя. Некоторые авторы опенсорсных программ жалуются (,), что сканирование даёт слишком много ложноположительных срабатываний.
То есть сканер GitHub может вызвать все симптомы состояния, известного как «усталость от безопасности» (security fatigue). Подробнее об этом состоянии см. в(doi: 10.1109/MITP.2016.84). Там говорится, что это состояние у человека подкрепляет его нежелание следовать рекомендациям по безопасности и влияет на общий анализ выгоды и затрат.
