Size: a a a

DevSecOps - русскоговорящее сообщество

2020 July 18

rd

rus dacent in DevSecOps - русскоговорящее сообщество
Roman Rusakov
А я ж правильно понимаю что с сонаром воркфлоу примерно такой: запустил первый раз, потом неделю-две добавил в исключения все что можно и нельзя, потом осталось допустим 3% от того что нарисовало сначала - и тут уже можно работать?
Я так делал один раз, а один раз пришел на готовый а там уже из проекта только одна маленькая папочка сканировалась
Репорты разгребаешь, ага. Постепенно false positive в общей массе уменьшается и с остатком уже можно работать. Но это обязательно делать нужно процессом.
источник

rd

rus dacent in DevSecOps - русскоговорящее сообщество
Yury Shabalin
Ну вообще это абсолютно нормальная практика, после первого прогона скана, например, статики, всё что насканилось называется техническим долгом команды ИБ, который нужно разобрать. Он методично и потихоньку своими силами или третьей стороны разбирается и только актуальные баги заносятся в Jira.

А вот сканирование нового кода или инкременты на пуллреквесты могут дать хороший результат. То есть мы не закидывает команду сразу отчётом на 3 тыщи страниц, а говорим, что вот в новом коде так писать не стоит. И поправить это проще и быстрее, так как фича ещё в разработке и не вызывает такого негатива.
+
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Мне кажется (гадаю как обычно) что Олег намекает что стоит просто заняться тем что уже нашли прежде чем тратить время на инструменты для поиска и сортировки новых
источник

A

Anton in DevSecOps - русскоговорящее сообщество
Скорее подход Юрия более жизнеспособен) Исправить то, чему срок условная неделя проще, чем то, чему уже 2 года)
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
Постепенно куча результатов превращается в некоторые дефекты в жире, причем даже не один к одному, а группируются, анализируются, обогащаются инфой и попадают уже в виде красивых и понятных багов к разрабам. А дальше устраняются в порядке приоритета наравне с функциональными багами.
источник

rd

rus dacent in DevSecOps - русскоговорящее сообщество
Anton
Скорее подход Юрия более жизнеспособен) Исправить то, чему срок условная неделя проще, чем то, чему уже 2 года)
Это да, но возможно тому что уже 2 года и исправлять не надо =)
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Так а смысл исправлять запятые? Вы ж сами пишете что баги нужно ранжировать по критичности, ну типа админка без пароля
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
Ведь нельзя выйти в пром с критикалалом функциональным (в идеале), так же и не стоит выходить с критикалом в ИБ части)
источник

A

Anton in DevSecOps - русскоговорящее сообщество
rus dacent
Это да, но возможно тому что уже 2 года и исправлять не надо =)
Тоже верно) И держать в голове, что только в идеальном мире все устранено, к этому добру можно и "принятие/exceptions" добавить
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
Roman Rusakov
Так а смысл исправлять запятые? Вы ж сами пишете что баги нужно ранжировать по критичности, ну типа админка без пароля
Ну таки да) занимаемся тем, что важно) и в принципе без разницы, функциональность или баги или дефекты ИБ
источник

A

Anton in DevSecOps - русскоговорящее сообщество
Roman Rusakov
Так а смысл исправлять запятые? Вы ж сами пишете что баги нужно ранжировать по критичности, ну типа админка без пароля
Так никто не говорит за все. Отсканили, получили пачку, удалили фолсы, из оставшегося множества выбрали критичное и устранимое - задачи первой очередности и так далее
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
rus dacent
Это да, но возможно тому что уже 2 года и исправлять не надо =)
Ну, возможно и стоит, но с подходом, что мы сначала пытаемся предотвратить появление новых, чтобы техдолг не разрастался
источник

rd

rus dacent in DevSecOps - русскоговорящее сообщество
Yury Shabalin
Ну, возможно и стоит, но с подходом, что мы сначала пытаемся предотвратить появление новых, чтобы техдолг не разрастался
Ага.
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Делать пул реквесты красными?
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Типа quality gate?
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Для этого нужны стальные яйца)
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
И отсутствие ложных срабатываний
источник

rd

rus dacent in DevSecOps - русскоговорящее сообщество
Roman Rusakov
Для этого нужны стальные яйца)
Да не, нормально =)
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
Roman Rusakov
Делать пул реквесты красными?
Не обязательно сразу, но к этому можно прийти. Тут важно разговаривать с разработкой. Что типо мы сейчас включим проверку, она будет вас информировать, писать вам комменты в пулл реквест на возможные срабатывания
источник

YS

Yury Shabalin in DevSecOps - русскоговорящее сообщество
Посмотреть, что фалзов немного/много, подтюнить слегка правила может и дальше, когда все попривыкнут, можно и стопить.
источник