Как стать автором
Обновить

Вы таки внедрили сканеры безопасности в пайплайны — на этом все?

Уровень сложностиСредний
Время на прочтение19 мин
Количество просмотров3.2K
Всего голосов 11: ↑11 и ↓0+13
Комментарии5

Комментарии 5

Внутренний сервис для оценки качества сервиса посредством выставления оценок по различным метрикам. Пример метрик: процент покрытия автотестами, утилизация CPU и памяти, соблюдение SLO. В этот же сервис вывели метрики по сканированию в пайплайнах.

Вот с этим не соглашусь:

  • Если были найдены новые файндинги, разработчик имеет возможность перейти в каждую джобу с результатами и сделать анализ. 

  • Если конкретный файндинг подтверждается, он переходит в статус уязвимости, разработчик ее исправляет. 

  • Если файндинг не подтверждается, т.е. разработчик посчитал его «фолсом», разработчик добавляет исключение для этого файндинга в отдельном репозитории в виде MR'а. 

Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec или его очень мало и он просто перегружен.

Подход, когда найденные секюрити проблемы, отправляются на анализ разработчику имеет ряд недостатоков. Для начала, как правило пайплайн един и в данной схеме отправляются как сикреты, так и какие то более сложные моменты, которые требуют знаний именно в аппсеке. В вашем случае, если дефект условно подтвердился, но разработчик его не правильно интерпретировал и неправильно исправил, то это возможно прошло мимро аппсека? (по схеме не очень понятно), если даже нет, то это увеличивает цепочку взаимодействий. Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа, и если дефект подтверждается, то в результате чего согдается дефект в виде документа, с рядом нужных полей, серьезность, описание с т.з. безопасности, т.е. то к чему может привести уязвимость, а так же с рекомендацией по устранению, что позволит помочь выбрать разработчику верное решение по устранению дефекта.

UPDATE:

"{пункт со звездочкой} внедрить QG и по возможности внедрить возможность блокировки релизов в случае несоблюдения политик ИБ."

Вот этот пункт, тоже по факту не жизнеспособен в реальности. Очень сложно настроить все так, чтобы блокировки всегда были обоснованы. А если произошла блокировка, а аппсек на обеде? С т.з. бизнеса это решение может привести к большим издержкам, и в целом снизит репутацию аппсек в компании. Здесь нужны другие меры.

Вот с этим не соглашусь

Ваше право, но подход уже доказал свою эффективность, больше года триажим так файндинги.

которые требуют знаний именно в аппсеке

Я бы не делал из знаний аппсека священную корову. Более того, нормальный разработчик точно должен знать основы; например, у нас проводятся всевозможные внутренние обучения как в процессе прохождения испытательного, так и регулярные после.

Девелопер-центричность - это про то, что разработчик получает сканирования безопасности как сервис - он имеет доступ к файндингам, имеет доступ к информации об уязвимости как в результатах сканирования, так и в нашей внутренней wiki и вполне может разобраться в сути проблемы. В 90% случаев проблемы (файндинги), с которыми сталкиваются разработчики, являются достаточно простыми и типовыми и все, что нужно сделать - научить справляться с ними самостоятельно.

Также важно понимать, что никто не исключает возможность задать вопрос аппсеку и тд.

AppSec не должен разгребать абсолютно все файндинги, потому что это может создать боттл нек в случае большого количества команд + сам по себе подход.. это все равно, что заставить L3 SOC работать на L1.

Мы, и безопасники, и разработчики, делаем одну работу под названием "качественный продукт". Поэтому не противопоставляя работу друг-другу, не набивая лишней ценности, мы просто помогаем решать те или иные задачи. Когда вы понимаете, что находитесь в одной лодке, вам не нужно бегать за разработчиками как за потенциальными злоумышленниками (они могут таковыми быть, но это другая тема) или детьми. Достаточно выстроить грамотные контроли и реализовать ретроспективные проверки.

Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec

Мой опыт говорит о диаметрально противоположном. Если аппсеки занимаются всем триажом, у меня появляются вопросы к наличию и качеству необходимых процессов.

не правильно интерпретировал и неправильно исправил

Риск есть, но, опять таки, я бы посмотрел как вы справляетесь с перепроверкой каждого обработанного файндинга при наличие 200+ микросервисов и встраивании хотя бы тех классов инструментов в пайплайны, о которых я писал в статье - SAST/SCA/Secrets. Ну и "неправильно" исправить нужно еще и так, чтобы сканер при следующей проверке не стриггерился еще раз)

Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа

Это ваша точка зрения, имеет место быть, но у меня другая.

позволит помочь выбрать разработчику верное решение по устранению дефекта

Если речь не про архитектурные баги, в 90% случаев гуглится за минуту или же ответ находится прям в описании файндинга.

Очень сложно настроить все так, чтобы блокировки всегда были обоснованы

Блокировки всегда имеют понятное обоснование - наличие необработанных файндингов.

Вот этот пункт, тоже по факту не жизнеспособен в реальности

Возможно мы в разных реальностях)

А если произошла блокировка, а аппсек на обеде

Можно пожелать приятного аппетита)) В целом, опять же, разработчик сам может постараться решить проблему и в большинстве случаев так и происходит. Но, если все же не может, и речь про хотфиксы и пр, сейчас мы разрешаем кенселить джобы, при этом отписав аппсеку о том, что это произошло по определенной причине. Как только аппсек доест, наверняка поможет разобраться в проблеме и файндинг в какой-то перспективе будет обработан.

больше года триажим так файндинги.

Вот может в этом разница, не хочу вас задеть, но я просто работаю в команде где аппсек выстраивался более 17 лет, через многие вещи уже прошли и многое показало свою несостоятельность, и от этого отказались, либо наоборот как рабочий вариант и его и придерживаемся.

В целом конечно же нет единственно верного пути и какого то 100% верного решения, много зависит от объема проекта/ов и кодовой базы, наличия сильной аппсек команды, вменяемости разработчиков и т.д...

Далее, дабы не утонуть в спорах, в которых не всегда рождается истина, пожелаю вам и вашей команде удачи в этом нелегком деле :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий