Вебинар: Киберинцидент как бизнес-риск: реальные кейсы и выводы

Дата проведения:
22 июля 2026г. | 12.00 (МСК)
Формат: онлайн
Регистрация по ссылке

22 июля в 12:00 Антон Бочкарев и Артем Наливайко проведут вебинар про реальные инциденты в российских компаниях.

Что разберем:
- почему большинство атак случается не из-за суперхакеров, а из-за обычных ошибок
- несколько свежих кейсов, включая недавнюю историю с молочным заводом в Уфе и атаку на поставщика через один украденный токен
- самые частые причины, из-за которых инциденты вообще происходят
- что делать в первые часы, если все уже случилось

Будет 30-40 минут практических примеров от Антона Бочкарева и Артема Наливайко, а потом сессия вопросов и ответов. Запись тоже будет, но если хотите успеть спросить свое – лучше приходите онлайн.
Всех кто останется до конца ждет бонус.

Регистрация

🌄 На Код ИБ ПРОФИ приезжают за практическими знаниями, профессиональным окружением и возможностью на несколько дней выйти из привычной рабочей рутины.

Если все это близко вам — присоединяйтесь к интенсиву 9-13 сентября в Сочи. До встречи!

#ИБнужныПРОФИ

На Код ИБ ПРОФИ собираются руководители и директора по ИБ со всей страны. Станьте частью самого сильного ИБ-комьюнити — присоединяйтесь к интенсиву в Сочи 9–13 сентября💥

#ИБнужныПРОФИ

ИИ уже стал частью рабочих процессов. Вместе с ним появились новые задачи для службы ИБ: Shadow AI, защита ML-моделей, безопасность AI-агентов, требования ФСТЭК, мониторинг атак на LLM.

Если вы хотите разобраться в этих вопросах системно, обратите внимание на модуль «Кибербезопасность в эпоху ИИ» программы «Директор по кибербезопасности 8.0».

За четыре занятия эксперты Норникеля, Домклик, СберЗдоровья и Академии Батранкова разбирают:

— Как меняется профиль рисков для ML и GenAI
— Почему запреты не решают проблему Shadow AI и какие подходы работают на практике
— Как выстроить безопасную разработку с использованием ИИ и защитить ML-пайплайны
— Как подготовиться к требованиям ФСТЭК, построить архитектуру контроля и организовать мониторинг атак на ИИ

Вместе с записью вы получите удостоверение о повышении квалификации и практические материалы: шаблон AI-BOM, чек-лист аудита ФСТЭК, рекомендации по политике использования ИИ, план мониторинга Shadow AI, SOC-плейбук и другие документы, которые можно использовать в работе.

Не ждите, пока вопросы по ИИ превратятся в инциденты. Присоединяйтесь к обучению и соберите собственную систему контроля AI-рисков.

Метрики здоровья OSS-проекта #опытэкспертов

В рамках курса «Директор по кибербезопасности 8.0» Виктор Бобыльков, CISO MWS Cloud, представил чек-лист, который позволяет быстро понять, стоит ли брать OSS-компонент в стек 👇🏻

1. Дата последнего релиза

Первый вопрос — когда выходило последнее обновление.
Целевое значение — не более 6 месяцев.
Красный флаг — если проект не обновлялся более года.

2. MTTR по CVE

Важно оценивать, насколько быстро команда проекта устраняет уязвимости.
Целевое значение — до 30 дней для critical CVE.
Красный флаг — более 90 дней или наличие уязвимостей без исправлений.

3. Bus factor

Необходимо понимать, сколько активных мейнтейнеров поддерживают проект.
Целевое значение — не менее трех.
Красный флаг — один мейнтейнер.

Bus factor — это реальный бизнес-риск. Если единственный сопровождающий выгорит, будет скомпрометирован, уйдет из проекта или прекратит поддержку, это может напрямую повлиять на компании, использующие данный компонент.

4. Наличие коммерческого спонсора

