Я прочитал следующее о package-lock. json file:
Этот файл предназначен для фиксации в репозиториях исходного кода и служит для различных целей:
- Опишите единое представление дерева зависимостей так, чтобы товарищи по команде, развертывания и непрерывная интеграция гарантированно устанавливали одни и те же зависимости.
- Предоставьте пользователям возможность «время- travel »в предыдущие состояния node_modules без необходимости фиксировать сам каталог.
- Для облегчения большей видимости изменений дерева с помощью читаемых различий в системе управления версиями.
- И оптимизировать процесс установки, разрешив npm для пропуска повторяющихся разрешений метаданных для ранее установленных пакетов.
См. NPMJS docs package-lock. json description .
Но в другом фрагменте по той же ссылке я вижу:
целостность§
Это стандартная целостность подресурсов для этот ресурс.
- Для связанных зависимостей это не включено, независимо от источника.
- Для источников реестра это целостность, предоставленная реестром, или если она не была предоставлена SHA1 в shasum.
- Для git источников это спецификация c commit ha sh, из которой мы клонировали.
- Для удаленных источников tarball это целостность, основанная на SHA512 файла.
- Для локальных источников tarball: это поле целостности, основанное на SHA512 файла.
См. NPMJS docs package-lock. json целостность зависимостей .
Следуя ссылке на Standard Subresource Integrity (SRI), я обнаружил следующее:
1.1. Цели
- Компрометация стороннего сервиса не должна автоматически означать компрометацию каждого сайта, включающего его скрипты. Авторы контента будут иметь механизм, с помощью которого они могут указывать ожидания для контента, который они загружают, что означает, например, что они могут загружать определенный c скрипт, а не любой скрипт, который имеет конкретный URL.
См. W3 C Целостность подресурсов
Итак, мне интересно, почему в описании package-lock. json в NPMJS docs цель безопасности не упоминается / не перечисляется. Лично мне нравится идея использования package-lock. json для повышения безопасности моего приложения (путем тщательного изучения фактических заблокированных зависимостей и изменения файла блокировки, зарегистрированного в моем репозитории VCS одновременно с некоторыми изменениями, внесенными в мой package. json предотвращение попадания любых измененных зависимостей в мое приложение).
Но, возможно, мне что-то не хватает, и по некоторым причинам файл блокировки не может быть использован в целях безопасности, о которых я говорил выше.