Господа, привет. А подскажите какие подходы используете или продумываете для

защиты от подобных угроз (https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview) на этапе разработки? Помиммо конечно полного запрета на повышения версий Open Source зависимостей..

SDLC,выработка политик для разрабов не обновлять без надобности, если нужно -то обязательная проверка AppSec,изолированый репо с разграничением прав кто может заливать туда зависимости ,кто нет. и т.д https://schibsted.com/blog/dependency-confusion-how-we-protected-ourselves/

Да. Только вот надобность очень часто возникает. Или когда уже накопился технический долг. Анализ пакета АппСеком. Можно не успеть вовремя особенно если пакет очень жирный. А у него еще своих зависимостей очень много. + как я говорил, может и при тестировании из дев. зависимостей стрельнуть. Конечно импакт будет ниже если все докерезировано/виртуализировано. Но все же + ущерб тем же разрабам может нанести, которые разработку не в докере ведут например.

нанести да нанесет, тут вопрос про скорость реагирования и уменьшения последствий

Это можно для прямых зависимостей. А вот глубже -- почти нереально руками

может обновы отложить ,если они прямо не асап задача критикал. А если так неотложно нужно, то проверить их под микроскопом. остальное не обновлять.

Под микроскопом в отдельном сетевом сегменте с этапами тестирования от зависимостей до фаззинга

Микроскоп разный. Если полное ревью то вот для примера, попробуй просмотреть вот это: https://deps.dev/npm/sails/1.5.2/dependencies/graph

SCA от известных, RT-Solar application analyzer и его аналог PT Application analyzer для поиска НВД, но не очень верится

Сначала тебе зависимость встроить в код надо, соответственно разрабу ее придется запускать на его тачке в процессе разработки и отладки. Вуаля - тачка разраба скомпрометирована, не?