Вот только что делать после само обследования? Строить по каждому пункты процессы?

Та нее, это скучно и долго

Формально определить цели, построить роадмап и внедрять процессы, да

Коллеги, нужен ваш совет.

Использую утилиту owasp dependency check для поиска уязвимых зависимостей в проектах компании. Она выдает очень много уязвимых npm зависимоcтей, часто это всякие утилиты для сборка фронта.
Можно ли явно отделить уязвимости, которые актуальны только для серверных nodejs приложений от уязвимостей, которые актуальны для веб-приложений?
Когда приходишь к фронтендерам они говорят, что найденные уязвимости нельзя воспроизвести в веб-приложении в принципе.

Привет, не проверять dev зависимости?

да, я уже так стал делать, но:
1. далеко не все команды разделяют dev и не dev зависимости
2. dev зависимости могут попадать на фронт

Это же всё организационные моменты. Не уверен что их можно решить настройкой инструментария

дело не в первом пункте, можно было бы повлиять
дело во втором пункте :) нет смысла пропускать dev зависимости, если они всё равно попадают на фронт

А каким образом они могут попадать?

Если их не устанавливать, то их и не будет

Сейчас пробую проверить гипотезу: беру веб-приложение, все зависимости из depedependencies перетащить в devDependencies
приложение должно развалиться, т.к. нужных компонентов в dependencies не окажется

но пока всё работает)

Значит запускается npm install без параметров, когда устанавливается всё

всем привет, кто подскажет как сделать в Jenkins логику таймаута для апдейта стека в AWS c помощью  cfnUpdate(stack: stackName, ....)
задача такая, если стек обновился гуд то идти дальше по джобе,
а если стук обновляется в течение 40 минут, то понизит кол-во  тасок до 0, и продолжет обновление до какого либо статуса и идти дальше оп джобе?

параметры не очень влияют на итоговый бандл
описанная гипотеза не подтвердилась: приложение успешно собралось, приложение работает, размер js не изменился.
коллега-фронтендер ещё раз сказал, что разделение зависимостей по типам условное.
Если зависимость импортируется где-нибудь в коде, то она попадёт в итоговый бандл

так что можно вернуться к первоначальному вопросу: можно ли явно отделить уязвимости, которые актуальны только для серверных nodejs приложений от уязвимостей, которые актуальны для веб-приложений?

Как это не повлияет? Если библиотека которая используется в прод билде указана в devDependencies, а при сборке с нуля (то есть без сохранения node_modules!) запустить npm install --only=prod, а затем сборку, то она отвалится с ошибкой, потому что не сможет найти эту библиотеку

я могу ответить ещё вот такой ссылкой: https://incubator.flaks.dev/devdependencies-mistake

всем приветов
кто-то запускал докер приложения через openfaas?

интересует пример как параметры передать