Журнал "Information Security/ Информационная безопасность" #1, 2020

1. DevOps, контейнеры на основе Linux и т.д. привели к значительному росту исполь- зования Open Source при разработке. 2. Как и коммерческое ПО, открытый исходный код содержит уязвимости. Недостаток данных о том, как и какие компоненты используются, привел к тому, что компании неосознанно под- вергаются значительному риску. 3. Отсутствие полной информации, политик или процессов управления ком- понентами Open Source привели к тому, что проверка на уязвимости проводится от случая к случаю (или вообще отсут- ствует), а при публикации информации о найденной уязвимости для исправле- ния затрачиваются большие усилия. 4. Зрелые компании расширяют свои возможности по управлению Open Source и проводят анализ работоспо- собности всей программы на основе происхождения конкретного компонента и его поддержки. 5. Те, кто профессионально занимают- ся взломами ИТ-систем, нацеливаются на репозитории компонентов с открытым кодом и инфицируют их, обеспечивая попадание вредоносного кода на раннем звене цепочки поставки ПО. Развитый функционал для поиска уязвимых компонентов Со временем системы проверки Open Source переродились в инструменты непрерывного управления компонентами Open Source, интегрируемыми с раз- личными инструментами разработки – репозиториями, инструментами сборки, серверами непрерывной интеграции. Переход к обнаружению уязвимостей и проблем с лицензированием в режиме реального времени позволил управлять открытым исходным кодом и идентифи- цировать проблемы на более ранних этапах процесса, когда их легче и быстрее устранить. Функционал подобных инструментов довольно широк. Инструменты анализа композиции приложения проводят инвен- таризацию всех компонентов Open Source в приложении, включая прямые и транзитивные зависимости, и предо- ставляют информацию о каждом ком- поненте, в том числе данные о лицензии и наличии уязвимостей. Инструменты с наиболее развитым функционалом, в частности WhiteSource, способны снизить число уведомлений об уязвимостях в компонентах Open Source на 70% благодаря запатентован- ным алгоритмам приоритизации по фак- тическим вызовам уязвимых методов. WhiteSource агрегирует информацию об уязвимостях из разных источников в собственную базу данных и предлагает разработчикам на выбор варианты исправления, от ссылок на обновления до рекомендаций по изменению систем- ных настроек и блокировки различных функций. Крылатое выражение "время – деньги" как нельзя лучше характеризует ситуа- цию с разработкой ПО. От разработчи- ков требуют нереальных, на первый взгляд, вещей: сделать продукт быстро и при этом чтобы он получился безопас- ным. В таких условиях не обойтись без автоматизации. WhiteSource может авто- матизировать весь процесс отбора, утверждения и отслеживания компонен- тов Open Source, автоматически приме- нять политики для блокировки уязвимого или проблемного компонента. Лицензионная чистота Использование Open Source подни- мает еще один вопрос, требующий вни- мания команды разработки, – о лицен- зионной чистоте. Каждый компонент Open Source, а также любой компонент, от которого он может зависеть, имеет лицензию, условия которой нужно соблюдать. Существует свыше 200 раз- личных лицензий Open Source, у каждой из которых свои условия. Выбор компо- нента с неподходящей лицензией может привести к самым разным последствиям, от необходимости изменения компонента до судебного иска о нарушении автор- ских прав. SCA-решение также призвано автоматизировать процесс соблюдения лицензионной чистоты, чтобы освобо- дить разработчиков от несвойственных им задач. Полный контроль на всех этапах Сообщество разработчиков Open Source выполняет грандиозную работу в части безопасности проектов, обнару- живая уязвимости и предлагая исправ- ления, но Open Source децентрализован по своей природе. Информация об уязви- мостях компонентов публикуется на раз- ных ресурсах, и просто невозможно вручную сопоставлять уязвимые компо- ненты с используемыми в своей разра- ботке. WhiteSource на всех этапах SDLC, от выбора компонентов с открытым кодом до мониторинга релизов в экс- плуатации, позволяет отслеживать уязвимости и лицензионные соглашения Open Source. l • 45 РАЗРАБОТКА www.itsec.ru Три способа проверки на уязвимость: 1. Проверка кода без его выполнения. 2. Проверка поведения программы без сканирования исходного кода. 3. Проверка архитектуры и логики. Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты. Ваше мнение и вопросы присылайте по адресу is@groteck.ru Реклама