Возлюби безопасника своего как самого себя: Построение DevSecOps как гармоничный путь развития
Softline и Microsoft открывают новую серию технических вебкастов темой безопасности "Возлюби безопасника своего как самого себя: Построение DevSecOps как гармоничный путь развития", который пройдёт 28 января.
Как это было раньше?
Безопасник выступал в роли контролирующего органа, продукт попадал к нему на оценку и согласование уже в конце, когда код написан, интеграционные и UI тесты пройдены, изделие, казалось бы, готово к выпуску в продакшн. Вот тут-то проблемы и начинались.
Разработчик: Я писал с применением популярных легальных open source библиотек.
Безопасник: В вашем коде целый кусок не соответствует требованиям безопасности и дыряв как швейцарский сыр.
В результате процесс начинается заново. Разработчик, злой и раздраженный, уходит переписывать кусок кода, запускать повторное тестирование. Безопасник, с чувством выполненного долга, ждет. Так идет неделя за неделей, а продукт все еще не выпущен.
А как сейчас.
Появилась методология DevSecOps. Она позволяет интегрировать процессы обеспечения безопасности внутри разработки. На всех этапах ответственный за соблюдение норм безопасности работает плечом к плечу с командой разработки.
У такого подхода несколько плюсов:
Приложение выводится в продакшн быстрее.
В приложении меньше дефектов и уязвимостей.
Уменьшается время, необходимое для обеспечения безопасности приложения.
Конфликты «безопасник/разработчик» снижаются и решаются на самых ранних этапах.
Снижаются риски использования некачественных или юридически рискованных open source компонентов, которые можно выявить, например, при проверке через Black Duck или WhiteSource
Дата проведения: 28.01.2020. Начало в 11:00
Место проведения: Онлайн
- Анонс
- Программа
- Участники
- Спикеры
Softline и Microsoft открывают новую серию технических вебкастов темой безопасности "Возлюби безопасника своего как самого себя: Построение DevSecOps как гармоничный путь развития", который пройдёт 28 января.
Как это было раньше?
Безопасник выступал в роли контролирующего органа, продукт попадал к нему на оценку и согласование уже в конце, когда код написан, интеграционные и UI тесты пройдены, изделие, казалось бы, готово к выпуску в продакшн. Вот тут-то проблемы и начинались.
Разработчик: Я писал с применением популярных легальных open source библиотек.
Безопасник: В вашем коде целый кусок не соответствует требованиям безопасности и дыряв как швейцарский сыр.
В результате процесс начинается заново. Разработчик, злой и раздраженный, уходит переписывать кусок кода, запускать повторное тестирование. Безопасник, с чувством выполненного долга, ждет. Так идет неделя за неделей, а продукт все еще не выпущен.
А как сейчас.
Появилась методология DevSecOps. Она позволяет интегрировать процессы обеспечения безопасности внутри разработки. На всех этапах ответственный за соблюдение норм безопасности работает плечом к плечу с командой разработки.
У такого подхода несколько плюсов:
Приложение выводится в продакшн быстрее.
В приложении меньше дефектов и уязвимостей.
Уменьшается время, необходимое для обеспечения безопасности приложения.
Конфликты «безопасник/разработчик» снижаются и решаются на самых ранних этапах.
Снижаются риски использования некачественных или юридически рискованных open source компонентов, которые можно выявить, например, при проверке через Black Duck или WhiteSource