Внутренний сервис для оценки качества сервиса посредством выставления оценок по различным метрикам. Пример метрик: процент покрытия автотестами, утилизация CPU и памяти, соблюдение SLO. В этот же сервис вывели метрики по сканированию в пайплайнах.
Ваше право, но подход уже доказал свою эффективность, больше года триажим так файндинги.
которые требуют знаний именно в аппсеке
Я бы не делал из знаний аппсека священную корову. Более того, нормальный разработчик точно должен знать основы; например, у нас проводятся всевозможные внутренние обучения как в процессе прохождения испытательного, так и регулярные после.
Девелопер-центричность - это про то, что разработчик получает сканирования безопасности как сервис - он имеет доступ к файндингам, имеет доступ к информации об уязвимости как в результатах сканирования, так и в нашей внутренней wiki и вполне может разобраться в сути проблемы. В 90% случаев проблемы (файндинги), с которыми сталкиваются разработчики, являются достаточно простыми и типовыми и все, что нужно сделать - научить справляться с ними самостоятельно.
Также важно понимать, что никто не исключает возможность задать вопрос аппсеку и тд.
AppSec не должен разгребать абсолютно все файндинги, потому что это может создать боттл нек в случае большого количества команд + сам по себе подход.. это все равно, что заставить L3 SOC работать на L1.
Мы, и безопасники, и разработчики, делаем одну работу под названием "качественный продукт". Поэтому не противопоставляя работу друг-другу, не набивая лишней ценности, мы просто помогаем решать те или иные задачи. Когда вы понимаете, что находитесь в одной лодке, вам не нужно бегать за разработчиками как за потенциальными злоумышленниками (они могут таковыми быть, но это другая тема) или детьми. Достаточно выстроить грамотные контроли и реализовать ретроспективные проверки.
Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec
Мой опыт говорит о диаметрально противоположном. Если аппсеки занимаются всем триажом, у меня появляются вопросы к наличию и качеству необходимых процессов.
не правильно интерпретировал и неправильно исправил
Риск есть, но, опять таки, я бы посмотрел как вы справляетесь с перепроверкой каждого обработанного файндинга при наличие 200+ микросервисов и встраивании хотя бы тех классов инструментов в пайплайны, о которых я писал в статье - SAST/SCA/Secrets. Ну и "неправильно" исправить нужно еще и так, чтобы сканер при следующей проверке не стриггерился еще раз)
Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа
Это ваша точка зрения, имеет место быть, но у меня другая.
позволит помочь выбрать разработчику верное решение по устранению дефекта
Если речь не про архитектурные баги, в 90% случаев гуглится за минуту или же ответ находится прям в описании файндинга.
Очень сложно настроить все так, чтобы блокировки всегда были обоснованы
Блокировки всегда имеют понятное обоснование - наличие необработанных файндингов.
Вот этот пункт, тоже по факту не жизнеспособен в реальности
Возможно мы в разных реальностях)
А если произошла блокировка, а аппсек на обеде
Можно пожелать приятного аппетита)) В целом, опять же, разработчик сам может постараться решить проблему и в большинстве случаев так и происходит. Но, если все же не может, и речь про хотфиксы и пр, сейчас мы разрешаем кенселить джобы, при этом отписав аппсеку о том, что это произошло по определенной причине. Как только аппсек доест, наверняка поможет разобраться в проблеме и файндинг в какой-то перспективе будет обработан.
Мы получаем метрики по репозиториям. Часто бывает так, что репозиторий и есть один сервис. Если нет, нужно просто немного постараться над метриками, чтобы их объединить.
> Ведь один сервис может разрабатывать десяток команд
У нас микросервисы, такое тоже редко случается.
> Каким образом сервис метрик помогает
В сервисе метрик подсвечивается у какого сервиса есть необработанные файндинги. Метрика по безопасности ставится в один ряд с остальными метриками и составляет одну общую метрику, по которой оценивается работа разработчиков. Собственно у разработчиков есть понятная и простая мотивация улучшить метрику.
Мы хотим внедрить ASOC, который будет работать в паре с построенной DevSecOps платформой, между которыми статусы файндингов будут зеркалироваться. Это уже следующая степень развития, где мы предоставляем AppSecам возможность работать с файндингами как через git в платформе, так и через UI в ASOC. В ASOC не будут попадать файндинги отфильтрованные на базе платформы. Платформа останется центральным звеном и все другие новые фичи будут внедряться также исходя из идеи девелопер центричности.
Смотря какую статистику Вы имеете ввиду. Если говорить о количестве файндингов и степени критичности найденных файндингов - мы эту статистику собираем. Из этой статистики строятся метрики в сервисе Скоринга, упомянутом в статье.
Мы запускаем SAST на каждый коммит, чтобы быть как можно "левее" и как можно раньше сообщать разработчикам о потенциальных проблемах. 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-ами проекта, что уже не так просто.
Мы знаем об этом (возможности переопределения) и держим в голове, что нам нужен превентивный механизм. Но риск мал (мы по проектам можем пробежаться "грепом" и все найти).
Внутренний сервис для оценки качества сервиса посредством выставления оценок по различным метрикам. Пример метрик: процент покрытия автотестами, утилизация CPU и памяти, соблюдение SLO. В этот же сервис вывели метрики по сканированию в пайплайнах.
Ваше право, но подход уже доказал свою эффективность, больше года триажим так файндинги.
Я бы не делал из знаний аппсека священную корову. Более того, нормальный разработчик точно должен знать основы; например, у нас проводятся всевозможные внутренние обучения как в процессе прохождения испытательного, так и регулярные после.
Девелопер-центричность - это про то, что разработчик получает сканирования безопасности как сервис - он имеет доступ к файндингам, имеет доступ к информации об уязвимости как в результатах сканирования, так и в нашей внутренней wiki и вполне может разобраться в сути проблемы. В 90% случаев проблемы (файндинги), с которыми сталкиваются разработчики, являются достаточно простыми и типовыми и все, что нужно сделать - научить справляться с ними самостоятельно.
Также важно понимать, что никто не исключает возможность задать вопрос аппсеку и тд.
AppSec не должен разгребать абсолютно все файндинги, потому что это может создать боттл нек в случае большого количества команд + сам по себе подход.. это все равно, что заставить L3 SOC работать на L1.
Мы, и безопасники, и разработчики, делаем одну работу под названием "качественный продукт". Поэтому не противопоставляя работу друг-другу, не набивая лишней ценности, мы просто помогаем решать те или иные задачи. Когда вы понимаете, что находитесь в одной лодке, вам не нужно бегать за разработчиками как за потенциальными злоумышленниками (они могут таковыми быть, но это другая тема) или детьми. Достаточно выстроить грамотные контроли и реализовать ретроспективные проверки.
Мой опыт говорит о диаметрально противоположном. Если аппсеки занимаются всем триажом, у меня появляются вопросы к наличию и качеству необходимых процессов.
Риск есть, но, опять таки, я бы посмотрел как вы справляетесь с перепроверкой каждого обработанного файндинга при наличие 200+ микросервисов и встраивании хотя бы тех классов инструментов в пайплайны, о которых я писал в статье - SAST/SCA/Secrets. Ну и "неправильно" исправить нужно еще и так, чтобы сканер при следующей проверке не стриггерился еще раз)
Это ваша точка зрения, имеет место быть, но у меня другая.
Если речь не про архитектурные баги, в 90% случаев гуглится за минуту или же ответ находится прям в описании файндинга.
Блокировки всегда имеют понятное обоснование - наличие необработанных файндингов.
Возможно мы в разных реальностях)
Можно пожелать приятного аппетита)) В целом, опять же, разработчик сам может постараться решить проблему и в большинстве случаев так и происходит. Но, если все же не может, и речь про хотфиксы и пр, сейчас мы разрешаем кенселить джобы, при этом отписав аппсеку о том, что это произошло по определенной причине. Как только аппсек доест, наверняка поможет разобраться в проблеме и файндинг в какой-то перспективе будет обработан.
Чтобы не обижать вендоров, скажу, что все зависит от языкового стека)
Мы получаем метрики по репозиториям. Часто бывает так, что репозиторий и есть один сервис. Если нет, нужно просто немного постараться над метриками, чтобы их объединить.
> Ведь один сервис может разрабатывать десяток команд
У нас микросервисы, такое тоже редко случается.
> Каким образом сервис метрик помогает
В сервисе метрик подсвечивается у какого сервиса есть необработанные файндинги. Метрика по безопасности ставится в один ряд с остальными метриками и составляет одну общую метрику, по которой оценивается работа разработчиков. Собственно у разработчиков есть понятная и простая мотивация улучшить метрику.
прометей как стандарт =)
Мы хотим внедрить ASOC, который будет работать в паре с построенной DevSecOps платформой, между которыми статусы файндингов будут зеркалироваться.
Это уже следующая степень развития, где мы предоставляем AppSecам возможность работать с файндингами как через git в платформе, так и через UI в ASOC. В ASOC не будут попадать файндинги отфильтрованные на базе платформы.
Платформа останется центральным звеном и все другие новые фичи будут внедряться также исходя из идеи девелопер центричности.
Смотря какую статистику Вы имеете ввиду. Если говорить о количестве файндингов и степени критичности найденных файндингов - мы эту статистику собираем. Из этой статистики строятся метрики в сервисе Скоринга, упомянутом в статье.
Мы запускаем SAST на каждый коммит, чтобы быть как можно "левее" и как можно раньше сообщать разработчикам о потенциальных проблемах.
MR-пайплайны есть не везде.
> Ведь это не позволяет делать красивые комментарии в мерж регвестах
Мы просто пошли по другому пути, что не исключает Вами предложенный вариант.
Если по вовлеченности - 53 контрибьютора в репозитории с исключениями, минус 1 DevSecOps и минус 6 AppSecов.
Метрика по эффективности - можно взять процент команд с оценкой A+ в Скоринге на момент внедрения и сравнить с текущим процентом. Так, например, процент команд с оценкой A+ по SAST на момент внедрения - 63%, сейчас - 85%, по секретам - на момент внедрения - 53%, сейчас - 88%.
Сейчас мы работаем только с результатами сканирования и можем исключать файндинг не только по конкретным репозиториям, но и для всех сразу (это если везде FP или принимаем риск).
В дальнейшем мы будем дорабатывать проверки сканеров.
Куда должен уводить клик? Стандартный Job аутпут так не умеет.
Это можно было бы сделать, если бы мы гоняли проверки только на MR пайплайне. Для того, чтобы просканить бранч, а потом разметить создавшийся MR, нужен бек, который сохранит результат привязанный к коммиту, потом смерджит резы сканов для разных коммитов и тд.
И я как-то пробовал размечать MR, ничего кроме грязи не получалось, если это делать прям по строкам. Мб чуть позже еще раз попробую как-то по-другому.
Они как правило задачами и подкрепляются. И это отличный механизм в том смысле, что тебе фактически не нужно следить дополнительно за выполнением задачи в баг-трекере. Если уязу вовремя не исправили, она "выстрелит" снова =)
Обычно к временным исключениям указывают комментарий - какая задача на исправление ей соответствует.
Но временные исключения создаются не только если речь про подтвердившуюся уязвимость, для которой завели задачу на исправление. Это также работает с уязвимостями в транзитивных зависимостях, для которых еще нет обновления.
Мы уже сейчас отслеживаем отмененные security-джобы и инлайн комментарии в коде, для обхода сработок сканера. (это в целом про потенциальные попытки обхода наших проверок разработчиками)
"Заменить пайплайн" нельзя, поскольку у нас PAAS и мы внедряемся в базовый пайп, который шарится на все микросервисы. К нему доступ разработчики не имеют.
Можно переопределить конкретную джобу внутри .gitlab-ci файла самого сервиса. Но для этого нужен сговор с Code Owners-ами проекта, что уже не так просто.
Мы знаем об этом (возможности переопределения) и держим в голове, что нам нужен превентивный механизм. Но риск мал (мы по проектам можем пробежаться "грепом" и все найти).