Всем привет!
Недавно завершился All Day DevOps, в котором было много интересных докладов, в том числе и по информационной безопасности. Но сегодня мы бы хотели рассказать про доклад 2019 года: An Intelligent Approach to Upgrading OSS Libraries! (второй доклад в playlist'e)
Использование open source библиотек позволяет делать поразительные вещи! Например, простейший web server на Java (Spring), который скажет нам «Hello world!» занимает всего 10 строк кода. Однако, всегда есть некоторая «невидимая часть», которая заключается в том, что для реализации нашего простого «Hello world!» необходимо 36 библиотек.
Какие из них уязвимы? Как можно устранить уязвимости с минимально необходимыми усилиями, за что браться «в первую очередь»?
На первый вопрос помогут ответить решения класса SCA (software composition analysis), такие как Nexus IQ, WhiteSource, Black Duck, Snyk, Checkmarx OSA и другие. А что делать со вторым вопросом?
Есть несколько «традиционных» подходов к решению этой задачи:
🍭 Подход №1: Приоритизация критичности приложений с последующим уточнением количества уязвимостей в рассматриваемых приложениях («Это приложение для нас критично и в нем не так много уязвимостей, отличный вариант для начала!»)
🍭 Подход №2: Приоритизация уязвимостей в зависимости от уровня критичности и масштаба использования рассматриваемой библиотеки в Компании («Она уязвима и ее часто используют – надо устранять в первую очередь»)
Однако, оба эти подхода, хоть и работают, могут породить большое количество дополнительных задач (пример можно посмотреть по ссылке на видео, time code ~ 4:55). Для решения этой проблемы ребята предложили интересный подход: Bottom Up, для реализации которого необходимо:
🍭 Идентифицировать все внутренние проекты, которые не зависят от иных внутренних проектов (а значит, зависят только от one source компонент)
🍭 Обновить уязвимые open source компоненты для множества проектов, идентифицированных на предыдущем этапе
🍭 Идентифицировать внутренние проекты, которые ссылаются на недавно обновленные проекты
🍭 Обновить множество проектов, идентифицированных на предыдущем этапе
🍭 Повторять, пока не будет достигнут «корень дерева»
С точки зрения авторов такой подход является оптимальным, т.к. он не порождает дополнительных задач и позволяет сформировать backlog по устранению уязвимостей.
Кроме проработки концепта ребята разработали утилиту, которая позволяет расставлять приоритеты устранения уязвимостей на основе вышеуказанного подхода – Ariadne.
Недавно завершился All Day DevOps, в котором было много интересных докладов, в том числе и по информационной безопасности. Но сегодня мы бы хотели рассказать про доклад 2019 года: An Intelligent Approach to Upgrading OSS Libraries! (второй доклад в playlist'e)
Использование open source библиотек позволяет делать поразительные вещи! Например, простейший web server на Java (Spring), который скажет нам «Hello world!» занимает всего 10 строк кода. Однако, всегда есть некоторая «невидимая часть», которая заключается в том, что для реализации нашего простого «Hello world!» необходимо 36 библиотек.
Какие из них уязвимы? Как можно устранить уязвимости с минимально необходимыми усилиями, за что браться «в первую очередь»?
На первый вопрос помогут ответить решения класса SCA (software composition analysis), такие как Nexus IQ, WhiteSource, Black Duck, Snyk, Checkmarx OSA и другие. А что делать со вторым вопросом?
Есть несколько «традиционных» подходов к решению этой задачи:
🍭 Подход №1: Приоритизация критичности приложений с последующим уточнением количества уязвимостей в рассматриваемых приложениях («Это приложение для нас критично и в нем не так много уязвимостей, отличный вариант для начала!»)
🍭 Подход №2: Приоритизация уязвимостей в зависимости от уровня критичности и масштаба использования рассматриваемой библиотеки в Компании («Она уязвима и ее часто используют – надо устранять в первую очередь»)
Однако, оба эти подхода, хоть и работают, могут породить большое количество дополнительных задач (пример можно посмотреть по ссылке на видео, time code ~ 4:55). Для решения этой проблемы ребята предложили интересный подход: Bottom Up, для реализации которого необходимо:
🍭 Идентифицировать все внутренние проекты, которые не зависят от иных внутренних проектов (а значит, зависят только от one source компонент)
🍭 Обновить уязвимые open source компоненты для множества проектов, идентифицированных на предыдущем этапе
🍭 Идентифицировать внутренние проекты, которые ссылаются на недавно обновленные проекты
🍭 Обновить множество проектов, идентифицированных на предыдущем этапе
🍭 Повторять, пока не будет достигнут «корень дерева»
С точки зрения авторов такой подход является оптимальным, т.к. он не порождает дополнительных задач и позволяет сформировать backlog по устранению уязвимостей.
Кроме проработки концепта ребята разработали утилиту, которая позволяет расставлять приоритеты устранения уязвимостей на основе вышеуказанного подхода – Ariadne.