⁉️

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

14 августа (четверг) в 18:00 приглашаем вас присоединиться к настоящему батлу DevOps и ИБ — со взаимными претензиями, дракой и реальными примерами из жизни.

Среди вопросов дискуссии:

🍭 Забытые секреты, неверные доступы и не только: чем пренебрегают команды DevOps?
🍭 Часто встречающиеся проблемы ИБ в пайплайнах.
🍭 Топ абсурдных требований от безопасников.
🍭 Кто такой ибэшник мечты?
🍭 Кто должен быть медиатором во время конфликтов?
🍭 Успешные кейсы интеграции DevOps и ИБ.

⤵️ Регистрация и подробная программа.

Всем привет!

Завершающая статья из цикла, посвященного анализу достижимости (о первых двух мы писали тут и тут).

В последней части Автор рассказывает о сложностях, которые присущи Runtime Reachability. Одной из таких сложностей является то, что все понимаю ее по-разному.

Некоторые считают, что если зависимость загружена или если она используется, то уязвимость актуальна. Иные считают, что уязвимость актуальна при наличии внешнего доступа к анализируемому ресурсу.

С точки зрения Автора все несколько иначе:
🍭 Зависимость загружена и, возможно, используется. Имеет место быть. Ведь если нет зависимости, то не т и уязвимости. Но сильно не поможет.
🍭 Доступ по сети. Может быть использован для расстановки приоритетов. Если есть N приложений с уязвимостью, эксплуатируемой удаленно и только 2 доступны извне – то лучше обратить внимание на них
🍭 Исполнение уязвимой функции. Самое интересное – именно этот способ может позволить максимально эффективно отсеять лишнее. Ведь если зависимость загружена, это не означает, что используется уязвимый метод

Поэтому, для достижения лучшего результата можно использовать все три способа.

Нюанс в том, что информацию об исполнении уязвимой функции в runtime получить не так просто и крайне мало средств автоматизации.

В статье еще много полезной информации о том, на что обращать внимание при работе с уязвимостями в зависимостях и как можно попробовать оптимизировать этот процесс.

Рекомендуем!

Всем привет!

Продолжение вчерашнего поста. Автор определился с тем, что такое анализ достижимости и пошел дальше.

Теперь его цель разобраться в том, какие виды такого анализа бывают, как они работают и в чем их разница.

Он выделяет 2 основных типа:
🍭 Статический анализ достижимости. Исследование исходного кода, библиотек, их использования и поиск уязвимых функций
🍭 Динамический анализ достижимости. Пакеты ОС, их использование, поиск уязвимых функций, идентификация вредоносного ПО

Далее Автор разбирает каждый из типов более детально и с примерами. Например, в чем разница между Package Level Reachability и Function Level Reachability, если говорить про статический анализ достижимости.

Помимо этого, в статье приводится очень хорошее описание сильных и слабых сторон для каждого из рассматриваемых способов анализа.

Всем привет!

Этот термин (хоть он далеко и не новый) появляется все чаще и чаще. Но что он означает? Как обычно, разные специалисты/компании интерпретируют его по-своему.

В статье Автор пытается разобраться в вопросе и формирует свой ответ на то, что же это такое.

Начинается все со сравнения – каким был процесс управления уязвимостями раньше и каким он стал сейчас. Да, когда-то было достаточно просто обновить версию ПО. Однако, сканеры развиваются, начинают лучше понимать ПО и могут анализировать ОС, пакеты, зависимости, ПО и т.д.

Вследствие чего появляется больше данных и, увы, ложных срабатываний. И вот тут анализ достижимости может пригодиться.

Например, понимание того:
🍭 Загружена ли библиотека
🍭 Используется ли метод
🍭 Доступно ли ПО извне
🍭 Есть ли какие-то меры по ИБ

может сильно помочь. И да, CVE может и присутствовать, но эксплуатировать ее нельзя. Тогда это false positive?

Поэтому, по мнению Автора, анализ достижимости это не только про комбинирование практик SAST и SCA, но и про понимание контекста – инфраструктуры, средств защиты.

Таким образом получается, что цель не в снижении false positive, а в поиске true positive.

А что вы думаете по этому поводу и реализуете ли вы такой анализ у себя?

Всем привет!

Продолжаем тему анализа безопасности open source проектов перед их использованием. Еще одним инструментом, который может помочь, является Gitxray.

Он позволяет собрать множество информации о репозитории для последующего анализа.

Например:
🍭 Искать чувствительную информацию в профилях contributors
🍭 Идентифицировать не настоящие (fake) или зараженные (infected) репозитории
🍭 Анализ времени commit’ов для идентификации аномалий
🍭 Предоставлять сведения об артефактах релизов, которые были изменены уже после релиза
🍭 И многое другое

Устанавливается и запускается крайне просто. Результаты работы утилиты предоставляются в виде наглядного html-отчета.

Больше информации об Gitxray можно найти в репозитории или в документации.