Что скрывается в вашем коде?

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

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

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

Вопрос доверия

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

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

Лишь недавно мы узнали, что у НПМ есть «логическая ошибка», что позволило злоумышленникам выдавать мошеннические библиотеки за законные. По сути, NPM позволял добавлять кого угодно в качестве сопровождающего пакета без уведомления этих пользователей или получения их согласия. 

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

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

В недавнем исследовании, проведенном в Университете Канзаса («Что за вилка? Поиск скрытых клонов кода в npm»), исследователи показывают, как использование даже полностью проверенных пакетов может быть небезопасным.

Что вы можете с этим поделать?

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

Есть несколько вещей, которые вы можете сделать:

1. Запросите полный SBOM у каждого владельца библиотеки или поставщика программы, которого вы привлекаете. SBOM может помочь вам убедиться в том, что представляют собой все «ингредиенты» библиотеки или продукта. Кроме того, если вы обнаружите в библиотеке или продукте что-то, чего нет в списке SBOM, это следует считать подозрительным. Вы можете узнать больше о том, что такое SBOM. здесь.
2. Запросите у поставщика или владельца библиотеки надежное подтверждение того, что проверка целостности была проведена и вы получаете то, что ожидаете. Вам не следует доверять только собственным заверениям поставщика.
   
3. При установке пакетов используйте флаг CLI npm. --ignore-scripts чтобы избежать выполнения сценариев из сторонних пакетов на этапе установки.
4. Использовать Пакет-lock.json файл для блокировки номеров версий пакета. Когда вы используете Пакет-lock.json вы не только блокируете версии пакетов, которые используете, но также блокируете их зависимости. Риск заключается в том, что вы не будете получать какие-либо автоматические обновления пакетов, которые могут включать исправления различных ошибок. Но если вы приложили усилия для проверки определенной версии и не хотите включать что-либо еще без предварительной проверки, то блокировка номеров версий — лучший вариант.

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