Через 20 лет 200 миллиардов

Лори Восс, главный операционный директор и соучредитель npm (@seldo), вчера написала в Твиттере, что количество пакетов JavaScript, загруженных из их репозитория, на прошлой неделе превысило 4 миллиарда. Ежегодно это будет более 200 миллиардов загрузок. Ух ты.

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

По оценкам Лори, за загрузку отвечали 12 миллионов разработчиков. Это означает, что ежегодно каждый разработчик JavaScript загружает около 17 000 компонентов. Представьте себе, сколько времени сэкономлено за счет того, что вам не нужно кодировать каждую из этих функций с нуля, просто загрузив пакет за миллисекунду из Интернета.

Цепочки поставок программного обеспечения в действии

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

Вчера во втором твите Лори написала: «Поскольку у нас около 12 миллионов пользователей, это означает, что средний пользователь установил ровно 1000 пакетов за 7 дней. На самом деле, большинство людей устанавливали очень мало пакетов, а куча блоков сборки CI устанавливала по 10 или 100 тысяч пакетов каждый».

По сути, существует армия роботов (автоматизированных инструментов CI), загружающих миллиарды компонентов из Интернета. Хотя этот тип автоматизации эффективен, сам по себе он не приносит пользы командам.

Репозитории в помощь

В Sonatype мы видели подобное поведение разработчиков на заре Maven. Отдельные разработчики загружали компоненты Java непосредственно из Maven Central. Пользователи Maven, сидящие рядом друг с другом в одной комнате и в одной команде, неоднократно загружали одни и те же версии одних и тех же компонентов, необходимых для их сборок. Именно по этой причине, среди прочего, наши основатели изобрели менеджер репозиториев Nexus. Nexus предоставил мгновенные преимущества командам разработчиков, оптимизировав их цепочки поставок программного обеспечения. К ним относятся:

  • Кэширование. Nexus действует как локальный склад запчастей для команд разработчиков. Новые компоненты загружаются один раз и сохраняются локально. Это избавляет от необходимости загружать один и тот же пакет 1000 раз.
  • Общий доступ. Компоненты, совместно используемые локально, могут использоваться неограниченно. Разработчикам не нужно выходить в Интернет, чтобы получить свои пакеты, и команды могут начать стандартизировать общие версии, чтобы уменьшить переключение контента и технический долг.
  • Приватизация. Не все пакеты можно распространять в Интернете. Команды часто создают свои собственные пакеты, которые необходимо совместно использовать локально, но при этом они должны оставаться проприетарными. Nexus также решил эту проблему.

Хотя менеджеры репозиториев уже довольно давно используются в сообществе Java, сообщение Лори говорит нам, что внедрение технологии все еще отстает в более молодых, менее зрелых экосистемах упакованного кода.

Компании, которым нужны менеджеры репозиториев, могут обратить внимание на такие решения, как e-npm — локальную технологию, продаваемую компанией Лори исключительно для пакетов JavaScript. Для компаний с многоязычными командами разработчиков универсальные менеджеры репозиториев, такие как Nexus Repository OSS, обеспечивают полнофункциональную бесплатную поддержку npm и 12 других типов компонентов, включая контейнеры Docker. Artifactory от JFrog — еще один универсальный менеджер репозиториев, но пользователю необходимо платить за поддержку npm, а также всех других форматов пакетов, за исключением компонентов Java.

Не все компоненты одинаковы

Я часто говорил, что если у вас есть 100 разработчиков, у вас есть 100 входных дверей в вашу организацию. 1000 разработчиков? 1000 входных дверей.

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

Исследования, которые я проводил в Sonatype в предыдущие годы, показали, что 5,5% (1 из 18) компонентов, загруженных менеджерами репозиториев, имели известные уязвимости в системе безопасности. Хотя процент не очень велик, имейте в виду, что менеджер репозитория загружает компонент только один раз. После кэширования будущие загрузки этого компонента не нужны, и эта команда может бесконечно повторно использовать компоненты.

Анализ Sonatype более 40 000 репозиториев Nexus показывает, что в среднем репозиторий содержит более 1600 компонентов. Более глубокий анализ 1600 компонентов, размещенных в среднем менеджере репозитория, выявил 192 уязвимости безопасности среди компонентов (некоторые компоненты имели более одной уязвимости безопасности).

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

Понимая важность безопасных методов разработки, Nexus от Sonatype в 2012 году сделал еще один шаг вперед в локальном хранении деталей, выявив известные уязвимости безопасности для компонентов в своих кэширующих репозиториях. Команды разработчиков, использующие функцию Проверка работоспособности репозитория, могли определить компоненты, которые со временем вышли из строя, а затем выбрать более безопасные версии. В конце 2015 года мы сделали еще один шаг вперед с автоматизированными политиками в Nexus Firewall — тема, которая хорошо освещена в других моих сообщениях.

То, что находится в вашем менеджере репозитория, находится в производстве

Используя данные более 133 000 веб-сайтов, исследователи из Северо-восточного университета показали, что «37% содержат как минимум одну библиотеку JavaScript с известной уязвимостью. С точки зрения каждой библиотеки по крайней мере 36,7% jQuery, 40,1% Angular, 86,6% Handlebars и 87,3% включений YUI используют уязвимую версию.

Вызывает тревогу то, что многие сайты продолжают полагаться на пакеты npm, такие как YUI и SWFObject, которые больше не поддерживаются. На самом деле, средний веб-сайт в наборе данных [NU] использует версию библиотеки на 1177 дней старше самой новой версии, что объясняет, почему так много уязвимых библиотек, как правило, задерживаются в Интернете».

Что не так с 200 миллиардами загрузок?

Ничего с инновационной точки зрения. Это потрясающе, и мы все можем отпраздновать это достижение вместе с Лори.

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

Если вам интересно узнать больше об универсальных менеджерах репозиториев, я приглашаю вас скачать Nexus Repository OSS сегодня. Он бесплатный, полнофункциональный и используется более чем 150 000 команд разработчиков по всему миру.