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