Почему ручное отслеживание open source компонентов не всегда возможно

Open source используют все. Практически в каждом проприетарном ПО, предлагаемом на рынке, можно найти open source. По разным оценкам его доля в общей кодовой базе составляет 60%-80% в 2020.

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

Open source используется и будет повсеместно использоваться разработчиками. Почему тогда некоторые компании все еще отслеживает его использование вручную?

А зачем нужно отслеживать использование open source?

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

• Перечень компонентов. Полная прозрачность open source компонентов необходима для эффективного управления ими и обеспечения соответствия политикам компании.
• Лицензии. Не все лицензии open source совместимы. Различные разрешения, требования и условия лицензий могут конфликтовать друг с другом. Единственный способ убедиться в том, что разрабатываемый продукт компании соответствует всем лицензионным требованиям используемых open source компонентов - идентифицировать и отслеживать все лицензии. Невыполнение же требований может поставить под сомнение легальность использования конечного продукта, а также затруднить регистрацию продукта в Реестре отечественного ПО.
• Уязвимости. Приложения подвергаются атакам в наибольшей степени. Если вы не отслеживаете свои компоненты с открытым исходным кодом, вы не сможете исправить известные уязвимости, потому что не будете знать, что они есть в вашем программном обеспечении.
• Исправления и обновления версий. Библиотеки с открытым исходным кодом постоянно обновляются для улучшения функциональности или исправления ошибок. Если вы не отслеживаете компоненты с открытым исходным кодом, вы не управляете их исправлениями или обновлениями версий.

Какие проблемы возникают при ручном управлении компонентами open source?

Успешному отслеживанию компонентов с открытым исходным кодом вручную препятствует несколько вещей. Во-первых, ручное отслеживание использования открытого исходного кода требует, чтобы разработчики фиксировали каждый заимствованный компонент и тут возможна ошибка вследствие человеческого фактора. Во-вторых, огромный объем компонентов с открытым исходным кодом в средней кодовой базе делает ручное отслеживание крайне затруднительным, а то и вовсе невозможным. И наконец, при ручном отслеживании компонентов с открытым исходным кодом становится невозможным применение политик в отношении open source компонентов или управления уязвимостями.

Ручное отслеживание open source и человеческий фактор

Разработчики - люди, они не всегда все делают правильно. Особенно это касается проектов с сжатыми сроками, т.е. всех проектов в наше время.

Рассмотрим такую ситуацию.

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

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

Ручное отслеживание open source компонентов не масштабируется

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

А теперь подумайте, сколько зависимостей есть у каждой библиотеки, и сколько зависимостей есть у этих зависимостей. Как можно вручную управлять всеми этими зависимостями?

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

Ручное отслеживание open source и применение политик

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

Отсутствие контроля выбора разработчиков приводит к своим рискам. Может случиться так, что несоответствующий компонент придется удалить уже после интеграции в проект, а это бесполезная трата дорогостоящего времени и разочарование разработчика.

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

Есть еще проблема сторонних поставщиков. Скажем, не весь свой программный продукт вы создавали самостоятельно. Что, если вы привлекаете стороннего разработчика для создания, скажем, мобильного приложения? Если они отслеживают использование открытого кода вручную, поверите ли вы, что они знают все, что было добавлено в код, разработанный для вас?

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

Автоматизация - лучший способ отслеживания open source

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

Если вы по-прежнему управляете open source компонентами вручную, маловероятно, что вы сможете быстро и точно ответить на эти вопросы. Но есть способ это исправить.

Решения класса Software composition analysis (SCA, анализ композиции ПО) - это инструменты, которые автоматически обеспечивают прозрачность и контроль над компонентами с открытым исходным кодом. Такие решения интегрируются с любыми инструментами сборки, работая в фоновом режиме в среде непрерывной интеграции и идентифицируя все существующие open source компоненты и зависимости. Они уведомляют о всех лицензиях и уязвимостях, и что более важно, делают это ежедневно. Это гарантирует, что о проблемах станет известно, как только они возникнут, а не в запланированный день релиза. Автоматизированное решение позволяет управлять open source без особых усилий и защитить вашу компанию.

Источник ►