В прошлый раз мы обсуждали, почему SAST не может обнаружить вредоносный код в frontend-приложениях. Сегодня рассмотрим SCA.
1️⃣ Современные js-фреймворки 📱 используют пакетный менеджер (npm). Все зависимости при билде упаковываются в файл-бандл (app.js, main.js и т.п.). Этот бандл подключается на веб-страницу в виде файлового скрипта. SCA-анализатору передается файл package.json/package-lock.json - по данному файлу SCA обнаружит зависимости, которые попадут в бандл.
НО на веб-странице могут быть подключены и другие скрипты 👩💻. В следующем примере на странице размещен бандл (main.js) и еще 2 внешних и 2 инлайн-скрипта. О них SCA не знает.
<html>
<head>
<script src="//metrics.ru/metrics.js"></script>
<script src="//cdn.ru/module.js"></script>
<script src="/js/main.js"></script>
</head>
<body onload='console.log("inline 1 script")'>
<div id="root"></div>
<script>console.log("inline 2 script")</script>
</body>
</html>
2️⃣ У вас в проекте нет внешних и инлайн-скриптов? А вы уверены? Проверяете? На аудитах безопасности мы иногда обнаруживаем даже скрипты Яндекс Метрики в проектах, которые должны работать в корп. сетях без интернета 😱. Поэтому одной уверенности здесь мало.
3️⃣ В некоторых компаниях SCA встроен только на этапе сканирования образов контейнеров 🖥. Для frontend-приложений это бессмысленно, т.к. из файла-бандла js невозможно восстановить зависимости (невозможно = SCA этим не занимается). Поэтому ваш Trivy покажет вам только уязвимости пакетов ОС, т.к. не найдет ни одной зависимости npm. Анализировать npm-зависимости необходимо только по исходному коду (package-lock.json).
4️⃣ В js есть возможность динамического импорта модулей / добавления на страницу новых скриптов в рантайме 🔎. Любая библиотека может загрузить новые скрипты со сторонних хостов. Код даже может быть спрятан в картинке/другом ресурсе и проинтерпретирован динамически через eval(). Если такое поведение библиотеки (НДВ) еще не засветилось и не попало в базы вредоносных пакетов вашего SCA, то вы об этом не узнаете.
6️⃣ Об актуальности базы вредоносных/уязвимых пакетов. Любая база пополняется с задержкой. Например в инциденте с вредоносным кодом в библиотеке polyfill.js информация попала в базы только через 4 месяца 😭. В более 100 000 приложений 4 месяца присутствовал вредоносный код 💰
7️⃣ В хороших SCA-анализаторах есть возможность подключения внешних фидов о вредоносных пакетах. А насколько хороша бесплатная база Trivy/Grype?
8️⃣ Если для популярных пакетов кто-то заметит вредоносное поведение и сообщит SCA-вендорам, то что говорить о редких пакетах /форках /внутренних библиотеках. Информация о них вообще никогда не появится в базах SCA.
9️⃣ Тег-менеджер (Google, Яндекс и другие). Прямое назначение тег-менеджеров - динамическое добавление на страницы новых скриптов по определенным условиям. SCA не видят это.
1️⃣0️⃣ Мы не знаем зависимости внешних/сторонних скриптов. Допустим скрипт системы аналитики, мы получаем его в виде минифицированного бандла, понять его зависимости также не получится.
1️⃣1️⃣ Можно ли считать код, написанный ИИ, сторонним opensource-кодом, а не собственным? 😄
1️⃣2️⃣ Разработчик может скопировать код сторонней библиотеки в проект/сделать форк, чтобы SCA не ругался. Но это отдельная история...
Таким образом SCA-анализатор не может достоверно обнаружить все сторонние компоненты, используемые frontend-приложением, а для тех которые обнаружил полностью зависит от качества используемых баз/фидов.
Применение SCA нейтрализует всего 3 из 75 угроз по фреймворку Frontend Kill Chain.
Для безопасной разработки frontend-приложений применяются FAST-анализаторы, обнаруживающие вредоносные компоненты по поведению в рантайме браузера-песочницы 🌐
FAST обнаруживает все скрипты, даже динамически загруженные и добавленные через тег-менеджеры, и анализирует реальное поведение собственного, стороннего и сгенерированного ИИ кода. И все это без ложных срабатываний и регулярного триажа 🔎
@FrontSecOps