Лучшие российские практики DevSecOps

• Обсуждение темы безопасной разработки, включая определение предметной области и ее составляющие.  

• Представление экспертов: Юрий Шабалин, Алексей Астахов, Сергей, Архип Ивановна, Валерий Куваев.  

• Процесс безопасной разработки - непрерывный процесс улучшения качества продукта с точки зрения безопасности.  

• Три фактора, на которых базируется процесс: люди, технологии и процессы.  

• Обсуждение важности технологий, процессов и людей в процессе безопасной разработки.  

• Валерий Куваев дополняет, что ваф - это про безопасную разработку.  

• Обсуждение того, что безопасная разработка - это не только написание безопасного кода, но и его внедрение, тестирование и сопровождение.  

• Упоминается, что безопасная разработка - это процесс, который включает в себя все этапы разработки, от начала до конца.  

• Обсуждение того, что безопасная разработка - это не только создание безопасных приложений, но и обеспечение безопасности в процессе их разработки, тестирования и сопровождения.  

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

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

• Упоминается, что разработчики должны быть вовлечены в процесс расследования инцидентов, чтобы лучше понимать контекст и улучшать свою работу.  

• Обсуждение вопроса о том, как заставить разработчиков писать безопасный код.  

• Упоминается, что безопасная разработка - это совместная работа, а не принуждение.  

• Обсуждается, что безопасный код - это код, который соответствует требованиям безопасности и не содержит уязвимостей.  

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

• Обсуждается, что код, который не является безопасным, может быть опасен для пользователей.  

• Упоминается, что обучение и мотивация разработчиков также важны для безопасной разработки.  

• Упоминается, что обучение и вовлечение разработчиков в процесс безопасной разработки является важной задачей.  

• Обсуждается, что безопасность кода - это ответственность разработчика, так как это свойство кода.  

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

• Обсуждение важности обучения разработчиков безопасности и встраивания инструментов безопасности в их рабочие процессы.  

• Статистика показывает, что большинство разработчиков занимаются повышением безопасности своих приложений для повышения общей безопасности.  

• Рост технологий и необходимость компенсации технологий, потерянных из-за ухода Windows из России.  

• Давление атакующих и необходимость защиты от них.  

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

• Виртуальные чемпионаты и другие способы обучения и развития культуры безопасности в командах.  

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

• В видео обсуждается проблема с безопасностью в разработке, когда разработчики не моют руки перед приемом пациентов, несмотря на таблички с призывом к этому.  

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

• В видео обсуждается культура безопасности и партнерство между разработчиками и безопасниками.  

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

• В видео подчеркивается важность коммуникации между разработчиками и безопасниками для решения проблем с безопасностью.  

• Приводится пример, когда руководитель инфраструктуры не понимал, что такое DMZ, и потребовалось объяснение от безопасника.  

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

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

• Обсуждение важности обучения разработчиков и руководителей бизнеса в области безопасности.  

• Упоминается необходимость обучения не только разработчиков, но и тех, кто заказывает разработку.  

• Упоминается важность понимания процессов безопасной разработки и их применения.  

• Результаты опроса показывают, что большинство разработчиков предпринимают первые шаги в области безопасности, такие как сканирование исходного кода и устранение дефектов.  

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

• Однако, результаты опроса также показывают, что некоторые разработчики не предпринимают никаких мер для обеспечения безопасности.  

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

• Упоминается, что статический анализатор не является функцией асек, и что для начала нужно понять, что именно нужно сделать.  

• Для этого необходимо провести аудит текущих процессов и разработки, чтобы понять, где находятся и что нужно сделать.  

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

• Упоминается, что опенсорс может быть использован для обкатки процесса, но требует много ресурсов.  

• Обсуждается, что для начала нужно понять, что именно нужно сделать, и только потом начинать внедрять процессы и инструменты.  

• Упоминается, что для внедрения безопасной разработки нужно найти компанию, которая умеет это делать, и предложить им пилотирование.  

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

• Обсуждение платформы как сервиса, которая предлагает различные инструменты для безопасной разработки.  

• Упоминается композиционный анализ и анализ опенсорса.  

• Обсуждается, что для сложных продуктов и длинных релизных циклов может потребоваться более сложный процесс разработки.  

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

• Обсуждаются различные метрики, такие как количество уязвимостей, количество критических замечаний на приемке и время жизни дефекта.  

• Упоминается, что для бизнеса важно понимать, что безопасная разработка ведет к недопустимым рискам.  

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

• Обсуждается, как управлять зависимостями и использовать композиционный анализ для верификации безопасности.  

• Обсуждение двух точек входа для внедрения безопасной разработки: моделирование угроз и инциденты.  

• Упоминается важность понимания причин появления уязвимостей и их устранения.  

• Использование существующих инструментов и технологий для автоматизации процессов безопасности.  

• Изучение своих продуктов и процессов, чтобы встроиться в них без ломки.  

• Кастомизация инструментов и правил для уменьшения ложных срабатываний.  

• Автоматизация процесса обработки уязвимостей для уменьшения трудозатрат.  

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

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

• Обсуждение необходимости обучения и контроля над процессом устранения уязвимостей.  

• Предложение о том, что команда безопасности должна иметь оцифрованную карту компетенций, чтобы их решения можно было принять как адекватные.  

• Предложение о том, что обучение должно быть специфичным под роль, контекст приложения и специфику фреймворка.  

• Обсуждение возможности обучения и аудита команд разработки.  

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

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

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

• Упоминается, что разработчики должны брать на себя часть работы по обеспечению безопасности, включая тестирование, анализ кода и архитектуру.  

• Обсуждается вопрос о том, как защитить контейнерную среду, в которой работают разработчики.  

• Упоминаются инструменты для сканирования образов и мониторинга активности в рантайме.  

• Обсуждается необходимость следить за инфраструктурой, включая операционные системы и образы, а также за взаимодействием между микросервисами.  

• Упоминается, что разработчики должны понимать, как их микросервисы взаимодействуют с другими и как они должны быть проверены на безопасность.  

• Обсуждение уязвимостей и их влияния на процесс разработки.  

• Уязвимости могут быть обнаружены в сторонних зависимостях, и их устранение может быть сложным или невозможным.  

• Вопрос о том, как использовать уязвимости и как их закрывать, является спорным.  

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

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

• Сложность сряжа результатов и стоимость необходимых средств анализа также являются важными факторами.  

• Результаты опросов показывают, что решение о том, как использовать уязвимости, принимается командой разработки в большинстве компаний.  

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

• Обсуждение различных практик и инструментов, используемых в процессе безопасной разработки, включая анализ защищенности, фазинг-тестирование и моделирование угроз.  

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

• Ожидается рост спроса на специалистов в области безопасности, развитие инструментов и процессов безопасной разработки, а также развитие культуры разработки.  

• Упоминается важность регуляторики и ее влияние на рынок безопасности.  

• Результаты опроса показывают, что большинство аудитории использует и будет совершенствовать практики и инструменты безопасной разработки.  

• Некоторые участники заинтересованы в начале внедрения этих практик, но есть и те, кто считает их избыточными.