DevOps
Узнать большеВ мире, где все больше процессов — от общения до финансовых операций — происходит в интернете, защита программного обеспечения становится основой его стабильной работы. Поэтому важно учесть требования к безопасности ПО с самого начала разработки. Уязвимости могут появляться прямо в коде, и злоумышленники используют их для атак: SQL-инъекции, DDoS, перехват данных, межсайтовый скриптинг и другие. Чтобы предотвратить такие проблемы, разработчики используют разные методы тестирования:
- статическое,
- динамическое,
- анализ состава приложений,
- цепочки поставок и лицензионных рисков.
В статье подробнее раскроем требования по безопасности, предъявляемые к ПО, и расскажем о каждом методе контроля.
О требованиях к безопасности ПО
Правила и стандарты информационной безопасности требуют учитывать следующие аспекты:
- Конфиденциальность данных. Вся обрабатываемая информация должна быть защищена от несанкционированного доступа. Особенно важны критичные данные, которые нужно хранить и передавать в зашифрованном виде. Для этого следует использовать протокол TLS и применять алгоритмы шифрования на уровне ПО.
- Целостность данных. Важно, чтобы данные не могли быть изменены без ведома пользователя. Для этого применяются алгоритмы шифрования и надежные механизмы аутентификации.
- Доступность данных и ключевых функций приложений. Одно из требований к безопасности ПО — даже при наличии всех мер безопасности пользователи должны иметь возможность без проблем работать с приложением. Все функции должны быть доступны тем, у кого есть на это права.
- Аудит и контроль безопасности. Разработчикам нужно предусмотреть возможность отслеживания пользовательских действий и событий внутри ПО. Это помогает выявить проблемы и быстро реагировать на них.
Чтобы повысить безопасность программных продуктов, ФСТЭК России рекомендует улучшать качество разработки, обеспечивать безопасность сборочной среды, защиту кода и поддерживать готовые решения.
ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения» задает основные требования к безопасности ПО и определяет порядок работ по созданию защищенных продуктов. Разработчики должны следовать этому стандарту для выпуска надежных программных решений на отечественный рынок.
Концепция DevSecOps для соблюдения требований по безопасности, предъявляемых к ПО
DevSecOps — подход, который делает разработку программного обеспечения безопасной. Он помогает найти баланс между защищенностью ПО, скоростью выпуска приложений и их качеством. Суть в том, что обеспечение безопасности становится частью процесса, а не просто добавляется в конце.
Процесс безопасной разработки в рамках подхода DevSecOps можно разделить на пять этапов:
- Анализ актуального ландшафта угроз — оценка текущих рисков и возможных уязвимостей.
- Планирование — определение требований к безопасности ПО.
- Разработка — внедрение безопасных методов кодирования и проведение тестирований на наличие уязвимостей, ошибок в коде.
- Тестирование — комплексная проверка безопасности создаваемого продукта.
- Эксплуатация — мониторинг угроз и быстрая реакция на инциденты.
Как видно, в DevSecOps безопасность находится в фокусе с самого начала разработки. Для сравнения — в рамках стандартного подхода создания ПО проверки безопасности проводятся только на определенном этапе. DevSecOps же подразумевает непрерывный процесс сотрудничества команд разработчиков и безопасников.
Методы проверки и контроля соблюдения требований безопасности, предъявляемых к ПО
Подробнее расскажем, как платформа Solar appScreener помогает обеспечить комплексную безопасность при разработке приложений.
Статическое тестирование
Static Application Security Testing (SAST) — самый распространенный метод проверки, с помощью которого можно узнать, соблюдены ли требования по безопасности, предъявляемые к ПО. Он заключается в анализе кода на наличие уязвимостей, ошибок и недекларированных возможностей. Главное преимущество — можно проверить практически 100% написанного кода, не запуская при этом программу. Однако нужно иметь доступ к исходному коду, поэтому такое тестирование называется стратегией белого ящика.
Обобщенный алгоритм статической проверки с помощью Solar appScreener:
- Создается промежуточное представление кода.
- Этот код проверяется с помощью различных методов статического анализа (лексического, синтаксического, семантического, taint-анализа, исследования потока управления и потока данных).
- Применяется комплекс правил обнаружения уязвимостей.
В результате формируются отчеты, где отражен перечень найденных проблем, распределенных по степени критичности. К этому списку прилагаются экспертные рекомендации по устранению уязвимостей.
Solar appScreener позволяет соблюдать требования к безопасности ПО, даже если у вас нет доступа к исходному коду. Такое может быть, если приложения разрабатывались сторонними разработчиками, наследовались или были скачаны из интернета. С помощью комплексного анализатора проводится анализ бинарного кода с предварительным применением механизмов декомпиляции и деобфускации.
Применение Solar appScreener позволит нивелировать главный минус анализа SAST — False Positive (ложноположительные срабатывания — сообщения о проблемах, которые фактически отсутствуют). Для минимизации False Positive в анализаторе используется технология Fuzzy Logic Engine, разработанная и запатентованная командой ГК «Солар».
Динамическое тестирование
Dynamic Application Security Testing (DAST) — тестирование уже развернутых и работающих приложений, но не завершенных — могут дорабатываться в процессе. Для такого анализа требуется имитированная рабочая среда, максимально приближенная к реальной. В отличие от статистического тестирования, при DAST не нужно иметь доступ к программному коду и структуре ПО, поэтому этот метод и называется стратегией черного ящика.
DAST имитирует атаки на приложения для поиска слабых мест, которые проявляются только при эксплуатации. Инструменты анализатора могут симулировать действия пользователей и атак хакеров, проверяя корректность работы программного обеспечения, а также исследуя реакцию на запросы. В платформе Solar appScreener предусмотрены разные виды сканеров:
- традиционный,
- пассивный,
- автоматический,
- AJAX,
- Fuzzer.
Также можно настроить степень агрессивности атаки.
Внедрение DAST на завершающих этапах разработки позволяет соблюдать требования к безопасности ПО, но часть уязвимостей все равно может быть упущена, так как не обеспечивается полное покрытие кода. Поэтому для наиболее эффективного анализа безопасности стоит использовать оба метода — и динамическое, и статическое тестирование. В Solar appScreener можно объединить результаты проверок коррелировать и получать развернутые детальные отчеты.
Анализ состава программ и цепочки поставок, оценка лицензионных рисков
Software Composition Analysis (SCA), Supply Chain Security (SCS) и анализ лицензионных рисков объединены в Solar appScreener в общий модуль — OSA. Особенности этих видов тестирований:
- SCA помогает проверять надежность всех компонентов Open source, которые используются в программе. Этот анализ стоит применять с начальных этапов разработки, чтобы оперативно выявить возможные уязвимости. С помощью SCA можно обнаружить: программные закладки, уязвимости в сторонних библиотеках, которые используют разработчики, а также проблемы с лицензированием открытых компонентов. Чтобы выполнить тестирование, достаточно загрузить программный код, ссылку на репозиторий или SBOM-файл в интерфейсе Solar appScreener. Если SBOM-файл отсутствует, анализатор соберет его самостоятельно из предоставленных исходников. Затем он считает все заимствованные фрагменты и проверит их с помощью баз уязвимостей.
- SCS помогает обеспечить безопасность на всех этапах пути, по которому ПО попадает к пользователям, — от момента создания или покупки продукта до начала эксплуатации. Этот анализ дает комплексную оценку всем используемым сторонним компонентам на основе 8 критериев: популярности, авторскому составу, активности сообщества, уровню заинтересованности в безопасности, давности создания библиотеки, подозрительной «высоты» первой версии, количеству проектов разработчика, процента пул реквестов, которые не выполняют требование рецензии от двух человек.
- Анализ лицензионных рисков нужен для минимизации юридических проблем, связанных с получением лицензий на открытые компоненты. Например, проверка позволит выявить отсутствие лицензий, несовместимость лицензий разных заимствованных компонентов.
Эти виды анализа помогут соблюсти требования к безопасности ПО, позволяя превентивно выявлять возможные уязвимости, связанные с внедрением сторонних компонентов.
Преимущества выполнения требований безопасности ПО
Перечислим ключевые моменты:
- Уменьшение затрат на выпуск ПО без потери качества. Внедрение безопасной разработки помогает заранее устранять недостатки продуктов и сэкономить бюджет на исправление последствий инцидентов ИБ.
- Снижение рисков утечек данных и атак на приложения — помогает избежать санкций и штрафов за несоблюдение требований по безопасности, предъявляемых к ПО.
- Повышение доверия пользователей. Безопасность продуктов напрямую влияет на репутацию разработчика, увеличивая доверие клиентов и пользователей.
- Выполнение требований регуляторов. Соблюдение норм ФСТЭК России, ЦБ и других регулирующих органов по безопасности ПО помогает избежать юридических последствий.
К тому же, если тестировать ПО на всех стадиях разработки, можно существенно ускориться процесс выпуска продукта. Это поможет избежать сложных и затратных работ по устранению уязвимостей в уже готовых приложениях.
