Middle: настроит манифест Deployment с проверками работоспособности, вынесет пароли и ключи в Secret, пропишет запросы и лимиты по CPU и памяти, настроит liveness- и readiness-пробы.
А можно нанять DevSecOps-а. Встроит все сканеры и ни один junior больше сможет скопипастить не выполнив все, что вы описали. Сканеры уязвимостей просто не дадут влить PR/MR новичка)
К вышеперечисленным практикам здесь стоит добавить аудит используемых пакетов для проверки их целостности, истории изменений и признаков компрометации, что помогает своевременно выявлять подобные аномалии.
проверки их целостности, так у вас в примерах "Ранее безопасные компоненты могут быть скомпрометированы", с какой SHA я должен сравнивать SHA только что опубликованного пакет?
истории изменений, я как-то занимался этим пол года, посидел, а CodeScoring этим занимется?
признаков компрометации, как это делать, требуется пройти курс вирусного аналитика или купить аналитика? Как вы помогаете в этом?
Так вы так и не написали как защищаться. Как защищаться то? Вот у меня OSA.Proxy, как с ее помощью защититься от:
Brandjacking -так дайте рекомендацию на примере ваших политик: например, если имя разработчика пакета содержит имя вашей организации и stage=proxy, то блокировать скачивание, элементарно же вместо "фиксация названий пакетов"
Combosquatting - пример политики CodeScoring, разработчик пакета не содержит имя вашей организации и содержит слова dev/test - отображать alert уровня warning?
Typosquatting - не представляю как, но у PT для python есть фид с сомнительными именами пакетов, может все же подскажете что-то конкретнее?
Манипуляции с пространством имён (namespace omission) - ну серьездно, вот как я и каким OSA/SCA решением должен защищаться? Вы правда предлагаете жестко фиксировать у себя где-то в базейке информацию о том, что каждый вендор каждой системы пакетов удалил свою организацию, как я буду следить за этим? Опять же фиксация пакетов никак не спасает, ведь имя организации не меняется, злоуышленник просто публикует пакет под "новой" версией пересоздав организацию, то есть имеем:
текущий пакет: gangsta_team/package_name@4.32.1
новый пакет, что нашел разработчик: gangsta_team/package_name@4.32.2
итого, бренд gangsta_team был удален, тут же хакер пересоздал его и опубликовал пакет package_name@4.32.2. Как меня защищает "фиксация названий пакетов"? Имя пакета и организация не менялись.
Галлюцинации систем ИИ (slopsquatting) - тут вообще мимо, так как и зачем используют ИИ? Отвечаю: что бы получить код и новую пачку зависимостей, ясно понятно, что использование ИИ пораждает изменение пакетов и не важно фиксируя и их или нет. Ну зафиксировал, ИИ мне порекомендовал что-то.
Вывод, возможно под "фиксация названий пакетов" вы имели строгий аудит изменения списка зависмостей в коде, при простой загрузке пакета из интернета чисто поиграться, "фиксация названий пакетов" никак не спасает потому, что я делаю npm install ИМЯ_ПАКЕТА не внося в файлы манифестов никакой информации. Плюс проверку на лету пакетов каким-то магическим инструментом, но каким и как я не понял (
фиксация названий пакетов
Так как это помогает??? ну вот есть lock файл, далее нерадивый разработчик находит пакет ошибившись в названии (пакет оказался СВП), скачивает, создает PR/MR для изменения зафиксированного списка зависимостей, PR/MR вливается, теперь среди зафиксированных зависимостей повляется, к примеру, Typosquatting пакет. Где и на каком этапе, что я должен сделать был? Как пример фиксации пакетов меня защитил? В lock файле бывает подтягивается за раз пара десятков изменений по пакетам, вы правда считаете, что кто-то каждое изменение lock файла должен анализировать и еще и умудриться понять был ли такой-то пакет из предлагаемых к изменению вредоносным.
Имея почти десятилетний опыт работы в Naumen, никому бы не рекомендовал, слишком долго грузится переход между страницами, процесс редактирования формы долгий, нет сохранения на лету, всегда нужно нажать «Редактировать», отредактировать и нажать «Сохранить».
результаты сканирования (payloads), отправляются в наш SOAR (StackStorm), откуда попадают в ASPM “базу данных” уязвимостей DefectDojo
ASPM видя уязвимости (findings) в коде или в библиотеках, триггерит SOAR (StackStorm), тот в свою очередь заводит Jira таски на исправление, а также результаты сканов отправляет в Slack канал команды
Зачем при первой же уязвимости генерить таски в Jira если AppSec еще не выполнил триад, разве не AppSec должен принимать решение о генерации Task?
Поэтому было решено, пару раз в неделю парсить наше локальное докер реджестри, где находим сервисы, билд которых старше 30 дней. И автоматически заводим Jira таски на пересборку (прохождение Security Gate) и перевыкатку сервиса
Почему бы просто не дергать конвейер сборки? Который далее стриеррит конвейер деплоя?
кнопка “Approve” триггерит в StackStorm runbook “pr_approve”, что в свою очередь разрешает мерж в мастер и выкатку нового релиза в production
Что происходит под капотом, можете рассказать подробнее? Запускается интеграци по API с Git системой в части перезапуска скана, который по результату проходит SG со статусом ОК и это не блокирует завершение PR?
А можно нанять DevSecOps-а. Встроит все сканеры и ни один junior больше сможет скопипастить не выполнив все, что вы описали. Сканеры уязвимостей просто не дадут влить PR/MR новичка)
проверки их целостности, так у вас в примерах "Ранее безопасные компоненты могут быть скомпрометированы", с какой SHA я должен сравнивать SHA только что опубликованного пакет?
истории изменений, я как-то занимался этим пол года, посидел, а CodeScoring этим занимется?
признаков компрометации, как это делать, требуется пройти курс вирусного аналитика или купить аналитика? Как вы помогаете в этом?
2. Путаница в названиях (name squatting)
А такое вообще возможно?
Так вы так и не написали как защищаться. Как защищаться то? Вот у меня OSA.Proxy, как с ее помощью защититься от:
Brandjacking - так дайте рекомендацию на примере ваших политик: например, если имя разработчика пакета содержит имя вашей организации и stage=proxy, то блокировать скачивание, элементарно же вместо "фиксация названий пакетов"
Combosquatting - пример политики CodeScoring, разработчик пакета не содержит имя вашей организации и содержит слова dev/test - отображать alert уровня warning?
Typosquatting - не представляю как, но у PT для python есть фид с сомнительными именами пакетов, может все же подскажете что-то конкретнее?
Манипуляции с пространством имён (namespace omission) - ну серьездно, вот как я и каким OSA/SCA решением должен защищаться? Вы правда предлагаете жестко фиксировать у себя где-то в базейке информацию о том, что каждый вендор каждой системы пакетов удалил свою организацию, как я буду следить за этим? Опять же фиксация пакетов никак не спасает, ведь имя организации не меняется, злоуышленник просто публикует пакет под "новой" версией пересоздав организацию, то есть имеем:
текущий пакет: gangsta_team/package_name@4.32.1
новый пакет, что нашел разработчик: gangsta_team/package_name@4.32.2
итого, бренд gangsta_team был удален, тут же хакер пересоздал его и опубликовал пакет package_name@4.32.2. Как меня защищает "фиксация названий пакетов"? Имя пакета и организация не менялись.
Галлюцинации систем ИИ (slopsquatting) - тут вообще мимо, так как и зачем используют ИИ? Отвечаю: что бы получить код и новую пачку зависимостей, ясно понятно, что использование ИИ пораждает изменение пакетов и не важно фиксируя и их или нет. Ну зафиксировал, ИИ мне порекомендовал что-то.
Вывод, возможно под "фиксация названий пакетов" вы имели строгий аудит изменения списка зависмостей в коде, при простой загрузке пакета из интернета чисто поиграться, "фиксация названий пакетов" никак не спасает потому, что я делаю npm install ИМЯ_ПАКЕТА не внося в файлы манифестов никакой информации. Плюс проверку на лету пакетов каким-то магическим инструментом, но каким и как я не понял (
Так как это помогает??? ну вот есть lock файл, далее нерадивый разработчик находит пакет ошибившись в названии (пакет оказался СВП), скачивает, создает PR/MR для изменения зафиксированного списка зависимостей, PR/MR вливается, теперь среди зафиксированных зависимостей повляется, к примеру, Typosquatting пакет. Где и на каком этапе, что я должен сделать был? Как пример фиксации пакетов меня защитил? В lock файле бывает подтягивается за раз пара десятков изменений по пакетам, вы правда считаете, что кто-то каждое изменение lock файла должен анализировать и еще и умудриться понять был ли такой-то пакет из предлагаемых к изменению вредоносным.
Вероятно, разработчики nginx его не осили?
Я думаю, что ваш пост ни о чем. Непонятно, что вы хотели написать. Если суть про
То так можно сказать по любого работника, будь то CIO
Ну не увольнять же iOS разработчиков
Замечено, что работает в МСК и Питере, дальше полный бан
Примерно это вы хотели нарисовать?
🤢🤮
Расшифруйте какое отношение эта фраза имеет к посту?
Имея почти десятилетний опыт работы в Naumen, никому бы не рекомендовал, слишком долго грузится переход между страницами, процесс редактирования формы долгий, нет сохранения на лету, всегда нужно нажать «Редактировать», отредактировать и нажать «Сохранить».
Личка закрыта, кажись слово
gurdrailпишется не такИнструменты понятные, но я не понимаю как это поможет защититься от нерадивого сетевика?
Получается никто не имеет права создавать PR в master кроме бота, который их делает только из stage?
Правильно понимаю, master статикой вообще не сканируете?
Зачем при первой же уязвимости генерить таски в Jira если AppSec еще не выполнил триад, разве не AppSec должен принимать решение о генерации Task?
Почему бы просто не дергать конвейер сборки? Который далее стриеррит конвейер деплоя?
Что происходит под капотом, можете рассказать подробнее? Запускается интеграци по API с Git системой в части перезапуска скана, который по результату проходит SG со статусом ОК и это не блокирует завершение PR?
Космос, когда увидим платный продукт или в составе PTAI?
Первым индикатором было поди наличие в коде whoami 😀