Не будьте индейкой — 5 распространенных ошибок, которые ваши разработчики совершают, используя открытый исходный код
Благодарение на нас!
Наполненный едой, семьей и, надеюсь, немного футбола — поехали в «Сихокс» — День Благодарения — это время, когда семьи собираются и говорят о том, за что они благодарны.
Здесь, в WhiteSource, мы благодарны за все усилия, которые прилагает сообщество открытого исходного кода, чтобы помочь другим быстрее создавать инновационные продукты, экономя всем время и деньги. Однако больше всего мы благодарны разработчикам, которые сделали все это возможным. Я говорю о парнях и девушках, которые работают день и ночь, чтобы добавить строки кода в ваши приложения и веб-сайты.
К сожалению, команды программистов в современном технически подкованном мире никогда не получают должного признания, которого они заслуживают, часто затмевая продукты, привлекающие все внимание.
Поэтому в этом году мы выражаем благодарность этой редкой породе хороших талантов за то, что они помогли нам развиваться более инновационно в будущем. Ты знаешь кто ты есть.
Мы также понимаем, что даже лучшие иногда совершают глупые ошибки. Даже в «умных» средах разработки, которые помогают выявлять проблемы на ранней стадии, некоторые проблемы все равно будут проскальзывать, мешая работе вашей команды.
В надежде избавить вас от небольшого смущения в наступающем году, мы решили выделить 5 наиболее распространенных ошибок, которые допускают ваши разработчики при использовании открытого исходного кода.
#1 Скопируйте и вставьте открытый исходный код
Несомненно, самая распространенная ошибка разработчиков с открытым исходным кодом заключается в том, что они копируют и вставляют код, не замечая, сколько дополнительного нежелательного кода они только что добавили в свою среду.
Билл Сурур утверждает, что копирование и вставка фрагментов кода из таких источников, как Google, Github и StackOverflow, — это нормально, если вы понимаете, как они работают. Однако ту же логику нельзя применить к открытому исходному коду.
Чтобы предотвратить эту распространенную ошибку, ваши разработчики должны иметь четкое представление о том, какой код необходим при копировании и вставке открытого исходного кода в ваше приложение, а от чего следует отказаться.
узнайте, как выбрать решение с открытым исходным кодом, которое соответствует вашим потребностям!
#2 Безопасность в течение всего дня каждый день
Когда люди думают об использовании открытого исходного кода, один из первых вопросов, который приходит на ум, звучит так: «Если он открыт, насколько он может быть безопасным?»
В то время как некоторые люди утверждают, что закрытое или коммерческое программное обеспечение выглядит более безопасным на бумаге, открытый исходный код представляет собой сценарий широко открытых дверей. Это означает, что чем больше просмотров кода сообществом, тем выше безопасность. Напротив, закрытый код используется в меньшем количестве проектов, но может иметь критические уязвимости, которые остаются незамеченными в течение длительного времени, ожидая, пока хакер придет и покопается, чтобы обнаружить дыры в их безопасности.
Когда дело доходит до использования открытого исходного кода, ваши разработчики должны понимать потенциальные риски безопасности в своем коде, которые могут возникнуть при использовании библиотек с известными уязвимостями. Это также означает знание того, какие части открытого исходного кода есть в ваших продуктах, и уверенность в том, что вы используете только безопасные версии.
#3 Не забудьте обновить
Итак, вы провели исследование и выбрали наиболее подходящий компонент с открытым исходным кодом для вашего продукта.
Здорово. Теперь вы должны убедиться, что он остается в актуальном состоянии.
Часто новые версии предлагают новые функции, исправляют обнаруженные ошибки программного обеспечения / уязвимости безопасности или добавляют совместимость с другими проектами с открытым исходным кодом. Эти версии являются результатом совместной работы сообщества открытого исходного кода для создания лучшего кода. Но вы не сможете извлечь из этого пользу, не обновив свои версии. Помимо фактора «новый и блестящий», новые версии содержат важные исправления для уязвимостей безопасности, помогая вам защитить ваш продукт.
Если вы не обновите эти версии, вы подвергнете свою компанию значительному риску, поскольку хакеры могут увидеть те же уязвимости и попытаться их использовать. Все, что им нужно сделать, — это найти недавно опубликованные уязвимости и опробовать их в организациях, которые слишком медленно обновляются. Другая угроза исходит от хакеров, сравнивающих старую версию с новой, выбирая, что было исправлено, и точно зная, на что нацелиться.
Взломы случаются, но не используйте их только потому, что вы не обновились.
#4 Могу ли я использовать эту лицензию?
Использование открытого исходного кода действительно может значительно облегчить жизнь вашим разработчикам, но иногда также может создать огромную головную боль. Это особенно верно, когда речь идет о юридической команде вашей компании.
Еще одна распространенная ошибка, с которой обычно сталкиваются разработчики, — это использование лицензии с открытым исходным кодом, которая противоречит политике вашей компании. Классическим примером является общая лицензия GPL, которая создала много юридических проблем для компаний, использующих эту лицензию в своих компонентах. Одна из самых неприятных ситуаций — это когда разработчик берет библиотеку с лицензией GPL, а потом реализует ее только в конце, незадолго до релиза. Это создает трудности, чтобы вырвать его и заменить кодом, допустимым в соответствии с политиками вашей компании.
Установите четкие политики в отношении того, какие лицензии разрешены, а какие нет. Мы предлагаем также иметь систему, которая дает вам полную информацию о том, какие лицензии находятся в вашем продукте, что позволяет вам быстро отвечать на вопросы юридического отдела о том, соблюдаете ли вы требования или нет.
# 5 Зависимости
Последняя в списке, но одна из наиболее важных ошибок касается зависимостей. Разработчики обычно не обращают внимания на количество библиотек с открытым исходным кодом, которые они фактически используют из-за зависимостей. Эта проблема особенно актуальна, если они используют инструменты управления зависимостями, такие как Maven (Java), Bower (JavaScript), Bundler (Ruby) и т. д., которые автоматически подключают сторонние зависимости.
Существует два основных типа зависимостей: прямые и транзитивные. Прямые зависимости — это библиотеки, к которым обращается ваш код, а транзитивные зависимости — это библиотеки, с которыми связаны ваши зависимости — в основном, зависимости зависимостей.
Если вы не отслеживаете свои зависимости с открытым исходным кодом, вы теряете видимость и контроль над своим программным обеспечением. Если ваша команда использует открытый исходный код, как и почти любой коммерческий программный продукт на рынке, вы должны отслеживать все используемые вами библиотеки с открытым исходным кодом, включая прямые и транзитивные зависимости.
Не будь индейкой
Мы все хотим быть ниндзя, но помните, что человек никогда не может быть «идеальным», поскольку всегда есть предел погрешности.
Вопрос в том, насколько хорошо мы учимся на своих ошибках? Какие системы и инструменты мы внедряем, чтобы свести ошибки к минимуму?
Надеемся, что этот список поможет вам и вашей команде сосредоточиться на разработке в следующем году, избегая ловушек прошлого года.
Первоначально опубликовано на www.whitesourcesoftware.com 21 ноября 2017 г.
