Опасность зависимости от сторонних кодов

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

Каждый раз, когда вы видите небольшую ссылку внизу веб-страницы с надписью «Powered by So-And-So», вы становитесь свидетелями этого совместного эффекта в действии.

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

1. Потенциальные угрозы безопасности

Поскольку почти весь код, который управляет чем-либо в Интернете, имеет открытый исходный код, можно поспорить, что если в каком-либо приложении есть какая-либо вредоносная полезная нагрузка, она будет быстро обнаружена сообществом разработчиков и быстро исправлена.

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

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

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

2. Вам не принадлежит это

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

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

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

3. Вы часто получаете гораздо больше, чем вам нужно

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

4. Несколько уровней зависимости от третьей стороны могут привести к реальным проблемам

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

Каждая цепочка так же сильна, как и ее самое слабое звено. Эта цепочка зависимостей означает, что, если какое-либо звено в любом месте цепочки будет разорвано или скомпрометировано, вся цепочка подвергается риску сбоя. В некоторых ситуациях это может быть довольно дорого. Никто бы не заподозрил мощь, заложенную в строках кода 11, содержащихся в этой мягкой маленькой функции под названием Left-Pad, но когда эта конкретная цепная ссылка перестала работать, это привело к остановке многих крупных веб-сайтов. Основная часть этого заключалась в том, что большинство людей, которые использовали Left-Pad, не знали, что они его используют, что он делает или как решить проблему. Как указано в пункте 2, если вы не владеете им, вы не обязательно понимаете это.

Left-Pad была очень простой функцией, которая просто добавляла несколько пробелов в левую часть строки, чтобы убедиться, что линия имеет правильную длину. Теперь проблема в том, что любой компетентный программист может легко воспроизвести эту функциональность. Абсолютно не нужно, чтобы какое-либо приложение зависело от этой сторонней функции, и все же тысячи веб-сайтов использовали программное обеспечение, которое включало его, включая Netflix, Facebook и Reddit. Это была просто удача, что в данном случае это была очень простая функция, которая разорвала цепочку, а не какая-то действительно сложная функция, которая имела свою собственную цепочку зависимостей.

Суть в том, что если вы можете построить это самостоятельно, то, вероятно, должны!

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

Чтобы упростить процесс принятия решения, вероятно, помогут следующие условия тестирования.

Если любой из этих факторов верен:

  • функция, которую вы хотите, проста
  • у вас (или вашей команды) есть возможность создать функцию
  • есть много времени для создания функции
  • ваше приложение нуждается в хорошей безопасности
  • у вас есть опасения по поводу потенциальных юридических проблем, связанных с лицензированием третьей стороной
  • важно, чтобы ваше приложение никогда не выходило из строя

Затем вы должны построить его самостоятельно,

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

изображение заголовка любезно предоставлено Стефани Такер

Богдан Рэнца

Богдан является одним из основателей Inspired Mag, накопив за этот период почти 6-летний опыт. В свободное время он любит изучать классическую музыку и изучать изобразительное искусство. Он тоже одержим исправлениями. У него уже есть 5.