Что бы вам ни понадобилось, для этого есть приложение. По данным Business of Apps, в 2024 году в Apple App Store будет 1,81 миллиона приложений. Эта растущая тенденция распространилась из наших карманов на наш бизнес с ростом внедрения программного обеспечения как услуги (SaaS) и облачных вычислений. Среднестатистическая компания имеет 371 SaaS-приложение, при этом IDC обнаружила, что в первой половине 2023 года компании потратили 315,5 млрд долларов на публичные облачные сервисы.
Все это программное обеспечение и все эти приложения созданы людьми, а люди, как известно, допускают ошибки. Ошибки при разработке программного обеспечения повышают вероятность атак, приводящих к нарушениям безопасности. Если умножить эти риски на размер вашего технологического стека, обеспечение безопасности вашей среды кажется практически невозможным.
Содержание
Обнаруживайте проблемы на ранней стадии
Чтобы снизить риски и снизить нагрузку на безопасность, выявляйте проблемы на ранних этапах процесса разработки программного обеспечения. Это называется концепцией «сдвига влево», поскольку она предполагает выполнение сканирования и проверки безопасности на более ранних этапах жизненного цикла разработки программного обеспечения (SDLC). Программное обеспечение для сканирования в конвейере непрерывной интеграции/непрерывного развертывания (CI/CD) обнаруживает проблемы, требующие внимания, прежде чем они станут уязвимыми для злоумышленников. Обнаружив ошибки, неправильные конфигурации или уязвимости раньше, вы также сможете исправить их раньше и с меньшими затратами, чем если бы те же проблемы возникали в производственных приложениях или были частью программного обеспечения, развернутого на тысячах или миллионах реальных ресурсов.
Хотя в последние годы концепция безопасности со сдвигом влево обсуждалась как лучшая практика, она, похоже, не реализована должным образом. Данные отчета Sysdig 2024 Cloud-Native Security and Usage Report показали, что сканирование производственных систем завершалось неудачно чаще, чем сканирование в конвейере сборки CI/CD. В отчете выявлено 91% ошибок политики производственного сканирования, а в 71% случаев сканирование CI/CD завершилось неудачей. Сканирование CI/CD выполняется перед сканированием среды выполнения. Поэтому любые ошибки, зафиксированные в конвейере сборки CI/CD, следует исправлять перед сканированием во время выполнения. Так почему же мы видим такой высокий процент сбоев во время выполнения, если концепция сдвига влево — лучший подход?
Стратег по кибербезопасности, Sysdig.
Вносите изменения в свои процессы
Прежде всего, улучшение сотрудничества между командами, а не просто удовлетворение требований безопасности, почти всегда оказывается более эффективным и устойчивым. С точки зрения разработчика, Shift-Left требует дополнительных обязанностей по исправлениям и изменениям без дополнительной поддержки. Для них сдвиг влево может выглядеть скорее как увеличение рабочей нагрузки, чем изменение подхода, которое может снизить риски безопасности.
Чтобы преодолеть это препятствие и заставить работать процессы сдвига влево, сотрудники службы безопасности должны понимать, как их коллеги-разработчики на самом деле работают на практике. Соблюдают ли создаваемые ими приложения традиционные принципы проектирования, являются ли они облачными приложениями, которые являются распределенными, неизменяемыми и эфемерными (DIE), или существует комбинация сборок при переходе от традиционных к облачным приложениям?
Лучше понимая, насколько сложны их среды и сборки приложений, группы безопасности могут помочь разработчикам выявить риски, существующие в их приложениях, а также расставить приоритеты и смягчить самые серьезные угрозы до того, как они будут реализованы в рабочей среде. Также следует определить, насколько велик риск для вашей компании и вашей среды и какие шаги необходимо предпринять для снижения риска. Этот процесс гарантирует, что разработчики могут сосредоточиться на любых изменениях, которые им необходимо внести там, где они необходимы больше всего, например, на критических уязвимостях, которые можно использовать, или неправильных конфигурациях.
Аналогичным образом, группы безопасности и их инструменты также могут отмечать, где в стандартные образы контейнеров могут быть включены ненужные компоненты или разрешения. Разработчики часто используют программные контейнеры или образы компьютеров в качестве стандартизированных шаблонов для развертывания. Однако если эти шаблоны содержат устаревшие компоненты, любое использование этого шаблона будет помечено как дополнительная угроза безопасности. Обновление шаблонов рабочей нагрузки разработчика сокращает количество предупреждений и рисков безопасности, а также сводит к минимуму повторяющуюся работу.
Улучшите безопасность подготовки к производству
В идеале программные контейнеры должны быть неизменяемыми. Это означает, что рабочая нагрузка не меняется во время выполнения. Дрейф контейнера, то есть изменения и обновления контейнера во время производства, часто вызывает оповещения системы безопасности, но это обычная практика для разработчиков. Когда разработчики воздерживаются от изменений рабочей нагрузки во время выполнения (контроль дрейфа), группы безопасности могут установить более чувствительные и надежные методы обнаружения дрейфа контейнеров, которые указывают на потенциально вредоносную активность, а не на шум разработки.
Сканирование во время выполнения более точно обнаруживает проблемы безопасности, активные в производственной среде. Благодаря этим сканированиям проблемы безопасности становятся ближе к команде безопасности, а не передаются разработчикам. Проблемы в производственной среде могут негативно повлиять на бизнес-операции.
Долгосрочные выгоды в области безопасности
Мы все полагаемся на программное обеспечение и приложения в нашей повседневной жизни и организациях. Это программное обеспечение должно быть защищено. Мы можем повысить безопасность, двигаясь влево и придерживаясь принципа «безопасность задумана». Безопасно созданное программное обеспечение и приложения представляют меньший риск атак и вызывают меньше ошибок при проверке политики, снижая нагрузку на безопасность как для групп безопасности, так и для разработчиков.
На практике группам безопасности необходимо работать с разработчиками, чтобы определить, где существуют эти потенциальные риски и как их можно устранить. В то же время разработчики могут обучать команды безопасности и сотрудничать с ними, чтобы предотвратить проблемы, связанные с вводом кода или компонентов инфраструктуры. Такая командная работа и разделение общих целей улучшат общее качество программного обеспечения и безопасность во всей организации.
Мы перечислили лучшее программное обеспечение для разработки мобильных приложений.
Эта статья была создана в рамках канала Expert Insights от TechRadarPro, где мы рассказываем о лучших и ярких умах в области технологий сегодня. Мнения, выраженные здесь, принадлежат автору и не обязательно принадлежат TechRadarPro или Future plc. Если вы заинтересованы в участии, узнайте больше здесь:
