Между командами разработки и безопасности существует общая история. Всегда существовало противоречие между необходимостью предоставлять быстродействующее программное обеспечение и необходимостью гарантировать его безопасную работу. Сегодня компании как никогда нуждаются в быстрой доставке приложений, и доступные для разработки инструменты предназначены для поддержки такой скорости.
В частности, резкое увеличение количества API и программных подключений привело в последние годы к ускорению поставок. Разработка на основе искусственного интеллекта — это лишь последняя версия этого набора инструментов, ориентированного на скорость, а повышение производительности труда разработчиков рекламируется как ключевое преимущество. Именно стремление к скорости позволило инновациям процветать.
В то же время за одержимость скоростью приходится платить. Специалисты по безопасности скажут вам, что кибербезопасность отходит на второй план ради целесообразности, что в конечном итоге сопряжено с большим риском и затратами. И у них есть доказательства, подтверждающие это. Недавно произошли серьезные инциденты с MoveIt (затронули более 60 миллионов человек), миллионы скомпрометированных записей Dell, Mercedes-Benz, раскрывающий уязвимость токена GitHub, и многое другое, что еще предстоит раскрыть. Хотя эти инциденты легко рассматривать по отдельности, совокупность инцидентов создает закономерность. Стремление к скорости приводит к снижению безопасности кода.
Вице-президент по продукту в Валарм.
Можно ли примирить эти две разные точки зрения?
Чтобы лучше понять это противоречие и, возможно, найти решение, мы можем более внимательно рассмотреть конкретную тему уязвимостей. В данном случае речь идет о программном изъяне, позволяющем злоумышленнику выполнить несанкционированное действие со злым умыслом. Если вы работаете в области информационной безопасности, вы знаете, что существует, по сути, бесконечное количество уязвимостей, которые нужно устранить с помощью ограниченных ресурсов, в то время как киберпреступники скрываются в тени.
Эти уязвимости существуют потому, что разработчик создал их, но не намеренно и все чаще не напрямую. Мало обсуждается вопрос об исправлении уязвимостей, которые явно представляют высокий риск или уже использовались. Однако существует много разногласий по поводу того, что представляет собой «высокий» риск и относительного приоритета устранения уязвимостей, которые занимают более низкое место в индексе риска. На самом деле существуют целые компании, занимающиеся определением приоритета уязвимостей.
Приоритизация уязвимостей — это микрокосм более широкой среды кибербезопасности. О принципах легко договориться, но о деталях сложно.
В конечном счете, путь к решению лежит в определении приоритетности проблем безопасности с учетом их оперативного воздействия. Другими словами, и безопасность, и развитие должны немного сдаться и согласиться с тем, что некоторые проблемы действительно критически важны, а другие — нет. Это требует переосмысления с обеих сторон и готовности работать вместе.
И хотя это не намеренно, это очень похоже на DevSecOps. Интеграция методов обеспечения безопасности в конвейер DevOps — один из способов сблизить эти две группы. Внедрение сдержек и противовесов безопасности на протяжении всего жизненного цикла разработки вместо того, чтобы рассматривать безопасность как второстепенную мысль, звучит как отличный план, и разработка на основе API напрямую поддерживает этот тип автоматизации. Однако автоматизация тестирования безопасности в рамках процесса CI/CD касается только процесса, а не образа мышления.
Сами по себе технологии не являются ответом
Культурные изменения также необходимы. Разработчики должны быть осведомлены о том, как проблемы безопасности влияют на бизнес, и обучение передовым практикам написания безопасного кода должно основываться на этих бизнес-потребностях. Команды безопасности, в свою очередь, должны понимать, с какими бизнес-давлениями сталкиваются разработчики, и работать, чтобы быть помощниками, а не привратниками. Межфункциональное обучение и совместные семинары могут способствовать укреплению взаимопонимания и развитию культуры, в которой безопасность рассматривается как общая ответственность.
Кроме того, компании должны применять подход к расстановке приоритетов, основанный на бизнес-рисках. Не все уязвимости одинаковы, поэтому крайне важно расставить их по приоритетности, исходя из их потенциального воздействия на бизнес. Необходимо оценить не только техническую серьезность уязвимости, но и бизнес-контекст. Например, уязвимость в критически важном API, который обрабатывает конфиденциальные данные клиентов, должна быть предпочтительнее, чем столь же серьезная проблема во внутреннем приложении с низким уровнем риска. Однако решить эти проблемы непросто.
Одна из целей DevSecOps — способствовать межведомственному общению. Эффективное общение между командами разработки и безопасности имеет решающее значение. Командам безопасности необходимо сформулировать риски и потенциальное влияние уязвимостей так, чтобы это нашло отклик у разработчиков. Это означает выход за рамки технического жаргона и сосредоточение внимания на бизнес-рисках и операционных последствиях, что требует от обеих команд одинакового понимания этого бизнес-контекста.
Напряженность между разработчиками и командами безопасности в конечном итоге сводится к разным приоритетам: скорость или безопасность. Создание общей основы для определения приоритетов потребностей бизнеса может помочь преодолеть этот разрыв. Применяя такие практики, как DevSecOps, используя автоматизацию, развивая культуру сотрудничества и уделяя особое внимание управлению уязвимостями с учетом бизнес-рисков, организации могут сблизить разработку и безопасность. Обе команды должны признать, что они работают над одной и той же целью: созданием безопасного и высококачественного программного обеспечения.
Мы перечислили лучшие облачные антивирусы.
Эта статья была создана в рамках канала Expert Insights от TechRadarPro, где мы демонстрируем лучшие и самые яркие умы в области технологий сегодня. Мнения, выраженные здесь, принадлежат автору и не обязательно отражают точку зрения TechRadarPro или Future plc. Если вы заинтересованы в участии, узнайте больше здесь:
