Comments 5
как я понял это pre-commit проверки в самих IDE разработчиков. Встраиваете ли вы эти же проверки в пайплайн на случай если разработчик игнорирует сообщения об уязвимостях?
Статистические анализаторы грешат ложными срабатываниями (по крайней мере на уязвимости из баз cve) можно ли в эти инструменты добавлять исключения для определённых проверок?
1) Да, встраиваем, все проверки линтерами проводятся как локально, так и на CI, блокируя деплой для уязвимого кода
2) Да, можно через `nolint` директивы, либо через конфигурацию запускаемых линтеров
Привет! На связи команда продуктовой безопасности Авито)
Проверки у нас встроены параллельно CI-пайплайну: сканируем каждый пуш в любой репозиторий, дальше отслеживаем дедуплицированные файндинги по их жизненному циклу (переходы между ветками, исчезновения, пометки как false positive и т.д.). Nolint, разумеется, игнорируем, фолзами промечаем конкретные находки либо сами, либо по просьбе разработчиков, которых уведомляем алертами и задачами.
Для сервисов на go последние 4 года используем gosec, последние 2 - codeql в пару к нему. Пуши в репозитории не блокируем из-за находок по языковым сканерам, блокируем только вычурно уязвимые зависимости и секреты.
Судя по статье gosec выглядит наиболее рабочим вариантом, в отличие от gokart и govulncheck. У себя применяем golangci-lint с gosec как часть CI.
Как искать уязвимости в проекте на Go: обзор популярных анализаторов кода и их возможностей