Официальный источник пакетов NuGet: Должен ли я беспокоиться о безопасности пакетов?

Question

Согласно этой странице :

Нет централизованного процесса утверждения для добавления пакетов. Когда вы загружаете пакет в галерею пакетов NuGet (которая еще не существует), вам не придется ждать дни или недели, пока кто-нибудь рассмотрит его и одобрит. Вместо этого мы будем полагаться на сообщество, которое будет модерировать и контролировать себя, когда дело доходит до подачи. Это в духе того, как работают CodePlex.com и RubyGems.org.

Это заставляет меня чувствовать себя неловко. Прежде чем загрузить дополнение Firefox, я знаю, что в нем не должно быть вредоносного кода, поскольку AFAIK все дополнения на addons.mozilla.org проверяются Mozilla. Прежде чем загрузить проект с открытым исходным кодом с codeplex.com или code.google.com, я знаю, что он должен быть безопасным, поскольку любой может проверить его исходный код. И я также могу использовать WOT (сеть доверия), чтобы проверить, как другие люди думают о проекте.

Но прежде чем загрузить пакет из официального источника пакета NuGet. Возьмите этот например. Я не знаю, кто сделал этот пакет, и что содержится в пакете. Мне кажется, что любой может упаковать что-либо в пакет, дать ему любое имя (например, «Microsoft Prism», если имя не занято), а затем загрузить его в официальный источник пакета.

Должен ли я беспокоиться о безопасности пакетов на официальном источнике пакетов NuGet?

Answer 1

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

1. Двоичные файлы, загруженные с Sourceforge.net, Codeplex.com и т. Д., Могут содержать вредоносный код (либо установленный исходным отправителем, либо,скорее всего, вставленный хакером в веб-сайт), который может остаться незамеченным, пока кто-то (вы?) не укусит вас и не поднимет тревогу.
2. Даже если вы компилируете свои собственные двоичные файлы из источника, загруженного с одного из бывших веб-сайтов, он все еще может совершать злонамеренные действия, если вы не изучите весь исходный код и не поймете, что он делает.
3. Даже программное обеспечение, загруженное из «магазинов приложений» (например, Apple iTunes, Android Market), может содержать вредоносный код;некоторые из этих процессов проверки частично автоматизированы, но все еще не являются непогрешимыми, и человеческая проверка, которая также происходит, определенно не является непогрешимой!
4. В прошлом были примеры программного обеспечения, содержащего вредоносное ПО!

Возможно, существует континуум доверия к программному обеспечению (предоставляемый в виде двоичных файлов или исходного кода), и что-то вроде галереи пакетов Nuget (и CodePlex.com, и RubyGems и т. Д.), Вероятно, принадлежит менее заслуживающему доверияконец континуума.

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

Я верю, что сообщество разработает соглашения и механизмы для обеспечениячто Nuget становится надежным источником программных библиотек для разработчиков .Net, сохраняя при этом гибкость, не требуя формального процесса проверки.Однако конечная ответственность лежит на вас, как на пользователе, за то, чтобы ваша ИТ-безопасность не была скомпрометирована, а принимаемые вами меры предосторожности зависят от критичности ИТ-безопасности в контексте программного обеспечения, которое вы пишете (например, домашние проекты;Вероятно, низкий. Банковские, медицинские, проекты управления процессами; вероятно, высокий!)

Answer 2

NuGet не управляет доверием. Даже если это произойдет, вам все равно придется беспокоиться о доверии к тому, чему доверяет NuGet.

Вы должны быть абсолютно обеспокоены безопасностью кода в пакете NuGet. Вы должны быть обеспокоены безопасностью любого кода, с которым вы не знакомы.

Ниже приведен подход к использованию пакетов как лично, так и профессионально через NuGet и NPM:

1. Полностью заблокируйте семантический номер версии. Явно укажите основные, вспомогательные и номера патчей. Не думайте, что новые обновления будут безопасными или что их семантическая версия будет точной.
2. Используйте только известные текущие версии для производства.
3. Экспериментируйте с чем-либо в тестовой среде с ограниченным доступом, например, под учетной записью, которая не является локальным администратором, нет локального доступа к привилегированным учетным данным, нет прав доступа к привилегированным ресурсам, предоставленным IP-адресу тестовой машины.
4. Проверьте продавца. Например, если пакет выпущен Amazon и является AWS SDK, то этот пакет, вероятно, безопасно использовать, если вы доверяете Amazon.

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

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

Answer 3

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

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