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




    Движок 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), что сканирование даёт слишком много ложноположительных срабатываний.


    В теории автоматическая проверка всех репозиториев — это хорошее дело, но на практике не очень приятно постоянно отвлекаться на сообщения о ложных «уязвимостях», особенно в dev-репозиториях или устаревших архивах, которые никогда не пойдут в продакшн. Такое очень быстро надоедает. Некоторые авторы говорят, что в их собственном коде большинство уязвимостей — на самом деле шум или не применимо в конкретном случае.

    То есть сканер GitHub может вызвать все симптомы состояния, известного как «усталость от безопасности» (security fatigue). Подробнее об этом состоянии см. в научной статье (doi: 10.1109/MITP.2016.84). Там говорится, что это состояние у человека подкрепляет его нежелание следовать рекомендациям по безопасности и влияет на общий анализ выгоды и затрат.
    Дата-центр «Миран»
    Решения для аренды и размещения ИТ-инфраструктуры

    Комментарии 14

      0
      Насколько я понимаю данный анализ способен найти только структурные уязвимости путём матчинга вашего кода на основе предопределенных паттернов?
      И если это так, то данный инструмент будет выдавать большое количество False positive уязвимостей.
        0
        payload = {
        "username": "username",
        "password": "password",
        "sid": "f4cd64c990eb89e7c38b6975762808dc",
        "redirect":"index.php",
        "mode": "login",
        "login": "Вход"
        }

        Съел и не поморщился. А по идее, он на секреты должен агрессивно срабатывать.
          0

          Для C/C++ пока он бесполезен чуть более, чем полностью. А была надежда что хотя бы до среднего статического анализатора подтянут к запуску.

            +1
            Та не было надежды. Это ж надо было или покупать какой-то толковый стат.анализатор или вкладываться в адаптацию бесплатного. И кто это будет финансировать для бесплатных юзеров? Я ещё поверю в это как в фишку для платных аккаунтов, но там кто хотел — уже всё себе и так купил и настроил.
              +1

              У них самая большая база кода (github) и самая большая база данных об ошибках (issues / pull requests). Дело в технологии, а не в цене или рынке.

                0
                Дело всегда в цене и рынке.
                  0
                  У них нет по сути базы об ошибках.
                  Пул реквесты? А о чем они? Как их разбирать автоматически?
                    0
                    Если PR упоминает issue, это хороший признак. Плюс вполне можно классифицировать это фича или маленький багфикс. Особенно когда прицепом идёт regression test.

                    Вся информация у них есть, но вопрос в том научились ли они с ней работать. Если бы это было так просто, то давно бы кто-то сделал. Вот, похоже, они пока тоже не научились. Я уверен что со временем натренируют свою модель так, что будет конкуренция другим тулам.

                    Смотреть на это надо так — может ли человек за безлимитное время смотря на текущий снапшот github'а научиться искать баги? Я думаю может. Значит вопрос в том как научить это делать машину вполне себе вопрос времени.
                      0
                      Что для одного проекта баг, для другого фича :) Простейшую классификацию сделать можно, но не думаю что с текущим уровнем развития технологий возможно сделать адекватного конкурента SAST с помощью ML
            0
            Подскажите название шрифта, пожалуйста.
              –1
              Если честно, я в небольшом недоумении. Вроде бы хорошее начинание, но что-то не так. Казалось бы, поиск по базе паттернов известных уязвимостей должен давать почти стопроцентное попадание. Это же как антивирус. Известен фрагмент кода, вызывающий уязвимость. И надо его просто найти. Да, как и антивирус, это будет давать иногда ложные срабатывания. Но не понятно, почему их уже так много. Видимо, фрагменты для поиска слишком малы и под них попадает много нормального кода. В общем как-то не туда пошло… Это ведь только начало. И чем больше будет пополнять база, тем больше будет ложных срабатываний…

              Ну и да, не забывайте помимо поиска известных ляпов, проводить классический статический анализ для поиска дефектов безопасности (SAST). Наш анализатор PVS-Studio уже умеет для этого работать в режиме классификации предупреждений согласно CWE, CERT и скоро добавим OWASP.

                0
                Потому что помимо паттернов нужен дата флоу анализ по крайней мере.
                Кроме того с паттернами не всегда всё однозначно.
                Вот например в Го все типы имеют дефолтное значение.
                В коде разработчик создаёт структуру http.Cookie
                httpCookie := &http.Cookie{}
                в этот момент все поля устанавливаются в дефолтные значения.
                Далее этот разработчик устанавливает отдельно уже поля, в частности поле HttpOnly:
                httpCookie.HttpOnly = true
                Это важно потому что усложняет XSS атаку с воровством session id. CWE-1004

                Но как относиться анализатору к дефолтному значению? Действительно ли там есть уязвимость? Нет потому что дальше поле устанавливается в правильное значение. Фолс позитив? Ну не совсем.

                Наш анализатор рекламировать не буду :)

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое