GitHub предупредит разработчиков об уязвимостях в их проектах



    Платформа для разработчиков запустила функцию под названием Dependency Graph, которая оповещает разработчиков в том случае, если их код содержит известные уязвимости. Система анализирует зависимости и модули, использующиеся в проекте, и выводит информацию о содержащихся в них ошибках безопасности. Инициатива направлена на повышение уровня безопасности проектов с открытым исходным кодом.

    В настоящий момент поддерживаются только языки программирования JavaScript и Ruby, однако в скором времени создатели GitHub обещают добавить Python.

    Автоматические оповещения будут получать администраторы проектов на GitHub, которые затем могут оповещать отдельные команды или конкретных разработчиков. В тексте оповещения будет содержаться название зависимости с уязвимостью и рекомендации по ее обновлению. Механизм оповещения использует технологии машинного обучения.

    image

    Оповещения будут касаться главным образом уязвимостей, которым присвоены идентификаторы CVE, однако по словам представителей GitHub, что в некоторых случаях будет выводиться и данные о публично разглашенных уязвимостях без присвоенного CVE.

    Существуют и другие инструменты выявления уязвимостей в коде программных продуктов. Например, бесплатный облачный сканер PT BlackBox Scanner позволяет находить ошибки безопасности на веб-сайтах. Кроме того, для поиска уязвимостей эффективны анализаторы защищенности исходного кода приложений — например, продукт PT Application Inspector работает со множеством платформ и языков, включая PHP, Java, .NET, HTML и SQL, а также со всеми типами уязвимостей приложений, включая SQLi, XSS и XXE.
    • +28
    • 6,4k
    • 8
    Positive Technologies 303,14
    Компания
    Поделиться публикацией
    Комментарии 8
    • 0
      А можно было бы встроить PVS-Studio (пускай даже как платную опцию) для анализа c++ проектов.
      • +5

        На GitHub анализаторы не встраиваются в GitHub, а хостятся сами и взаимодействуют с GitHub через API. На GitHub есть каталог всяких анализаторов и прочих помощников для репозиториев. Хорошая идея для PVS-Studio распространять свой продукт как SaaS-CI-сервис через GitHub.

      • +4
        Неплохой такой инструмент для исследования получается: форкнул исследуемый проект — получил всю информацию об обнаруженных GitHub'ом уязвимостей…
        • 0
          Итого, явное доказательство, что вендоринг библиотек с локом по first use, которым так гордятся рубисты — это at expense of security. Гем залочили, ничего не ломается. А что там уязвимость? Ну уязвила и пофигу. Не разработчика же, и то хорошо.

          Вендоринг — зло. Он может работать только в условиях идеального кода, когда (случайно взятая текущая версия библиотеки) не содержит в себе критических багов.
          • 0

            Я некоторое время назад предлагал proof-of-concept библиотеки для ограничения прав доступа javascript-зависимостей.

            • 0
              Уязвимость времени установки — это один вопрос. Тут, скорее, вопрос про уязвимость времени исполнения приложения. То есть испольуземая библиотека приносит уязвимость в софт. В библиотеке баг давно поправили, а в софте — из-за вендоринга и gem.lock'а — она сохраняется неограниченно долго.
              • 0

                Предлагаемая мною paraquire — она как раз про время исполнения. Другое дело, что сейчас в npm уязвимости времени установки могут быть более актуальны.

          • +1

            Что ещё за «технологии машинного обучения»? Каким тут это вообще боком? GitHub же не сам ищет эти уязвимости, а просто использует какую-то базу (исходя из того факта, что оповещения будут присылаться для уязвимостей с присвоенными CVE, то есть, кто-то уязвимость уже нашёл и присвоил какой-то идентификатор). Это же простой запрос к API: вот тебе список проектов и их версий, ответь, есть в них какие-нибудь уязвимости? Откуда здесь машинное обучение?


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


            Ещё вопрос: что происходит, если уязвимость обнаружена в транзитивной зависимости? Оповещение будет присылаться кому: только напрямую зависимому проекту или всем по цепочке? Ведь хотя вроде в собственных зависимостях уязвимости нет, но безопасность-то нарушена!

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

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