А вы по oauth синхронизируете иерархию проектов из гитлаба согласно составу?
У нас поздний АД был на гитлабе, по сути структура гитлаба формирует премиссы для инструментов ИБ.
Не кажется костыльным подходы? В том плане, что можно же организовать эндпойнт по середине который мог бы вопервых сопровождать создание проектов забирая из гитлаба минимальные свойства, во вторых сократить кол-во access key гуляющих по рукам и упростить настройку нового репо (допустим достаточно было бы просто имя коммитера + свойство репо имя, id, группа. Отлавливаем отчеты, там же допустим конвертируем и грузим в необходимый инструмент/проект обозначая авторов и данные о иерархии. Иначе говоря если прям совсем упростить - разработчику понадобиться лишь эндпойнт адрес этого распределителя ну и скажем что ключик общий на гитлаб для шифрования передачи всех этих данных.
идея в том чтобы унифицировать и избавиться от гуляющих токенов. если бы у нас было бы пару сотен разрабов.... плюс токены по хорошему должны иметь ограниченный цикл жизни (как по дефолту 30 дней в сонаре), но конечно же его выпускают бещ срока скорее всего...
Кстати, вопрос по хранению DAST reports например от ZAP.
Как вы выбираете DD product для dast репортов, если тестируется api или сайт в целом, который может состоять из кучи репозиториев (микросервисы). У нас в DD продукты мапятся на репозитории. Мб есть смысл создавать отдельный dd продукт, с именем домена или еще как, и уже туда загружать репорты? Мб кто-то имеет похожую проблему.
Все варианты имеют право на жизнь, но я все таки пошел в сторону бесконечно живущих engagement'ов, именованных по имени ветки. Ну и дедупликация на уровне eng.
Иначе было бы сложно трекать уязы когда у тебя все сливается в кучу, да еще с включенным дедупом на уровне проекта.
А что делает дженкинс, например в связке gitlab cicd + sq + dojo, часто вижу туда еще и дженкинс подкидывают, для какой цели?
Читать полностью…Привет. Примерно вот https://roadmap.sh/devops
Зависит от того, какие знания есть на данный момент. Обычно девопс не учат с 0, а вкатываются из другой профессии, которая дала базу, как из сисадмина. Иначе ,с современной скоростью изменений в айти можно попасть в цикл, когда только что то изучил -оно уже не актуально . Если есть знакомые девопсы,можно у них спросить, есть ли вакансия с обучением и на ходу прямо учиться. В идеале поднять свою инфру дома и на ней тренироваться плюс интерактивные базовые уроки с сайта кубера и хашикорпа.
Конечно совсем без токенов не выйдет, как же issue, но хотя бы чисто из процесса cicd
Читать полностью…2018) да я в целом, от всяких 1с-ников до джетов. Хвалят его, а за что а изза чего не говорят :) Решил на всякий убедиться. Гитлаба более чем достаточно. Боль лишь остается в сборке докеров в докер раннерах. Кубер бы...
Читать полностью…у нас корневая группа репозитория = product type, проект/микросервис внутри группы = product, каждый вид теста - engagement, внутри engagements - бъются по типу сканера. тесты dast - мапятся на репозиторий, т.к. запускаются в пайпе репозитория конкретного репозитория
Читать полностью…бесспорно. Может там legacy просто? Сборки в jenkins были давно. Работает, не трогай)
Читать полностью…У нас сделано так же, только engagement'ы побили на sast, sca, dast
Просто, когда есть несколько последовательных сканов - тяжело разобраться, почему дефект предыдущего скана в текущем - пропал, точнее - он пропал из-за того что исправили или код так поменялся, что дефект теперь в другое место переехал
Единственный кейс может быть это автоматическое создание проектов в сонаре. В доке сонора описан процесс с дженкинсом и мол в этой связке при первом скане создаст в сонаре проект если его не было
Читать полностью…привет
мы используем 1 engament на 1 ветку
т.е. если тестишь master branch, загружаешь репорты в master eng всегда
Всем привет. А расскажите пжл, у кого есть опыт с DefectDojo, кто как понимает engagements? Исходя из описания в доке это промежуток времени, в течении которого происходит тестирование. Эта логика неплохо накладывается на некие ручные тестирования, но не понятно как применить к CI. По логике - создавать под каждый build_id свой engagement? Не умрет ли DD от такого? Или мб создать какой то долгоживущий engagement на каждую ветку и в нем уже делать reimport к примеру чтобы не плодить тесты?
Читать полностью…