ptsecurity Nov 21 2017 at 17:10

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

1 min

7.6K

Positive Technologies corporate blogInformation Security*

+28

Comments 8

wxmaper Nov 22 2017 at 04:29

А можно было бы встроить PVS-Studio (пускай даже как платную опцию) для анализа c++ проектов.

Finesse Nov 22 2017 at 06:22

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

Germanets Nov 22 2017 at 09:29

Неплохой такой инструмент для исследования получается: форкнул исследуемый проект — получил всю информацию об обнаруженных GitHub'ом уязвимостей…

amarao Nov 22 2017 at 12:12

Итого, явное доказательство, что вендоринг библиотек с локом по first use, которым так гордятся рубисты — это at expense of security. Гем залочили, ничего не ломается. А что там уязвимость? Ну уязвила и пофигу. Не разработчика же, и то хорошо.

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

NickKolok Nov 22 2017 at 14:44

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

amarao Nov 22 2017 at 15:10

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

NickKolok Nov 22 2017 at 15:50

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

Mingun Nov 22 2017 at 19:35

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

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

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