Желательно, чтобы за проектом стояли foundation или крупная компания.
Красный флаг — полностью hobby project.

5. Активность сообщества

Стоит обращать внимание на активность за последние 90 дней:

1. Новые issues
2. Pull request
3. Общую активность сообщества

Красный флаг — если проект фактически «замер», это повод дополнительно оценить риски.

6. OpenSSF Scorecard

OpenSSF Scorecard — инструмент Open Source Security Foundation, который автоматически оценивает безопасность OSS-проектов.

Он анализирует публичные данные GitHub и включает 18 проверок, связанных с:

— Практиками безопасности
— Рисками исходного кода
— Рисками процесса сборки

Среди проверяемых параметров:

— Защита основной ветки
— Обязательность code review
— Фиксация зависимостей
— Подпись релизов
— Использование SAST
— Наличие открытых уязвимостей

Итоговая оценка выставляется по шкале от 0 до 10.

Рекомендуется для критически важных компонентов — ориентироваться на Scorecard не ниже 7/10, т.к значение ниже 5/10 — красный флаг.

📩 На третьем модуле курса «Директор по кибербезопасности 8.0» эти критерии разбираются как практический инструмент для оценки OSS-компонентов и принятия решений о включении их в технологический стек.

Если хотите получать системные знания от действующих CISO, присоединяйтесь к обучению!

#ДиректорПоИБ

Ольга Поздняк стала звездой ИТ-Маркетинга 💫

CEO Код ИБ Ольга Поздняк победила в Marketing Battle на конференции Marketing Stars, где эксперты представили лучшие кейсы в антикризисном маркетинге.

Ольга рассказала, как в Код ИБ искусственный интеллект помогает автоматизировать рабочие процессы и делать маркетинг эффективнее в эпоху кризиса.

По итогам зрительского голосования Ольга стала победителем баттла и получила награду — звезду Marketing Battle ⭐️

Поздравляем с заслуженной победой!

💥 OpenSSF Scorecard — инструмент здоровья OSS-проектов #опытэкспертов

Материалом поделился Виктор Бобыльков, директор по кибербезопасности MWS Cloud, в рамках образовательного курса «Директор по кибербезопасности 8.0».

При выборе Open Source-компонента многие команды смотрят на популярность проекта, количество звезд на GitHub или активность сообщества. Но этих критериев недостаточно для оценки рисков.

OpenSSF Scorecard — инструмент, который позволяет автоматически оценить безопасность Open Source-проекта и получить его «балл здоровья». Он автоматически анализирует проект через GitHub API и оценивает его по 18 проверкам в трех категориях:

1. Практики безопасности проекта (Holistic Security Practices)
2. Риски исходного кода (Source Code Risk)
3. Риски процесса сборки (Build Process Risk)

Среди критериев оценки:

1. Защищена ли основная ветка (Branch Protection)
2. Проводится ли обязательное code review
3. Зафиксированы ли зависимости (Pinned Dependencies)
4. Подписываются ли релизы (Signed Releases)
5. Используется ли статический анализ кода (SAST)
6. Есть ли открытые и неустраненные CVE

По результатам формируется итоговый балл от 0 до 10.

💥 Как использовать OpenSSF Scorecard в работе CISO?

1. Включать минимальный порог Scorecard в политику использования Open Source
2. Проверять новые зависимости перед включением в стек
3. Регулярно отслеживать изменение баллов у уже используемых компонентов
4. Использовать публичные дашборды Scorecard для быстрой проверки
5. Для внутренних OSS-проектов компании — внедрить Scorecard как KPI команд разработки
6. Для критичных вендоров — запрашивать Scorecard в RFI/RFP

Многие команды разработки сами публикуют бейджи OpenSSF Scorecard для своих проектов и используют их как показатель зрелости процессов безопасности.

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

Именно этим вопросам посвящен третий модуль программы «Директор по кибербезопасности 8.0».

Программа модуля доступна в записи. Изучайте её на сайте и присоединяйтесь к обучению 🙌🏻

#ДиректорПоИБ