Comments 15
Есть какие-то метрики, как переход от первого случая ко второму повлиял на вовлеченность и общее качество?
Что дальше делать с правилами, которые часто дают FP (выше какого-то порога)? Мы переписываем правило, убираем его из обязательных для триажа или делаем кросспроверку с помощью LLM
UX для добавления FP выглядит прям страшно (смена контекста, накидать MR, понять за какое свойство зацепиться), как и способы дедупликации. Как и вывод джобы поехал, может сделать его кликабельным? А разметку FP перенести в комментарии к MR.
Временные исключения должны подкрепляться задачей на устранений тех. долга, иначе какой в них смысл?
Что мешает пользователю заменить пайплайн? Как-то этот момент обошли в статье.
Есть какие-то метрики, как переход от первого случая ко второму повлиял на вовлеченность и общее качество
Если по вовлеченности - 53 контрибьютора в репозитории с исключениями, минус 1 DevSecOps и минус 6 AppSecов.
Метрика по эффективности - можно взять процент команд с оценкой A+ в Скоринге на момент внедрения и сравнить с текущим процентом. Так, например, процент команд с оценкой A+ по SAST на момент внедрения - 63%, сейчас - 85%, по секретам - на момент внедрения - 53%, сейчас - 88%.
Что дальше делать с правилами, которые часто дают FP (выше какого-то порога)
Сейчас мы работаем только с результатами сканирования и можем исключать файндинг не только по конкретным репозиториям, но и для всех сразу (это если везде FP или принимаем риск).
В дальнейшем мы будем дорабатывать проверки сканеров.
может сделать его кликабельным?
Куда должен уводить клик? Стандартный Job аутпут так не умеет.
А разметку FP перенести в комментарии к MR
Это можно было бы сделать, если бы мы гоняли проверки только на MR пайплайне. Для того, чтобы просканить бранч, а потом разметить создавшийся MR, нужен бек, который сохранит результат привязанный к коммиту, потом смерджит резы сканов для разных коммитов и тд.
И я как-то пробовал размечать MR, ничего кроме грязи не получалось, если это делать прям по строкам. Мб чуть позже еще раз попробую как-то по-другому.
Временные исключения должны подкрепляться задачей на устранений тех. долга, иначе какой в них смысл?
Они как правило задачами и подкрепляются. И это отличный механизм в том смысле, что тебе фактически не нужно следить дополнительно за выполнением задачи в баг-трекере. Если уязу вовремя не исправили, она "выстрелит" снова =)
Обычно к временным исключениям указывают комментарий - какая задача на исправление ей соответствует.
Но временные исключения создаются не только если речь про подтвердившуюся уязвимость, для которой завели задачу на исправление. Это также работает с уязвимостями в транзитивных зависимостях, для которых еще нет обновления.
Что мешает пользователю заменить пайплайн
Мы уже сейчас отслеживаем отмененные security-джобы и инлайн комментарии в коде, для обхода сработок сканера. (это в целом про потенциальные попытки обхода наших проверок разработчиками)
"Заменить пайплайн" нельзя, поскольку у нас PAAS и мы внедряемся в базовый пайп, который шарится на все микросервисы. К нему доступ разработчики не имеют.
Можно переопределить конкретную джобу внутри .gitlab-ci файла самого сервиса. Но для этого нужен сговор с Code Owners-ами проекта, что уже не так просто.
Мы знаем об этом (возможности переопределения) и держим в голове, что нам нужен превентивный механизм. Но риск мал (мы по проектам можем пробежаться "грепом" и все найти).
Правильно понимаю, всё проверки SAST вы запускаете не как валидационную сборку в мерж регвесте не давая тем самым завершить влитие уязвимого кода в защищаемую ветвь , а уже после влития на этапе сборки CI?
По чему так? Ведь это не позволяет делать красивые комментарии в мерж регвестах
Мы запускаем SAST на каждый коммит, чтобы быть как можно "левее" и как можно раньше сообщать разработчикам о потенциальных проблемах.
MR-пайплайны есть не везде.
> Ведь это не позволяет делать красивые комментарии в мерж регвестах
Мы просто пошли по другому пути, что не исключает Вами предложенный вариант.
Правильно понял, что отказавшись от DD, вы теперь не собираете нигде статистику уязвимостей в одном месте?
Почему вы не пошли путем такого конвейера:
Сканирование -> предобработка уязвимостей на основе конфигов DevSecOps -> отправка сырых/предобработанных отчетов от сканеров в DD -> дедупликация в том числе на основе предыдущих исключений в DD апсеками/разрабами -> возврат отчёта DD по репозиторию/сканеру с оставшимися уязвимостями в конвейер -> Quality gate принимает решение на основе содержимого уязвимостей от DD. Если надо внести исключение - оно вносится в DD, разраб перезапускает конвейер, и из DD уязвимость не прилетит, QG не лочит сборку. Затем при необходимости исключения переносятся в конфиги DevSecOps либо в сами сканеры при наличии у них собственных конфигов или UI. При необходимости срочно релизиться даже с уязвимостью, уязвимость в DD принимается разрабом/апсеком и при возврате списка уязвимостей из DD в конвейер возвращаются только не обработанные уязвимости (отклоненные и принятые не выгружаются, то есть возвращаются только явно необработанные), соответственно, сборка продолжается.
?
Мы хотим внедрить ASOC, который будет работать в паре с построенной DevSecOps платформой, между которыми статусы файндингов будут зеркалироваться.
Это уже следующая степень развития, где мы предоставляем AppSecам возможность работать с файндингами как через git в платформе, так и через UI в ASOC. В ASOC не будут попадать файндинги отфильтрованные на базе платформы.
Платформа останется центральным звеном и все другие новые фичи будут внедряться также исходя из идеи девелопер центричности.
Какой сервис используете для сборки метрик безопасности ?
Каким образом сервис метрик помогает? Там видно какие команды выполняли изменения больше всего за месяц или как, чтобы? Ведь один сервис может разрабатывать десяток команд. Или просто руководство разработки видит оценки по сервисам и этого достаточно, далее оно просто говорит «в таком-то сервисе в следующем инкременте повысить оценку»?
Мы получаем метрики по репозиториям. Часто бывает так, что репозиторий и есть один сервис. Если нет, нужно просто немного постараться над метриками, чтобы их объединить.
> Ведь один сервис может разрабатывать десяток команд
У нас микросервисы, такое тоже редко случается.
> Каким образом сервис метрик помогает
В сервисе метрик подсвечивается у какого сервиса есть необработанные файндинги. Метрика по безопасности ставится в один ряд с остальными метриками и составляет одну общую метрику, по которой оценивается работа разработчиков. Собственно у разработчиков есть понятная и простая мотивация улучшить метрику.
Разве увеличился time-to-market при реализации этапа 2?
Тот же semgrep не дает ли вам множество фолзов, ведь как утверждают Solar и PT их сервисы находят уязвимости с меньшим количеством фолзов?
Через тернии к звёздам: строим SSDLC на OpenSource-компонентах