Зачем нужен AI SAST и как он работает?
Всем привет!
Ответ на первую часть вопроса достаточно прост. «Классические» SAST решения в большей степени привыкли искать некие шаблоны (patterns). Они не понимают, как работает приложение.
Поэтому они показывают не самые лучшие результаты, например, при анализе бизнес-логики или ИБ-дефектах, связанных с обходом аутентификации.
На вторую часть вопроса ответить тяжелее, так как у разных производителей свои подходы. Сегодня хотим поделиться с вами тем, как это делает ZeroPATH.
Подход ребят состоит из этапов:
🍭 Trigger Scan. Просто запуск сканирования (ручной, автоматический – не важно)
🍭Application Identification. «Изучение» приложения и получение «базовой» информации о нем
🍭AST Generation & Indexing. Создание AST
🍭Graph Enrichment. Обогащение графа через контекст
🍭Vulnerability Discovery. Идентификация ИБ-дефектов за счет анализа графа
🍭Validation & Verification. Подтверждение возможности эксплуатации, в том числе за счет анализа достижимости
🍭Patch Generation. Генерация рекомендаций по устранению уязвимостей
Каждый из этапов очень детально описан в статье. Приводятся схемы, поясняется что же это за «контекст» такой, который нужен для корректной работы.
Получился материал, который может дать неплохое представление о том, как AI SAST может работать «под капотом».
Рекомендуем!
Всем привет!
Ответ на первую часть вопроса достаточно прост. «Классические» SAST решения в большей степени привыкли искать некие шаблоны (patterns). Они не понимают, как работает приложение.
Поэтому они показывают не самые лучшие результаты, например, при анализе бизнес-логики или ИБ-дефектах, связанных с обходом аутентификации.
На вторую часть вопроса ответить тяжелее, так как у разных производителей свои подходы. Сегодня хотим поделиться с вами тем, как это делает ZeroPATH.
Подход ребят состоит из этапов:
🍭 Trigger Scan. Просто запуск сканирования (ручной, автоматический – не важно)
🍭Application Identification. «Изучение» приложения и получение «базовой» информации о нем
🍭AST Generation & Indexing. Создание AST
🍭Graph Enrichment. Обогащение графа через контекст
🍭Vulnerability Discovery. Идентификация ИБ-дефектов за счет анализа графа
🍭Validation & Verification. Подтверждение возможности эксплуатации, в том числе за счет анализа достижимости
🍭Patch Generation. Генерация рекомендаций по устранению уязвимостей
Каждый из этапов очень детально описан в статье. Приводятся схемы, поясняется что же это за «контекст» такой, который нужен для корректной работы.
Получился материал, который может дать неплохое представление о том, как AI SAST может работать «под капотом».
Рекомендуем!
Zeropath
How ZeroPath Works - ZeroPath Blog
Technical deep-dive into ZeroPath's SAST methodology: From AST generation to AI-powered vulnerability discovery and automated patch generation.
👍3🔥1
Docker Security: лабораторные работы
Всем привет!
Материал для начинающих. По ссылке можно найти GitHub-репозиторий, в котором собран набор лабораторных работ по безопасности Docker.
Всего доступно 6 заданий:
🍭 Lab 01: Security Auditing with Docker Bench
🍭 Lab 02: Secure Container Configurations
🍭 Lab 03: Least Privilege Containers
🍭 Lab 04: Image Signing and Verification
🍭 Lab 05: Seccomp Profile
🍭 Lab 06: AI Model Security
Для каждой работы приводится краткое описание в формате *.md о том, что надо сделать и как ее надо запустить.
Если возникнут трудности с решением, то можно обратиться к этой статье.
В ней Автор описывает как и что он делал для успешного прохождения лабораторных.
Всем привет!
Материал для начинающих. По ссылке можно найти GitHub-репозиторий, в котором собран набор лабораторных работ по безопасности Docker.
Всего доступно 6 заданий:
🍭 Lab 01: Security Auditing with Docker Bench
🍭 Lab 02: Secure Container Configurations
🍭 Lab 03: Least Privilege Containers
🍭 Lab 04: Image Signing and Verification
🍭 Lab 05: Seccomp Profile
🍭 Lab 06: AI Model Security
Для каждой работы приводится краткое описание в формате *.md о том, что надо сделать и как ее надо запустить.
Если возникнут трудности с решением, то можно обратиться к этой статье.
В ней Автор описывает как и что он делал для успешного прохождения лабораторных.
GitHub
GitHub - opscart/docker-security-practical-guide: A hands‑on, lab‑based toolkit for securing containerised environments. Progress…
A hands‑on, lab‑based toolkit for securing containerised environments. Progress from core audit techniques to advanced AI‑enabled runtime security, with clear examples, scripts, and best practices....
❤10👍1
Kubernetes Network Tutorial для разработчиков
Всем привет!
По ссылке можно найти обзорный материал о том, как устроено сетевое взаимодействие в Kubernetes и как с ним можно (нужно) работать.
«Предварительные требования» невелики: общее понимание контейнеризации и сетевых терминов, наличие кластера Kubernetes и установленный Helm.
Материал структурирован по разделам:
🍭 Introduction to Kubernetes Networking
🍭 Core Concepts in Kubernetes Networking
🍭 Cluster Networking Components
🍭 DNS and Service Discovery
🍭 Pod Networking Deep Dive
🍭 Network Policies and Security
🍭 Common Pitfalls and Troubleshooting
🍭 Summary and Next Steps
Получился tutorial, который охватывает сразу несколько тем и написан очень простым и понятным языком.
Много примеров и пояснений. В каждом разделе есть какой-то свой сценарий, на котором Автор наглядно демонстрирует происходящее.
Хоть в названии и указано «для разработчиков», статья может быть полезна всем, кто хочет разобраться в основах сетевого взаимодействия Kubernetes.
Рекомендуем!
Всем привет!
По ссылке можно найти обзорный материал о том, как устроено сетевое взаимодействие в Kubernetes и как с ним можно (нужно) работать.
«Предварительные требования» невелики: общее понимание контейнеризации и сетевых терминов, наличие кластера Kubernetes и установленный Helm.
Материал структурирован по разделам:
🍭 Introduction to Kubernetes Networking
🍭 Core Concepts in Kubernetes Networking
🍭 Cluster Networking Components
🍭 DNS and Service Discovery
🍭 Pod Networking Deep Dive
🍭 Network Policies and Security
🍭 Common Pitfalls and Troubleshooting
🍭 Summary and Next Steps
Получился tutorial, который охватывает сразу несколько тем и написан очень простым и понятным языком.
Много примеров и пояснений. В каждом разделе есть какой-то свой сценарий, на котором Автор наглядно демонстрирует происходящее.
Хоть в названии и указано «для разработчиков», статья может быть полезна всем, кто хочет разобраться в основах сетевого взаимодействия Kubernetes.
Рекомендуем!
freeCodeCamp.org
Kubernetes Networking Tutorial: A Guide for Developers
Kubernetes networking is one of the most critical and complex parts of running containerized workloads in production. It’s what allows different parts of a Kubernetes system – like containers and services – to talk to each other. This tutorial will w...
❤8👍1
Раскрытие чувствительных данных через GitLab GraphQL API
Всем привет!
Небольшая история о том, как уязвимость в GitLab API позволила получить доступ к конфиденциальной информации.
GraphQL API GitLab’a отключает защиту от CSRF для
Это построено на допущении, что
Оказалось, что нет. Нашлась
Соединив все это вместе Автор реализовал сценарий:
🍭 Атакующий настраивает webhook для получения данных
🍭 Создается HTML-файл, который перенаправляет пользователя на специальный URL (используя ту самую «небезопасную»
🍭 Файл направляется аутентифицированному GitLab-пользователю, он нажимает на ссылку…
🍭 Отправляется
🍭 Готово! Данные отправлены атакующему
Если нужно больше деталей о реализации сценария, то найти их можно в статье – там все очень подробно расписано.
Помимо этого, в статье есть видеозапись, которая демонстрирует реализацию рассмотренной атаки.
Важно (!): информация об уязвимости была сообщена команде GitLab и устранена в версии 18.4 (подробности доступны тут).
Всем привет!
Небольшая история о том, как уязвимость в GitLab API позволила получить доступ к конфиденциальной информации.
GraphQL API GitLab’a отключает защиту от CSRF для
Queries (которые передаются через GET-запросы) и включает ее для Mutations (которые передаются через POST-запросы).Это построено на допущении, что
Queries могут только «читать» данные и ничего больше. Но так ли это на самом деле?Оказалось, что нет. Нашлась
Query, которая может делать запросы к внешним сервисам.Соединив все это вместе Автор реализовал сценарий:
🍭 Атакующий настраивает webhook для получения данных
🍭 Создается HTML-файл, который перенаправляет пользователя на специальный URL (используя ту самую «небезопасную»
Query)🍭 Файл направляется аутентифицированному GitLab-пользователю, он нажимает на ссылку…
🍭 Отправляется
GET запрос к gitlab.com/api/graph/…🍭 Готово! Данные отправлены атакующему
Если нужно больше деталей о реализации сценария, то найти их можно в статье – там все очень подробно расписано.
Помимо этого, в статье есть видеозапись, которая демонстрирует реализацию рассмотренной атаки.
Важно (!): информация об уязвимости была сообщена команде GitLab и устранена в версии 18.4 (подробности доступны тут).
❤6
DevEx Engineer: на что обращать внимание при аудитах
Всем привет!
Работа на новой позиции зачастую связана с ответом на вопрос: «А что здесь вообще происходит и с чем мне придется работать?».
DevEx (Developer Experience) – роль, которая должна помочь оптимизировать процессы разработки и доставки ПО – не исключение.
В статье можно найти достаточно подробный план на 30 первых дней, в котором указано на что следует обращать внимание при проведении первичного аудита.
Материал структурирован по разделам:
🍭 Phase 1: Benchmark Feedback Loops (Days 1–10). Понимание процессов сборки, тестирования, разворачивания
🍭 Phase 2: Reduce Context Switching (Days 11–20). Работа с управлением задачами, базой знаний и передачей компетенций
🍭 Phase 3: Audit Rituals That Impact Velocity (Days 21–30). Поиск ненужных (неоптимальных) «ритуалов» и бутылочных горлышек
Для каждой из фаз Автор приводит краткое описание «что это и зачем?», а также набор метрик, которые помогут лучше разобраться в вопросе.
Дополнительно описываются рекомендации о том, как и что можно улучшить.
В указанный план аудита можно очень удачно встроить часть, связанную с информационной безопасностью, чтобы сделать его более комплексным и полным.
Всем привет!
Работа на новой позиции зачастую связана с ответом на вопрос: «А что здесь вообще происходит и с чем мне придется работать?».
DevEx (Developer Experience) – роль, которая должна помочь оптимизировать процессы разработки и доставки ПО – не исключение.
В статье можно найти достаточно подробный план на 30 первых дней, в котором указано на что следует обращать внимание при проведении первичного аудита.
Материал структурирован по разделам:
🍭 Phase 1: Benchmark Feedback Loops (Days 1–10). Понимание процессов сборки, тестирования, разворачивания
🍭 Phase 2: Reduce Context Switching (Days 11–20). Работа с управлением задачами, базой знаний и передачей компетенций
🍭 Phase 3: Audit Rituals That Impact Velocity (Days 21–30). Поиск ненужных (неоптимальных) «ритуалов» и бутылочных горлышек
Для каждой из фаз Автор приводит краткое описание «что это и зачем?», а также набор метрик, которые помогут лучше разобраться в вопросе.
Дополнительно описываются рекомендации о том, как и что можно улучшить.
В указанный план аудита можно очень удачно встроить часть, связанную с информационной безопасностью, чтобы сделать его более комплексным и полным.
MetalBear 🐻
Your First 30 Days as a DevEx Engineer: What to Audit and Improve
A practical 30 day audit framework for new DevEx engineers to benchmark feedback loops, reduce context switching, and eliminate outdated rituals that slow teams down.
❤2👍1