Pull to refresh
12
0

Cybersecurity evangelist

Send message

Конечно про проверки правильность миграции, кода, чтобы отловить ошибки, которые могут возникнуть при обновлении бд

Тот же 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% оклада замещаемого.

Законодательство вроде не менялось, пиратство как было им, так и останется

Специально на туристическую сниму завел в вк аккаун

Так почему бы мою рекомендацию не добавить в статью первым или последним пунктом?

Стоп, а где самая главна рекомендация № 8:

Отлеживайте регистрацию доменов, похожих на ваши, и моментально вносите их в список вредоносных.

Так вы уже проактивно защищаете свою компанию от большого процента фишинга, разве ваш SOC не должен об этом знать?

Они правда реализовали это не совсем понятно ибо в конвейере вообще не понятно, что за уязвимость, что разрабов ввело в замешательство, как видно из скриншота нет никакой информации об уязвимости в консоли конвейера. При просмотре же уязвимостей у билда в Artifactory она не отображалась из-за настроенных у нас watches, но при выгрузке pdf отчета она отображается… Возможно, поправят в скором времени.

Красным выделил индикаторы данной уязвимости у Jfrog Xray.

Jfrog Xray Scan/Audit показывает у нас так:

Jfrog Xray Scan/Audit
Jfrog Xray Scan/Audit

Jfrog Xray отчет:

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

Михаил, я так и не понял что делает Chainloop в конвейере сборки. Можете совсем простыми словами описать? Собирает SBOM и provenance, все это подписывает и докладывает в итоговй билд или метаданные в хранилище пакетов? Затем кто угодно через интерфейс Chainloop, например, конвейер деплоя может проверить соответствие метаданных пакета перед деплоя каким-то политикам ИБ?

Практика SAST также хорошо автоматизируется и легко встраивается в CI/CD, его результаты также можно рассматривать в рамках общего анализа пакета на вредоносность.

Владимир, но ведь PT, Solar и другие как бы не обманывали, они не ищут на само деле ни ВПО ни protestware. Они просто не выдадут никаких результатов по части НДВ или я ошибаюсь?

Information

Rating
3,504-th
Location
Россия
Works in
Registered
Activity