Комментарии 5
Что за сервис Scoring?
Вот с этим не соглашусь:
Если были найдены новые файндинги, разработчик имеет возможность перейти в каждую джобу с результатами и сделать анализ.
Если конкретный файндинг подтверждается, он переходит в статус уязвимости, разработчик ее исправляет.
Если файндинг не подтверждается, т.е. разработчик посчитал его «фолсом», разработчик добавляет исключение для этого файндинга в отдельном репозитории в виде MR'а.
Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec или его очень мало и он просто перегружен.
Подход, когда найденные секюрити проблемы, отправляются на анализ разработчику имеет ряд недостатоков. Для начала, как правило пайплайн един и в данной схеме отправляются как сикреты, так и какие то более сложные моменты, которые требуют знаний именно в аппсеке. В вашем случае, если дефект условно подтвердился, но разработчик его не правильно интерпретировал и неправильно исправил, то это возможно прошло мимро аппсека? (по схеме не очень понятно), если даже нет, то это увеличивает цепочку взаимодействий. Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа, и если дефект подтверждается, то в результате чего согдается дефект в виде документа, с рядом нужных полей, серьезность, описание с т.з. безопасности, т.е. то к чему может привести уязвимость, а так же с рекомендацией по устранению, что позволит помочь выбрать разработчику верное решение по устранению дефекта.
UPDATE:
"{пункт со звездочкой} внедрить QG и по возможности внедрить возможность блокировки релизов в случае несоблюдения политик ИБ."
Вот этот пункт, тоже по факту не жизнеспособен в реальности. Очень сложно настроить все так, чтобы блокировки всегда были обоснованы. А если произошла блокировка, а аппсек на обеде? С т.з. бизнеса это решение может привести к большим издержкам, и в целом снизит репутацию аппсек в компании. Здесь нужны другие меры.
Вот с этим не соглашусь
Ваше право, но подход уже доказал свою эффективность, больше года триажим так файндинги.
которые требуют знаний именно в аппсеке
Я бы не делал из знаний аппсека священную корову. Более того, нормальный разработчик точно должен знать основы; например, у нас проводятся всевозможные внутренние обучения как в процессе прохождения испытательного, так и регулярные после.
Девелопер-центричность - это про то, что разработчик получает сканирования безопасности как сервис - он имеет доступ к файндингам, имеет доступ к информации об уязвимости как в результатах сканирования, так и в нашей внутренней wiki и вполне может разобраться в сути проблемы. В 90% случаев проблемы (файндинги), с которыми сталкиваются разработчики, являются достаточно простыми и типовыми и все, что нужно сделать - научить справляться с ними самостоятельно.
Также важно понимать, что никто не исключает возможность задать вопрос аппсеку и тд.
AppSec не должен разгребать абсолютно все файндинги, потому что это может создать боттл нек в случае большого количества команд + сам по себе подход.. это все равно, что заставить L3 SOC работать на L1.
Мы, и безопасники, и разработчики, делаем одну работу под названием "качественный продукт". Поэтому не противопоставляя работу друг-другу, не набивая лишней ценности, мы просто помогаем решать те или иные задачи. Когда вы понимаете, что находитесь в одной лодке, вам не нужно бегать за разработчиками как за потенциальными злоумышленниками (они могут таковыми быть, но это другая тема) или детьми. Достаточно выстроить грамотные контроли и реализовать ретроспективные проверки.
Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec
Мой опыт говорит о диаметрально противоположном. Если аппсеки занимаются всем триажом, у меня появляются вопросы к наличию и качеству необходимых процессов.
не правильно интерпретировал и неправильно исправил
Риск есть, но, опять таки, я бы посмотрел как вы справляетесь с перепроверкой каждого обработанного файндинга при наличие 200+ микросервисов и встраивании хотя бы тех классов инструментов в пайплайны, о которых я писал в статье - SAST/SCA/Secrets. Ну и "неправильно" исправить нужно еще и так, чтобы сканер при следующей проверке не стриггерился еще раз)
Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа
Это ваша точка зрения, имеет место быть, но у меня другая.
позволит помочь выбрать разработчику верное решение по устранению дефекта
Если речь не про архитектурные баги, в 90% случаев гуглится за минуту или же ответ находится прям в описании файндинга.
Очень сложно настроить все так, чтобы блокировки всегда были обоснованы
Блокировки всегда имеют понятное обоснование - наличие необработанных файндингов.
Вот этот пункт, тоже по факту не жизнеспособен в реальности
Возможно мы в разных реальностях)
А если произошла блокировка, а аппсек на обеде
Можно пожелать приятного аппетита)) В целом, опять же, разработчик сам может постараться решить проблему и в большинстве случаев так и происходит. Но, если все же не может, и речь про хотфиксы и пр, сейчас мы разрешаем кенселить джобы, при этом отписав аппсеку о том, что это произошло по определенной причине. Как только аппсек доест, наверняка поможет разобраться в проблеме и файндинг в какой-то перспективе будет обработан.
больше года триажим так файндинги.
Вот может в этом разница, не хочу вас задеть, но я просто работаю в команде где аппсек выстраивался более 17 лет, через многие вещи уже прошли и многое показало свою несостоятельность, и от этого отказались, либо наоборот как рабочий вариант и его и придерживаемся.
В целом конечно же нет единственно верного пути и какого то 100% верного решения, много зависит от объема проекта/ов и кодовой базы, наличия сильной аппсек команды, вменяемости разработчиков и т.д...
Далее, дабы не утонуть в спорах, в которых не всегда рождается истина, пожелаю вам и вашей команде удачи в этом нелегком деле :)
Вы таки внедрили сканеры безопасности в пайплайны — на этом все?