Своё программное обеспечение можно разрабатывать по лучшим практикам РБПО. А что насчёт чужого? В эпоху SolarWinds, 3CX и массового использования сторонних компонентов вопрос доверия к вендору — вопрос выживания. Компании всё чаще становятся жертвами, даже не подозревая, что источник угрозы уже давно установлен и работает внутри инфраструктуры.

Вторая часть эфира посвящена защите от атак на цепочку поставок: как оценивать зрелость поставщика, запрашивать и проверять SBOM, обрабатывать уязвимости и контролировать доступ стороннего ПО к конфиденциальным данным. Обсудим реальные сценарии, когда вендор уходит с рынка или отказывается чинить баги, — и что с этим делать. Если вы закупаете, внедряете или эксплуатируете ПО — обязательно включайтесь.

Ключевые вопросы дискуссии:

1. Выбор безопасного поставщика программного обеспечения
   • Как выбирать поставщика ПО с точки зрения информационной безопасности?
   • Чему нас научили инциденты типа SolarWinds, Codecov, Log4Shell и другие?
   • Есть ли практика проведения внешнего аудита или пентестов приобретаемого ПО?
   • Какие стандарты или фреймворки должны использоваться у потенциального поставщика?
   • Как проверить наличие у вендора политики безопасной разработки?
   • Требовать ли у поставщика SBOM (Software Bill of Materials)? Как его проанализировать?
   • Как оценить риски от open source компонентов в стороннем ПО?
   • Выход вендора на Bug Bounty — это явный плюс при выборе в закупках?
   • Как контролировать доступы стороннего ПО к чувствительным данным и API?
   • Какую систему классификации и инвентаризации стороннего ПО стоит использовать?
2. Управление сторонним ПО с позиции ИБ
   • Что делать, если у нас 50 поставщиков ПО? Как приоритизировать усилия по проверке при ограничении ресурсов?
   • Как проверять происхождение и подписи бинарных файлов?
   • Что делать, если нет уверенности в стороннем ПО, но отказаться от него нельзя?
   • Требовать ли у вендора уведомление о найденных уязвимостях?
   • Как быстро вендор обязан реагировать на обнаруженные уязвимости?
   • Каким должен быть процесс валидации обновлений стороннего ПО?
   • Кто в компании должен отвечать за «чистоту» стороннего ПО — ИБ, ИТ или DevOps?
   • Как быть с наследуемым ПО, проверить или поднять уровень безопасности которого не представляется возможным?
   • Случилось самое плохое. У поставщика нашлась критическая уязвимость или произошел инцидент — как нужно действовать?
3. Итоги и прогнозы
   • Какие сценарии атак через цепочку поставок будут набирать обороты? 
   • Какие меры могут проявить российские организации для проактивной минимизации рисков атак через поставщиков?
   • Что должно поменяться в индустрии ИТ, чтобы цепочки поставок стали безопаснее?

Приглашенные эксперты:

Модераторы: