Как стать автором
Обновить

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

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

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

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

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

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

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

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

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


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


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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий