🛠 WSO2 MI/ APIM с точки зрения AppSec
Салют,
Что то душновато было на прошлой неделе,
Надеюсь у меня одного так было, ну и мемасики были полезны для тебя, иногда же надо мозг расплавить 🙃
Часто в практике и при исследовании кейсов по интеграциям я смотрю в сторону WSO2, еще со времен РБ, поэтому сейчас хочу рассказать почему это решение имеет преимущество. WSO2 воспринимается всегда как очередной ESB и API‑шлюз, но для безопасной архитектуры это классный слой между внешним и внутренним сегментом сети.
Фича для AppSec в том, что бы Security‑политики были как конфигурация, а не код. Пароли, сертификаты, правила подписи/ шифрования и аутентификации оформляются как политики и артефакты MI/ APIM, версионируются и проходят code‑review как часть инфраструктурного кода. AppSec Toolchain сканирует как API‑слой, так и интеграционные сервисы в MI. То есть логи MI/ APIM идут в SIEM, где можно строить корреляцию между уязвимостями и реальным трафиком. Zero‑trust‑подход на интеграционном уровне.
Ключевые фичи
Типовой контур, который дает защиту всего потока API‑вызовов через общие политики
Итого
Сноска
#appsec #pmicases #devsecops #techsolution #reco #toolchain
Салют,
Что то душновато было на прошлой неделе,
Надеюсь у меня одного так было, ну и мемасики были полезны для тебя, иногда же надо мозг расплавить 🙃
Часто в практике и при исследовании кейсов по интеграциям я смотрю в сторону WSO2, еще со времен РБ, поэтому сейчас хочу рассказать почему это решение имеет преимущество. WSO2 воспринимается всегда как очередной ESB и API‑шлюз, но для безопасной архитектуры это классный слой между внешним и внутренним сегментом сети.
Micro Integrator отвечает за интеграцию и обмен данными (можно навесить аутентификацию, авторизацию, WS‑Security, шифрование, логирование и трансформацию трафика до того, как он попадёт в бизнес‑сервисы), а API Manager за публикацию и защиту, управление доступом, трафиком и разработчиками ( по факту граница для всех HTTP/ REST/ gRPC API с OAuth2/ OIDC, JWT, rate‑limit и тд).
Фича для AppSec в том, что бы Security‑политики были как конфигурация, а не код. Пароли, сертификаты, правила подписи/ шифрования и аутентификации оформляются как политики и артефакты MI/ APIM, версионируются и проходят code‑review как часть инфраструктурного кода. AppSec Toolchain сканирует как API‑слой, так и интеграционные сервисы в MI. То есть логи MI/ APIM идут в SIEM, где можно строить корреляцию между уязвимостями и реальным трафиком. Zero‑trust‑подход на интеграционном уровне.
Ключевые фичи
• Аутентификация и авторизация на уровне интеграции — можно проверять username, token, роли и права до обращения к backend, в том числе через WS‑Security
• Шифрование и подпись SOAP/ WS сообщений, до 16 типовых сценариев WS‑Security (sign, encrypt, username token, X.509 и их комбинации)
• Шифрование и управление секретами через keystore/ truststore — защита SSL/ mutual TLS, ключей и паролей, отказ от дефолтных хранилищ
• Валидация и санитайзинг данных: проверка XSD/ JSON‑схем, фильтрация полей, вырезание чувствительных данных до логирования
• Централизация интеграционных политик
Типовой контур, который дает защиту всего потока API‑вызовов через общие политики
• Клиенты/ партнёры стучатся через WSO2 APIM
• APIM аутентифицирует запрос в зависимости от политики, валидирует токены, применяет throttling, IP‑фильтры, CORS и др.
• Запрос идёт в микросервис, либо в WSO2 MI, где выполняются интеграционные потоки: маршрутизация, обогащение, трансформация, вызовы систем
• На уровне MI включаются WS‑Security, подпись и шифрование сообщений, дополнительная аутентификация/ авторизация, проверка схем и валидация полезной нагрузки
• Все события уходят в логи, а метрики и ошибки — в аналитику APIM и платформенный мониторинг
Итого
• WSO2 как способ собрать безопасность и интеграцию в единый управляемый слой
• Единый периметр для API и интеграций
• Меньше уязвимостей в приложениях
• Команды фокусируются на бизнес‑логике, а типовые задачи интеграции и безопасности решаются готовыми фичами WSO2 MI/ APIM; новые интеграции добавляются конфигурацией, а не кастомным кодом
• Из коробки есть трейсинг вызовов, метрики, логирование и аналитика по API
• WSO2 заточен под сценарии, когда есть и облако, и on‑prem, и микросервисы, и старые SOAP‑системы
Сноска
• ESB (Enterprise Service Bus) - интеграционная шина, то есть централизованный программный слой, который подключает разнородные приложения и сервисы, беря на себя маршрутизацию, трансформацию и безопасность сообщений между ними.
• API‑шлюз (API Gateway) - единая точка входа для API‑клиентов, обратный прокси перед набором backend, который принимает запросы, маршрутизирует их к сервисам, агрегирует ответы и одновременно реализует политики безопасности (аутентификация, авторизация, rate limiting, мониторинг)
#appsec #pmicases #devsecops #techsolution #reco #toolchain
🔥5
🤔 WSO2 InfoSec Reco
Салют, давай в догонку, с тобой, ко вчерашнему посту, посмотрим на требования ИБ, которые помогут нам при интеграциях.
Эти требования позволят снизить риски связанные с киберпреступлениями, утечками, не соответствия Compliance. Требования рассматриваем ближе для финтех‑интеграций.
Поделюсь именно своей подборкой, которая поможет тебе предусмотреть массу проблем, с которыми не придется дальше разбираться.
• Учитывать стандарты безопасности Открытых API
• ГОСТ 57580.1 и процессы
• Требования по персональным данным
• Архитектурные требования
• Дополнение
#reco #devsecops #pmicases #specialty #techsolution #compliance #paper
Салют, давай в догонку, с тобой, ко вчерашнему посту, посмотрим на требования ИБ, которые помогут нам при интеграциях.
Эти требования позволят снизить риски связанные с киберпреступлениями, утечками, не соответствия Compliance. Требования рассматриваем ближе для финтех‑интеграций.
Поделюсь именно своей подборкой, которая поможет тебе предусмотреть массу проблем, с которыми не придется дальше разбираться.
• Учитывать стандарты безопасности Открытых API
— СТО БР ФАПИ.СЕК‑1.6‑2024 (безопасность OpenID API)
— СТО БР ФАПИ.ПАОК‑1.0‑2024 (аутентификация по отдельному каналу)
• ГОСТ 57580.1 и процессы
— Для фин информации и ПДн применять состав мер ГОСТ 57580.1: защита каналов, контроль доступа, регистрация событий, управление уязвимостями, обеспечение целостности и актуальности ПО
— Логи WSO2 и бэкенд‑сервисов по API должны попадать в централизованный журнал
— Для каждого API, обрабатывающего ПДн, должна быть проведена оценка рисков ИБ в рамках 57580.1 и внутренних политик по 152‑ФЗ
• Требования по персональным данным
— Факт передачи ПДн через WSO2 должен быть отражён в договорных документах и в перечне информационных систем ПДн, и трансграничных передач
— Внутренние документы должны описывать порядок уведомления Роскомнадзора об инцидентах с ПДн (72 часа на расследование и отчёт) и ответственность ролей
— Для API, где минимально возможен объём ПДн, следует применять минимизацию, маскировку и обезличивание: передавать только необходимый набор атрибутов, а также, где можно, использовать токены/ псевдонимы вместо прямых идентификаторов клиента
• Архитектурные требования
— Настроить WSO2 с использованием HTTPS/ TLS 1.2+ с Forward Secrecy для всех публичных endpoint’ов, включить проверку клиентских сертификатов, если используется mutual TLS
— Использовать OAuth 2.0 + OpenID Connect как основной механизм аутентификации клиентов API (в соответствии с ФАПИ.СЕК), ограничивать доступ по scope/ role и, при необходимости, по IP/ ASN
— Обеспечить защиту от типичных атак на API: rate limiting, throttling, защита от replay‑атак, CSRF, injection, а также валидацию схемы JSON/ REST
• Дополнение
— Для каждого интеграционного кейса должна быть выполнена модель угроз и оценка рисков с фиксацией мер защиты в архитектуре
— Необходим отдельный регламент «Управление внешними интеграциями», описывающий: жизненный цикл API, ответственность Integration Layer, порядок ревью ИБ и архитекторов, требования к логированию и мониторингу
— Нужен регламент по управлению уязвимостями и интеграционных сервисов: периодичность сканов, порядок установки обновлений, SLA по устранению критичных уязвимостей
— Доступ с BYOD во внутренний контур должен быть ограничен путем контроля привелегированных пользователей путем Segregation-of-Duties
— Необходимо реализовать отсутствие прав доступа во внутренним системам
— Предшествующая аутентификация является необходимой для источников данных и при ее отсутствии, используемые каналы связи и используемые ресурсы должны быть зашифрованы (блокировка целостности, шифрование, контроль источника и т.п.)
— Все файлы, которые передаются (также для последующих случаев - в обе стороны, если будут использоваться) должны быть зашифрованы и проходить через песочницу
— Доступ к данным по id из внешнего периметра должен исключать инкрементальный id
— При проектировании API через WSO2 ориентироваться на профили безопасности OpenID/ OAuth2: обязательно TLS, защищённое хранение и передача токенов, защита от подмены запросов/ ответов
#reco #devsecops #pmicases #specialty #techsolution #compliance #paper
🔥6
🏆 Информационная безопасность на всех этапах жизненного цикла разработки ПО
Салюты, напомню, что стартует, совсем скоро курс по МФТИ, поделюсь расписанием вот тут.
А пока ты можешь покачаться на лабках, которые скоро получат новый релиз и будут также обкатываться на МФТИ.
Почекай лабки тут.
—————————————————————
🗓 Сроки обучения:
23 марта – 05 мая 2026 г.
⏰ Время занятий:
18:00 – 19:30 / 20:30 / 21:30
—————————————————————
🔰 НЕДЕЛЯ 1 | Основы ИБ и защиты информации ИС
• 23.03 (Пн) | Вводная лекция | 1 ак.ч. | 18:00-18:45 | Zoom
• 24.03 (Вт) | Лекция 1 и 2 | 4 ак.ч. | 18:00-21:30 | Zoom
• 26.03 (Чт) | ПР 1 и Лекция 3 | 2 ак.ч. | 18:00-19:30 | Zoom
🔰НЕДЕЛЯ 2 | Обследование ИС, анализ уязвимостей и угроз
• 31.03 (Вт) | Лекция 4 | 2 ак.ч. | 18:00-19:30 | Zoom
• 02.04 (Чт) | Лекция 5 и ПР 2 | 2 ак.ч. | 18:00-19:30 | Zoom
🔰НЕДЕЛЯ 3 | Формирование и реализация требований по ИБ к ИС
• 07.04 (Вт) | Лекция 6 и 7 | 4 ак.ч. | 18:00-21:30 | Zoom
• 09.04 (Чт) | Лекция 8 и ПР 3 | 2 ак.ч. | 18:00-19:30 | Zoom
—————————————————————
⬅️ НЕДЕЛЯ 4 | Shift-Left: от анализа до требований ИБ
• 15.04 (Ср) | Лекция 9 и ПР 4 | 3 ак.ч. | 18:00-20:30 | Zoom
• 17.04 (Пт) | Лекция 10 и 11 | 3 ак.ч. | 18:00-20:30 | Zoom
⬅️ НЕДЕЛЯ 5 | Жизненный цикл безопасной разработки ПО
• 22.04 (Ср) | Лекция 12 и 13 | 4 ак.ч. | 18:00-21:30 | Zoom
• 24.04 (Пт) | ПР 5 и Лекция 14 | 3 ак.ч. | 18:00-20:30 | Zoom
🎯 НЕДЕЛЯ 6 | Завершение
29.04 (Ср) | Лекция 15 и ПР 6 | 3 ак.ч. | 18:00-20:30 | Zoom
—————————————————————
🏆 Защита итоговой работы
—————————————————————
#course #devsecops #appsec #toolchain
Салюты, напомню, что стартует, совсем скоро курс по МФТИ, поделюсь расписанием вот тут.
А пока ты можешь покачаться на лабках, которые скоро получат новый релиз и будут также обкатываться на МФТИ.
Почекай лабки тут.
—————————————————————
🗓 Сроки обучения:
23 марта – 05 мая 2026 г.
⏰ Время занятий:
18:00 – 19:30 / 20:30 / 21:30
—————————————————————
🔰 НЕДЕЛЯ 1 | Основы ИБ и защиты информации ИС
• 23.03 (Пн) | Вводная лекция | 1 ак.ч. | 18:00-18:45 | Zoom
• 24.03 (Вт) | Лекция 1 и 2 | 4 ак.ч. | 18:00-21:30 | Zoom
• 26.03 (Чт) | ПР 1 и Лекция 3 | 2 ак.ч. | 18:00-19:30 | Zoom
🔰НЕДЕЛЯ 2 | Обследование ИС, анализ уязвимостей и угроз
• 31.03 (Вт) | Лекция 4 | 2 ак.ч. | 18:00-19:30 | Zoom
• 02.04 (Чт) | Лекция 5 и ПР 2 | 2 ак.ч. | 18:00-19:30 | Zoom
🔰НЕДЕЛЯ 3 | Формирование и реализация требований по ИБ к ИС
• 07.04 (Вт) | Лекция 6 и 7 | 4 ак.ч. | 18:00-21:30 | Zoom
• 09.04 (Чт) | Лекция 8 и ПР 3 | 2 ак.ч. | 18:00-19:30 | Zoom
—————————————————————
⬅️ НЕДЕЛЯ 4 | Shift-Left: от анализа до требований ИБ
• 15.04 (Ср) | Лекция 9 и ПР 4 | 3 ак.ч. | 18:00-20:30 | Zoom
• 17.04 (Пт) | Лекция 10 и 11 | 3 ак.ч. | 18:00-20:30 | Zoom
⬅️ НЕДЕЛЯ 5 | Жизненный цикл безопасной разработки ПО
• 22.04 (Ср) | Лекция 12 и 13 | 4 ак.ч. | 18:00-21:30 | Zoom
• 24.04 (Пт) | ПР 5 и Лекция 14 | 3 ак.ч. | 18:00-20:30 | Zoom
🎯 НЕДЕЛЯ 6 | Завершение
29.04 (Ср) | Лекция 15 и ПР 6 | 3 ак.ч. | 18:00-20:30 | Zoom
—————————————————————
🏆 Защита итоговой работы
—————————————————————
#course #devsecops #appsec #toolchain
🔥7
🛠 Карта DevSecOps Toolchain
Салют,
Хорошие новости, я как то рассказывал про карту инструментов тут.
Наконец то ее залили в релизе 2.0.1 в репозиторий нашего сообщества findevsecops.ru, почекай.
Сейчас будет буст самой карты инструментов и ты можешь поучаствовать с нами в развитии этого дела, я планирую еще дорабатывать репу и развивать, так как это оч классная штука для твоего роста и отраслевого контроля тулов, которые помогают в достижении целей безопасной разработки ПО.
Сам репозиторий у нас с тобой вот тут для сообщества, а мой корневой, который прям родительский тут - его качаем как dev.
Захотел поделиться с тобой этой инфой, потому что это очень классно для нас с тобой 😉
Всем спасибо
#appsec #toolchain #devsecops #specialty #techdolution
Салют,
Хорошие новости, я как то рассказывал про карту инструментов тут.
Наконец то ее залили в релизе 2.0.1 в репозиторий нашего сообщества findevsecops.ru, почекай.
Сейчас будет буст самой карты инструментов и ты можешь поучаствовать с нами в развитии этого дела, я планирую еще дорабатывать репу и развивать, так как это оч классная штука для твоего роста и отраслевого контроля тулов, которые помогают в достижении целей безопасной разработки ПО.
Сам репозиторий у нас с тобой вот тут для сообщества, а мой корневой, который прям родительский тут - его качаем как dev.
Захотел поделиться с тобой этой инфой, потому что это очень классно для нас с тобой 😉
Всем спасибо
#appsec #toolchain #devsecops #specialty #techdolution
❤🔥6🔥5
🏆 Испытания ФСТЭК России ГОСТ 71207
Я как то ранее писал про эти испытания тут, что мы в ЛАНИТ с моими ребятами получили грамоту на нашу компанию за вклад, который внесли, а теперь подьехала очень приятная история, еще одна. Люблю когда так мотивирует, согласись, приятно же?
Очень рад с тобой делиться таким 🙏
#appsec #devsecop #specialty #toolchain #sast #conf #meetup #compliance #gost #paper
Я как то ранее писал про эти испытания тут, что мы в ЛАНИТ с моими ребятами получили грамоту на нашу компанию за вклад, который внесли, а теперь подьехала очень приятная история, еще одна. Люблю когда так мотивирует, согласись, приятно же?
Очень рад с тобой делиться таким 🙏
#appsec #devsecop #specialty #toolchain #sast #conf #meetup #compliance #gost #paper
🔥11
🏆 geminishkv.tech
UwU, короче сделал тут сайтик для себя, хочу поделиться с тобой, считаю получилось особенно прикольно с глитчем, адаптивка отдельно доставила.
geminishkv.tech - чекай, но конечно простенько, но эффекто для портфолио 🙃
#paper #appsec #devsecops
UwU, короче сделал тут сайтик для себя, хочу поделиться с тобой, считаю получилось особенно прикольно с глитчем, адаптивка отдельно доставила.
geminishkv.tech - чекай, но конечно простенько, но эффекто для портфолио 🙃
#paper #appsec #devsecops
🔥10❤🔥7
🤔 InfoSec Reco СУБД
Салют,
Думаю сегодня классно будет посмотреть, вместе, на то как лучше подойти к защищенности БД, брокеру очередей для записи в БД и, конечно, частично к frontend части при взаимодействии с БД.
Мои реко строятся на базе опыта и того, что я чаще всего замечаю, надеюсь, для твоей практики, это будет полезно и ты сможешь более глубоко и сразу смотреть в правильном направлении, - потому что это важно при анализе и не важно аналитики ты или инженер, главное понимать архитектуру и как это построено. В некоторых пунктах отмечу, что плохо и думаю ты поймешь почему.
Реляционные СУБД
Redis и in-memory cache
Очереди и брокеры сообщений
JavaScript и frontend
#reco #devsecops #appsec #specialty
Салют,
Думаю сегодня классно будет посмотреть, вместе, на то как лучше подойти к защищенности БД, брокеру очередей для записи в БД и, конечно, частично к frontend части при взаимодействии с БД.
Мои реко строятся на базе опыта и того, что я чаще всего замечаю, надеюсь, для твоей практики, это будет полезно и ты сможешь более глубоко и сразу смотреть в правильном направлении, - потому что это важно при анализе и не важно аналитики ты или инженер, главное понимать архитектуру и как это построено. В некоторых пунктах отмечу, что плохо и думаю ты поймешь почему.
Реляционные СУБД
• Плохая практика: выдавать приложению db_owner, sysadmin или доступ на всю схему без ограничений
• Чувствительные данные хранить так, чтобы прямой доступ к базовым таблицам был ограничен: использовать views, stored procedures или сервисный слой
• Размещать СУБД в отдельном сетевом сегменте и запрещать прямой доступ из внешних и полупубличных зон
• Плохая практика: использовать plaintext-подключения или отключать проверку сертификата
• Включать аудит критичных операций: чтение, изменение, удаление, DDL-изменения и административные действия
• Строки подключения, ключи и пароли хранить только во внешнем хранилище секретов.
• Использовать отдельные учётные записи для каждого приложения и среды, без shared-паролей между командами
• Никогда не передавать пользовательский JSON напрямую в фильтры запросов без проверки и нормализации
• Использовать типизированные запросы, драйверные API или строго ограниченные схемы фильтрации
• При работе с произвольными документами проверять, что в них нет операторов, начинающихся с $, и других опасных конструкций
• Плохая практика: пропускать $where, $gt, $regex и похожие операторы без whitelist
Redis и in-memory cache
• Привязывать сервис только к внутренним интерфейсам и не публиковать его в публичную сеть
• Плохая практика: слушать 0.0.0.0 и оставлять Redis доступным извне
• Обязать аутентификацию и использовать длинные случайные пароли или эквивалентный механизм авторизации
• Плохая практика: оставлять доступными FLUSHALL, CONFIG, EVAL, SCRIPT, DEBUG
• Плохая практика: выдавать приложению полный ACL или использовать один пользователь для всех ролей.
• Использовать namespace-префиксы для ключей, чтобы изолировать кэши, сессии и служебные данные
• Не хранить в Redis долгоживущие секреты или критичные данные без дополнительной защиты
Очереди и брокеры сообщений
• Плохая практика: оставлять guest или аналогичные заводские учётки
• Создавать отдельных пользователей для producer, consumer и административных задач
• Изолировать окружения через отдельные virtual host/ namespace/ tenant-механизмы, если они поддерживаются
• Плохая практика: смешивать dev, test и prod в одном пространстве имён
• Producer должен иметь право только на публикацию в разрешённые exchange или topic
• Consumer должен иметь право только на чтение из разрешённых очередей и не должен публиковать сообщения
• Проверять сертификаты клиентов и сервера, если брокер используется в чувствительном контуре
• Ограничивать размер сообщений и задавать квоты, чтобы снизить риск flooding и abuse
JavaScript и frontend
• Не использовать опасные DOM-операции с пользовательским вводом: innerHTML, outerHTML, document.write
• Любой HTML, пришедший извне, санитайзить перед отображением
• Запрещать небезопасные redirect-механизмы на основе пользовательского ввода без whitelist
• Применять CSP с минимально необходимыми источниками и без unsafe-inline, где это возможно
• Для inline-скриптов использовать nonce или hash-подход
• Для внешних библиотек и CDN использовать Subresource Integrity
• Плохая практика: грузить библиотеку с CDN без проверки целостности
#reco #devsecops #appsec #specialty
🔥5
Forwarded from Proxy Bar
When Local AI Becomes an Attack Vector: A Deep Dive into LLM Infrastructure Security
Original text by Charles Senges
The article “Deep dive into the deployment of an on-premise low-privileged LLM server” by Synacktiv examines how organizations deploy internal Large Language Model (LLM) servers and analyzes the security implications of running such systems inside corporate infrastructure. The researchers study a real deployment where an open-source LLM is hosted on-premise…
https://core-jmp.org/2026/03/when-local-ai-becomes-an-attack-vector-a-deep-dive-into-llm-infrastructure-security/
Original text by Charles Senges
The article “Deep dive into the deployment of an on-premise low-privileged LLM server” by Synacktiv examines how organizations deploy internal Large Language Model (LLM) servers and analyzes the security implications of running such systems inside corporate infrastructure. The researchers study a real deployment where an open-source LLM is hosted on-premise…
https://core-jmp.org/2026/03/when-local-ai-becomes-an-attack-vector-a-deep-dive-into-llm-infrastructure-security/
🛠 Security SBOM generator with vulnerability chechup
Салют,
Сегодня хочу поделиться тулой, которую покрутил на выхах. Эта тула помогает быстро и в более удобном виде собирать SBOM для проекта, это будет особенно полезно для сертификации по ФСТЭК России, включая контроля твоего supply-chain.
Именно такой подход хорошо ложится на практики, где SBOM генерится автоматически из репозитория или сборочного артефакта, а потом используется дальше в пайплайнах и системах контроля.
Как работает?
Функционально
Зачем?
Планирую докрутить
Links
• PyPi
• DockerHub
• Github Package
Структура
#appsec #devsecops #specialty #toolchain #techsolution #paper #sbom
Салют,
Сегодня хочу поделиться тулой, которую покрутил на выхах. Эта тула помогает быстро и в более удобном виде собирать SBOM для проекта, это будет особенно полезно для сертификации по ФСТЭК России, включая контроля твоего supply-chain.
Тула построена так, что бы ручками не ковыряться в зависимостях, а получать нормальную структурированную картину по составу софта. то есть понятная карта компонентов, версий и метаданных, которая дальше помогает с аудитом, рисками supply chain и проверкой уязвимостей по каждому компоненту.
Именно такой подход хорошо ложится на практики, где SBOM генерится автоматически из репозитория или сборочного артефакта, а потом используется дальше в пайплайнах и системах контроля.
Как работает?
• Генерирует SBOM по проекту в одном из стандартных форматов, чтобы его можно было дальше отдавать в другие инструменты или хранить как артефакт
• Помогает привести результат к более удобному виду, чтобы SBOM не был просто «сырой простынёй», а нормально читался
• Подходит для автоматизации в CI/CD, как постоянная часть supply-chain процесса
• Может использоваться как стартовая точка для дальнейшего анализа зависимостей, лицензий и уязвимостей
• Может использоваться для сертификации во ФСТЭК России по требованиям испытательной лаборатории в том числе
• Нормально ложится в сценарии, где нужно быстро получить экспорт зависимостей и потом прогнать их через security-инструменты или загрузить в внешний контур
Функционально
• Генерирует SBOM из локальной директории или Git-репозитория (GitHub / GitLab)
• Сканирует уязвимости через Trivy, OWASP Dependency-Check, Clair
• Встраивает найденные уязвимости в SBOM (CycloneDX 1.5)
• Экспортирует читаемые отчёты: Excel (.xlsx), Word (.docx), ODT (.odt)
• Подписывает итоговый SBOM (SHA-256)
Зачем?
• Перед релизом, чтобы понимать, из чего состоит и какие зависимости используются
• В CI/CD, чтобы SBOM генерировался автоматически на каждый билд или релиз и можно было сверяться с обходными путями от команд для используемых зависимостей
• Для security review, когда нужно быстро показать состав зависимостей и точки риска
• Для compliance и supply-chain контроля
Планирую докрутить
• Более гибкие режимы генерации под разные типы проектов
• Сделать более удобный post-processing и валидацию результата
Links
• PyPi
• DockerHub
• Github Package
Структура
sbom_genform/
├── src/sbom_pipeline/
│ ├── cli.py # secsbom / secsbom-pipeline (typer)
│ ├── pipeline.py # оркестратор
│ ├── generate.py # генерация SBOM
│ ├── dedup.py # дедупликация
│ ├── sign.py # SHA-256 подпись
│ ├── exporter.py # xlsx / docx / odt
│ ├── vuln_merger.py # встраивание уязвимостей
│ ├── config.py # конфигурация
│ └── scanner/
│ ├── trivy.py
│ ├── depcheck.py
│ └── clair.py
├── docker/
│ └── Dockerfile.secgensbom
├── examples/project_inject/ # уязвимый PHP
├── secgensbom/secgensbom.yml # GitLab CI shared template
├── .github/workflows/
│ ├── ci.yml
│ ├── secgensbom.yml
│ └── publish.yml
├── tests/test_smoke.py
├── pyproject.toml
└── .env.example
#appsec #devsecops #specialty #toolchain #techsolution #paper #sbom
🔥5
🛠🏆 AppSec Labs to pump yourself up Release v.1.5.0
Салюты,
Разместил линк тут - course.geminishkv.tech
Интересный апдейт для тебя про который хотел бы рассказать про лабки, которые делал ранее. Да, именно те лабки, которые покажут тебе основные команды инструментов, как работать с ними, что такое база для работы в AppSec и тд. С ними у тебя получится качать себя и да, в лабах есть намеренные косяки, что бы ты смог разобраться, потому что бездумно копируя и смотря лог - маловероятно, что ты получишь какую то прокачку для себя.
Доработанные материалы в новом релизе
Stay Tuned 😉
#appsec #devsecops #roadmap #specialty #toolchain #techsolution #gost #paper #course #reco #sast #sca #dast #sbom #containersecurity #secrets #riskanalys #techsolution
Салюты,
Разместил линк тут - course.geminishkv.tech
Интересный апдейт для тебя про который хотел бы рассказать про лабки, которые делал ранее. Да, именно те лабки, которые покажут тебе основные команды инструментов, как работать с ними, что такое база для работы в AppSec и тд. С ними у тебя получится качать себя и да, в лабах есть намеренные косяки, что бы ты смог разобраться, потому что бездумно копируя и смотря лог - маловероятно, что ты получишь какую то прокачку для себя.
Доработанные материалы в новом релизе
• Добавлено описание и Mermaid-карта лабораторных работ в README.md
• Добавлена информация по pet_project и lab09 в README.md и docs/index.md
• Актуализированы конфиги линтеров и инструментов сборки: .gitattributes, .gitignore, .dockerignore, ruff.toml, mypy.ini, .markdownlint.yaml
• Полностью переписан .dockerignore
• Устранён баг сборки MkDocs: удалена несуществующая страница Metro4Shell.md из навигации mkdocs.yml
• Выровнены отступы в sidebar: переработаны стили sidebar.css
• Обновлены shields на главной странице сайта: добавлены бейджи инструментов безопасности (Semgrep, Checkov, Trivy, OWASP ZAP, Nmap) и GitHub-метрики
• Добавлены тестовые задания по лабораторным работам
• Прочие доработки
Stay Tuned 😉
#appsec #devsecops #roadmap #specialty #toolchain #techsolution #gost #paper #course #reco #sast #sca #dast #sbom #containersecurity #secrets #riskanalys #techsolution
🔥4