Я правильно понял, что вы просто ткнули пальцем в первого попавшегося ИТ-шника и сказали «теперь ты чемпион». Просто из:
Впереди:
развитие направления Security Champion в СИГМЕ — проведение курсов, повышение осведомленности и т.д.;
выглядит так, что у вас вдруг ни с того ни с сего появились чемпионы, которых вы ничему не обучали, ведь это только предстоит?
Или может расскажете по какому принципу выбирались эти чемпионы? По моему опыту даже при почти тысяче разработчиков ни бизнес ни ИТ не желают выделять кого-то в качестве чемпионов, а ИБ не готовы считать таковым кого угодно.
Каким образом сервис метрик помогает? Там видно какие команды выполняли изменения больше всего за месяц или как, чтобы? Ведь один сервис может разрабатывать десяток команд. Или просто руководство разработки видит оценки по сервисам и этого достаточно, далее оно просто говорит «в таком-то сервисе в следующем инкременте повысить оценку»?
Сканирование -> предобработка уязвимостей на основе конфигов DevSecOps -> отправка сырых/предобработанных отчетов от сканеров в DD -> дедупликация в том числе на основе предыдущих исключений в DD апсеками/разрабами -> возврат отчёта DD по репозиторию/сканеру с оставшимися уязвимостями в конвейер -> Quality gate принимает решение на основе содержимого уязвимостей от DD. Если надо внести исключение - оно вносится в DD, разраб перезапускает конвейер, и из DD уязвимость не прилетит, QG не лочит сборку. Затем при необходимости исключения переносятся в конфиги DevSecOps либо в сами сканеры при наличии у них собственных конфигов или UI. При необходимости срочно релизиться даже с уязвимостью, уязвимость в DD принимается разрабом/апсеком и при возврате списка уязвимостей из DD в конвейер возвращаются только не обработанные уязвимости (отклоненные и принятые не выгружаются, то есть возвращаются только явно необработанные), соответственно, сборка продолжается.
Правильно понимаю, всё проверки SAST вы запускаете не как валидационную сборку в мерж регвесте не давая тем самым завершить влитие уязвимого кода в защищаемую ветвь , а уже после влития на этапе сборки CI?
По чему так? Ведь это не позволяет делать красивые комментарии в мерж регвестах
Вопрос, а какой набор персданных требует вайлдберриз из гос услуг, весь набор с постоянным доступом как делают все или что-то конкретное?
Независимый аудит от компании из своего же скоупа?
Где скачать СИГМА:Алькор для iOS?
Я правильно понял, что вы просто ткнули пальцем в первого попавшегося ИТ-шника и сказали «теперь ты чемпион». Просто из:
выглядит так, что у вас вдруг ни с того ни с сего появились чемпионы, которых вы ничему не обучали, ведь это только предстоит?
Или может расскажете по какому принципу выбирались эти чемпионы? По моему опыту даже при почти тысяче разработчиков ни бизнес ни ИТ не желают выделять кого-то в качестве чемпионов, а ИБ не готовы считать таковым кого угодно.
И процент утверждающим pull request? Странная схема, за мошенничество можно притянуть я думаю легко.
Как иронично вы категоризировали решения SAST
Какие рекомендации для простых пользователей PyPi при скачивании пакетов, что проверять?
Правильно помню, в данном случае файлы из важных папок должны в облако засинхриться?
Попахивает фейком, 1018 сотрудников корпораций…
В корпорациях обычно работают десятки тысяч сотрудников. Дальше читать не стал.
Конечно про проверки правильность миграции, кода, чтобы отловить ошибки, которые могут возникнуть при обновлении бд
Тот же semgrep не дает ли вам множество фолзов, ведь как утверждают Solar и PT их сервисы находят уязвимости с меньшим количеством фолзов?
Разве увеличился time-to-market при реализации этапа 2?
Каким образом сервис метрик помогает? Там видно какие команды выполняли изменения больше всего за месяц или как, чтобы? Ведь один сервис может разрабатывать десяток команд. Или просто руководство разработки видит оценки по сервисам и этого достаточно, далее оно просто говорит «в таком-то сервисе в следующем инкременте повысить оценку»?
Какой сервис используете для сборки метрик безопасности ?
Почему вы не пошли путем такого конвейера:
Сканирование -> предобработка уязвимостей на основе конфигов DevSecOps -> отправка сырых/предобработанных отчетов от сканеров в DD -> дедупликация в том числе на основе предыдущих исключений в DD апсеками/разрабами -> возврат отчёта DD по репозиторию/сканеру с оставшимися уязвимостями в конвейер -> Quality gate принимает решение на основе содержимого уязвимостей от DD. Если надо внести исключение - оно вносится в DD, разраб перезапускает конвейер, и из DD уязвимость не прилетит, QG не лочит сборку. Затем при необходимости исключения переносятся в конфиги DevSecOps либо в сами сканеры при наличии у них собственных конфигов или UI. При необходимости срочно релизиться даже с уязвимостью, уязвимость в DD принимается разрабом/апсеком и при возврате списка уязвимостей из DD в конвейер возвращаются только не обработанные уязвимости (отклоненные и принятые не выгружаются, то есть возвращаются только явно необработанные), соответственно, сборка продолжается.
?
Правильно понял, что отказавшись от DD, вы теперь не собираете нигде статистику уязвимостей в одном месте?
Правильно понимаю, всё проверки SAST вы запускаете не как валидационную сборку в мерж регвесте не давая тем самым завершить влитие уязвимого кода в защищаемую ветвь , а уже после влития на этапе сборки CI?
По чему так? Ведь это не позволяет делать красивые комментарии в мерж регвестах
Какие вы рекомендуете валидационные проверки запускать в мерж регвесте, без выполнения которых разработчик не сможет закрыть мерж регвест?
Работал в СИБЭКО, как помню выходной оплачивался, куда уж там, оплачивалось даже замещение работника в размере 50% оклада замещаемого.
Законодательство вроде не менялось, пиратство как было им, так и останется