Все еще используете сканер кода для идентификации вашего open source кода? Есть лучший способ

Известно, что open source «свободен» для использования. Почему слово «свободен» взято в кавычки? Полагаю, что многие компании уже пришли к пониманию, что open source можно свободно использовать, модифицировать, распространять, но при условии выполнения требований лицензии, под которой выпущен тот или иной компонент.

Сегодня многие компании уже узнали о юридических требованиях лицензий open source благодаря аудиту open source. Потребность в таком аудите возникает при прохождении процедур M&A, IPO или новых раундов инвестирования, когда требуется отчет о сторонних open source компонентах, содержащихся в проприетарном ПО. Другими словами, в компании такой аудит может быть инициирован разными командами – юридическими департаментами, специалистами по комплайнсу и по безопасности.

Ручной сбор этой информации может потребовать много времени, особенно если в вашем продукте использовано множество open source компонентов. Доля open source в кодовой базе может составлять до 60-80%, что еще больше указывает на необходимость и ценность контроля и управления компонентами open source с самого начала.                                           

Еще три года назад большинство компаний периодически запускали инструменты сканирования open source, чтобы быть уверенными в том, что они выполняют все правовые нормы в отношении использования открытого кода. Но в последние годы на рынке наблюдаются значительные изменения, большинство сканеров кода open source либо изменили свои подходы, либо полностью потеряли своих клиентов.

Как все начиналось

Чтобы помочь компаниям с аудитом open source, в 2002 году стартап Black Duck Software представил на рынке первое решение для сканирования open source. Это решение идентифицировало компоненты с открытым кодом, а также предоставляло информацию об их лицензиях. Вскоре после этого подобные решения выпустили еще несколько вендоров, включая Protecode, Palamida и Open Logic. В общих словах, эти сканеры могли сканировать код и идентифицировать фрагменты кода («сниппеты»), которые напоминали код, появляющийся в open source компонентах. Пользователи получали уведомление о схожести кода и должны были вручную просмотреть такой фрагмент.

Поначалу казалось, что сканеры с открытым исходным кодом произвели революцию среди методов мониторинга и управления инвентаризацией open source.

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

3 основных недостатка методов управления лицензиями и безопасностью open source

Вместо того, чтобы облегчить управление open source, такие сканеры принесли лишние хлопоты. Мы выделили 3 основных недостатка таких решений.

Недостаток №1: бесконечные ложные срабатывания

Одной из основных проблем, возникающих при использовании сканера open source, является большое количество ложноположительных уведомлений. Кажется, что найдены совпадающие сниппеты, но при более близком рассмотрении, этот фрагмент не является частью open source компонента. Эти ложноположительные результаты будут отмечены сканером кода, а затем вычеркнуты командой разработчиков.

Можно сказать, что нет ничего страшного в небольшом количестве ложных срабатываний, пока большая часть проверки выполнена правильно. Правда в том, что этими ложными срабатываниями можно управлять только при условии ограниченного использования open source компонентов в вашем продукте. Однако, в последние годы, количество open source компонентов значительно выросло – только в нашей базе мы говорим сегодня о более чем 155 миллионов проектов (как в двоичном, так и в исходном виде) на таких языках как Java, Ruby и Python и еще 11 миллиардов проектов на таких языках как C/C++, Javascript, PHP и ObjectiveC. При таком большом количестве доступных компонентов совпадающие фрагменты будут гарантированно. И когда мы говорим "гарантированно", мы имеем в виду тысячи (это не преувеличение).

«Просеивание» этих ложных срабатываний может быть очень утомительной и трудоемкой работой – работой, времени на которую не хватает, особенно в дни, предшествующие релизу, или в ходе due dilligence проверки при слиянии и поглощении.

Недостаток №2: agile-методология разработки? Не в случае с использованием сканера кода

Недостаток №1 четко подчеркивает трудоемкость процесса сканирования кода. При этом заблуждение №2 высвечивает невозможность проведения сканирования не непрерывной основе. В наши дни команды разработчиков все больше и больше стараются повысить гибкость разработки, чаще выпуская новые версии и в более сжатые сроки. Однако, этот ускоренный шаг часто притормаживается сканерами open source. Процессы автоматического сканирования могут продолжаться недели, после чего наступает очередь недостатка №1 (чрезмерное количество ложных срабатываний). Даже если ваша компания использует каскадную модель разработки, все равно могут возникнуть значительные отставания от графика релиза.

Давайте представим, вам хватило терпения дождаться окончания сканирования кода, это произошло как раз перед релизом. Что делать, если окажется, что в вашем продукте был использован open source компонент с лицензией, которая не соответствует политике вашей компании. Если использован компонент с серьезной уязвимостью? Эти запоздалые результаты могут негативно повлиять на ваши сроки, так как потребуется сфокусироваться на удалении проблемного компоненты, что занимает часто много времени.

Недостаток №3: при наличии уязвимостей нужно действовать быстро

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

Если не сканеры open source, то что?

Сканеры open source были хорошими решениями в свое время, но в условиях быстрого роста количества open source компонентов и их использования в программных продуктах, а также гибкости и скорости разработки они не оправдывают возложенные на них ожидания.   

Правильное управление компонентами с открытым исходным кодом не обязательно должно быть таким хлопотным. Уже давно появились новые решения, которые представляют собой эффективный, экономящий время и, что наиболее важно, непрерывный подход к управлению open source компонентами. Первое решение для управления open source для agile-компаний было представлено компанией WhiteSource еще в 2011 году. Решение WhiteSource способно полностью интегрироваться в SDLC и вычислять сигнатуры компонентов open source в репозиториях и сборках без необходимости построчного сканирования кода. Эти сигнатуры затем сопоставляются с обширной базой данных WhiteSource, чтобы идентифицировать все ваши open source компоненты, включая все зависимости, и предоставить аналитическую и практическую информацию о лицензиях, уязвимостях безопасности, новых версиях и проблемах качества.

Вскоре после того, как WhiteSource стала пионером этого нового подхода, ряд других компаний последовали этому примеру, осознав огромные преимущества этой технологии. Ушли в прошлое дни тысяч ложных срабатываний, длительных периодов сканирования и угроз, связанных с уязвимостями безопасности.

Мы подытожили преимущества этого решения на изображении ниже:

Время двигаться вперед к agile-управлению компонентами open source

Пришло время признать, что время сканеров open source кода прошло, и двигаться дальше к новым инструментам анализа состава ПО, разработанным для управления open source с самых ранних этапов разработки.

В современных условиях agile-разработки нельзя просто полагаться на сканеры кода. И даже для тех, кто все еще следует каскадной модели, использование нового инструмента приведет к снижению усилий со стороны разработчиков и DevOps, экономя время и предоставляя больше возможностей. Как сказал однажды Сенека, каждое новое начало происходит от какого-то конца начала…

Источник ►