Разработчики программного обеспечения и специалисты по безопасности часто похожи на двух собак, лающих друг на друга через забор. Так быть не должно, пишет на портале TechBeacon Питер Данье, соучредитель и генеральный директор компании Secure Code Warrior.
Согласно исследованию Ponemon Institute, проведенному в 2020 г., разработчики традиционно рассматривают безопасность как узкое место для инноваций и скорости, в то время как лидеры в области безопасности считают, что разработчики отдают приоритет скорости доставки, а не качеству. Пришло время преодолеть этот разрыв.
Разработчики находятся на передней линии обороны организации и, следовательно, конечного пользователя. В феврале NIST выпустил руководство по обеспечению безопасности цепочки поставок ПО. Агентство рекомендует минимальные меры безопасности, включая усиленное подтверждение практики обеспечения безопасности при использовании и разработке ПО.
Растущая проблема
Цепочка поставок ПО становится все более заметной мишенью для кибератак. Согласно исследованию Argon «Supply Chain Attacks Study: Identifying Primary Risk Areas», в период с 2020 по 2021 гг. число атак на цепочки поставок ПО увеличилось более чем на 300%. Эти атаки включали в себя внедрение вредоносного кода в популярные пакеты с открытым исходным кодом или использование существующей уязвимости.
Особенно популярной мишенью стал канал Open Source-компонентов. Согласно исследованию компании Sonatype, в четырех крупнейших Open Source-экосистемах насчитывается более 37 млн. компонентов и пакетов. В прошлом году объем загрузок ПО с открытым исходным кодом достиг 2,2 трлн., что на 73% больше, чем в 2020 г.
Организации все чаще используют Open Source-решения для своих бизнес-потребностей. Хотя эти платформы с открытым исходным кодом обеспечивают огромную ценность, они часто приводят к повышенным рискам. Именно здесь разработчики могут быть крайне полезны.
Изменение культуры
Руководство NIST, безусловно, подтолкнет это движение вперед, но организации должны использовать проактивный подход для повышения безопасности. Это включает в себя честные разговоры и структуры отчетности между командами безопасности приложений, с одной стороны, и разработчиками и их руководителями, с другой, о приоритетах и ожиданиях.
Разработчиков следует поощрять к последовательному развитию своих навыков для повышения безопасности в процессе разработки. Для этого необходима стратегия, обеспечивающая им время, обучение и инструменты для достижения лучших результатов в области безопасности. Разработчики должны рассматривать себя как наконечник копья безопасности.
Организации должны осуществить культурный сдвиг в своих стратегиях управления рисками, чтобы принять руководящие принципы NIST. Простое игнорирование или деприоритизация потребностей безопасности больше недопустимо.
Повышение квалификации разработчиков
Изменение культуры требует повышенного внимания обучению и развитию навыков. Хотя разработчики приобретают определенные навыки в процессе формального образования, они также должны регулярно проходить тренинги, чтобы идти в ногу с развитием технологий.
Если руководители служб безопасности хотят, чтобы разработчики принимали более активное участие в обеспечении безопасности ПО, они должны предоставить им возможность изучать необходимые методы создания более качественного и безопасного кода. Слишком часто организации минимизируют потребность в обучении и предлагают разработчикам только возможность участвовать в ежегодном повышении квалификации, если таковая имеется.
Одним из популярных способов сделать это является микрообучение. В этом формате разработчики участвуют в небольших учебных блоках и краткосрочных учебных мероприятиях. Он включает в себя краткосрочные стратегии, разработанные специально для улучшения понимания на основе развития навыков.
Микрообучение позволяет разработчикам приобретать новые навыки без постоянного выделения больших кусков времени. Вместо этого они могут проходить небольшие курсы, которые формируются с течением времени. Это гарантирует, что разработчики последовательно осваивают навыки, необходимые для успешного создания безопасного кода для бизнеса, без необходимости длительного обучения, которое часто отодвигается из-за сжатых сроков проектов.
Дальнейшее продвижение вперед
Есть надежда, что этот необходимый сдвиг в культуре произойдет. CISO, как правило, больше интересуются потенциалом команд разработчиков в области безопасности и тем, что они делают для защиты всех сотрудников компании от разрушительных нарушений безопасности. Разработчики должны быть прозрачны в своих потребностях. Для управления конкурирующими приоритетами необходима эмпатия с обеих сторон.
Атака SolarWinds показала, насколько разрушительными могут быть дыры в процессе разработки ПО. Разработчики могут оказать значительное положительное влияние. Для этого необходимо понять их потребности и сбалансировать их с другими приоритетами, чтобы обеспечить положительный и безопасный результат для всех.
