Иногда, когда речь заходит о проблемах безопасности NPM, я слышу аргумент «но наш код не работает публично», «это просто внутреннее приложение». Аргумент состоит в том, что им не нужно беспокоиться о безопасности. Это, конечно, совершенно неправильно.
Это неправильно, потому что конечные пользователи — не единственная цель для хакеров. Разработчики также могут быть взломаны. Особенно на этапе сборки. Знаете ли вы, что существует несколько пакетов npm, которые загружают и запускают двоичный исполняемый код как часть обычной сборки веб-проекта? Мы действительно уязвимы.
Итак, как оставаться в безопасности? Тем более, что инструмент аудита npm сам по себе совершенно бесполезен, как мы можем убедиться, что наше приложение является пуленепробиваемым, в том числе во время разработки?
В первую очередь разделим размещение уязвимого кода. Это очень важно при определении того, вызывает ли данная проблема безопасности в данном пакете NPM какое-либо беспокойство. Код работает
- В браузере.
- На сервере
- Во время сборки приложения.
Если брешь в безопасности связана именно с безопасностью браузера, вам не нужно беспокоиться о том, что зависимость, которую вы используете, работает только на сервере или во время сборки.
Во-вторых, вам нужно помнить о различных типах уязвимостей безопасности. Часто настоящий аудит безопасности указывает, является ли уязвимость проблемой конкретно в браузере или на сервере. Если об этом ничего не сказано, то вам просто нужно было бы предположить, что уязвимость может касаться всех, и залатать ее.
