Комментарии 3
Вот прям отдельное спасибо за опенсорс решения в каждой вашей статье!
Выглядит интересно, SAST в Gitlab включается и настраивается легко. Есть много инструментов, которые могут дополнять друг друга.
Скорее всего они делают тоже самое что и semgrep
В целом и сам Gitlab потихоньку двигается в сторону уменьшения инструментов, объявляя, что перестает поддерживать некоторые из них (например, Bandit, ESLint, GoSec).
Почему? Потому что портированы практически все правила с bandit, eslint, gosec в правила semgrep https://gitlab.com/gitlab-org/security-products/sast-rules
Поэтому иногда имеет смысл подключить инструмент самостоятельно. Покажу на примере все того же Semgrep.
На досуге возьмите semgrep базовый и контейнер из gitlab, просканируйте одну и туже кодовую базу, и сравните результаты. Боюсь разница вас смутит... з.ы. не хочу сказать что концептуальная разница в сканнерах, но показатели work time и выявленные дефекты будут существенно отличаемы.
Зоопарк технологий. Под каждый ЯП — свой набор инструментов, каждый из которых может работать по-своему. Например, phpcs-security-audit выполняется не под рутом, а это значит, что мы не можем установить свои либы (jq, bash и т. д.).
FROM registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest
USER root
RUN apk update && apk add git curl
в alpine нету bash, в alpine ash
Но есть и минусы:
GitLab может ограничивать возможности инструмента;
GitLab может не так активно актуализировать версии инструментов.
Во многих языках программирования есть пакетные менеджеры, при помощи которых мы можем выкачивать код, и информация об этом сохраняется в различных файлах (go.sum, composer.lock, package-lock.json, yarn.lock, Gemfile.lock, requirements.txt и т. д.). Dependency Scanning-инструменты сканируют эти файлы, смотрят, какие пакеты были выкачаны и какие были версии, далее пакеты проверяют в базе скомпрометированного ПО и, если их там находят, выдают ошибку.
Если бы было все так просто...
К ознакомлению попрошу изучить данную статейку - https://www.endorlabs.com/learn/why-are-all-sca-tools-wrong
Ознакомиться с подходом syft'а "catalogers"
з.ы. дальше статью не осилил)
Спасибо за проявленный интерес к статье и за комментарий!
Скорее всего они делают тоже самое что и semgrep
Возможно, но нельзя сказать со 100% уверенностью. К тому же, главная цель статьи, показать существующие возможности.
Почему? Потому что портированы практически все правила с bandit, eslint, gosec в правила semgrep https://gitlab.com/gitlab-org/security-products/sast-rules
Да, в том числе. Но всё таки Gitlab это делает довольно медленно, тот же phpcs-security-audit до недавнего времени использовался по умолчанию для PHP и только 5 месяцев назад миграцию на Semgrep сделали (и то ещё не полноценно) https://gitlab.com/gitlab-org/gitlab/-/issues/364060
FROM registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest
USER root
RUN apk update && apk add git curl
Если прочитаете предыдущую статью, станет понятно, что одна из целей - сделать максимально простое и универсальное решение, которое будет покрывать все стадии DevSecOps на любом Gitlab. Если для каждого инструмента делать свои образы, то это лишние заморочки.
в alpine нету bash, в alpine ash
Bash ставился как раз для того, чтобы использовать один и тот же скрипт для обработки артефакта.
(тут скрин с обновлениями Semgrep в Gitlab)
То, что обновления происходят часто - не значит что это актуальные изменения.
К тому же, кроме Semgrep там ещё много других внешних инструментов.
К тому же, вспоминаем кейс выше с phpcs-security-audit, issue висел 2 года до того, как начали делать миграцию.
В любом случае, до конечных пользователей изменения будут приходить с задержкой. Где-то больше, где-то меньше, но задержка будет.
Если бы было все так просто...
К ознакомлению попрошу изучить данную статейку - https://www.endorlabs.com/learn/why-are-all-sca-tools-wrong
Опять же, я рассказываю про то, какие инструменты есть. Использовать их или нет - решает каждый сам для себя :)
з.ы. дальше статью не осилил)
Рекомендую всё таки прочитать (в том числе другие части), чтобы была более целостная картина, надеюсь будет полезно
Внедряем DevSecOps в процесс разработки. Часть 2. Обзор инструментов, Commit-time Checks