Solar inCode — анализатор кода приложений на наличие уязвимостей и недокументированных возможностей. Его отличительной особенностью является возможность анализа не только исходного кода, но и исполняемых файлов (то есть представленных в бинарном виде), что позволяет значительно превзойти результаты, получаемые с помощью динамического анализа (DAST). Поддерживает 20+ языков программирования и 7 расширений файлов.
Введение
Solar inCode представляет собой инструмент для проверки мобильных и веб-приложений на уязвимости с помощью статического анализа кода. Внедрение inCode в процесс создания программного обеспечения позволяет выявлять уязвимости еще на этапе разработки. Это облегчает процесс их устранения и контроля уровня безопасности приложений. Инструмент может быть интегрирован с такими продуктами, как среды разработки, средства сборки, серверы непрерывной интеграции, системы контроля ошибок. Рассмотрим особенности inCode, которые помогут быстрее верифицировать и устранить уязвимости при разработке приложений.
Возможности inCode
Интеграция со сторонними инструментами
Интеграция с серверами CI
Плагины Solar inCode к серверам непрерывной интеграции позволяют сделать статический анализ частью автоматизированных сборок. Запуск сканирований будет происходить по триггерам, а результаты будут доступны в интерфейсе inCode или выгружаться в виде отчета. Из коробки можно осуществить интеграцию с Jenkins и TeamCity.
Интеграция со средствами сборки
Для inCode доступна интеграция с maven, gradle и sbt. Интеграция осуществляется с помощью инструмента командной строки. Чтобы запускать анализ с помощью команды средства сборки, достаточно настроить конфигурационные файлы.
Интеграция с IDE
Плагин Solar InCode для интеграции с Eclipse позволяет проверять приложение на уязвимости на этапе разработки. Запустить анализ можно из интерфейса Eclipse, указав настройки соединения с системой.
Интеграция с помощью JSON API и CLT
Наиболее гибкая интеграция возможна с помощью JSON API и Command Line Tool. Подробнее о способах настройки интеграции можно узнать в документации inCode.
Интеграция с JIRA
После того как получены результаты анализа приложения, нужно верифицировать обнаруженные уязвимости и назначить ответственных за их устранение. В интерфейсе inCode можно создать задачу в JIRA, указав нужный проект в JIRA, приоритет задачи и ответственного за ее выполнение. Пока уязвимость не исправлена, при пересканировании приложения в интерфейсе inCode будет отображаться ранее созданная задача в JIRA и ее статус.
Исключение директорий
При анализе приложений может потребоваться исключить некоторые директории из анализа. Например, файлы с тестовым кодом. В них часто обнаруживается много уязвимостей, хотя они не влияют на безопасность самого приложения. Если указать соответствующие директории при запуске, ложных срабатываний станет меньше, а рейтинг безопасности точнее.
Опция также полезна для разработчиков: каждый может отслеживать безопасность только того кода, над которым он работает. Это сократит время, необходимое для изучения результатов, и ускорит устранение уязвимостей.
Чтобы исключить директории из анализа, нужно перечислить их в настройках при запуске анализа в inCode.
Рисунок 1. Исключение директорий из анализа
Выбор наборов правил
Если некоторые правила поиска уязвимостей не являются критичными для вашего приложения, можно исключить их из анализа. Для этого нужно сформировать набор, который будет включать только те правила, что нужно использовать при анализе.
Рекомендуем применять эту возможность с осторожностью. С каждым обновлением inCode база правил поиска уязвимостей становится больше, а существующие правила дорабатываются.
Выбрать наборы правил можно при запуске анализа. Для этого в разделе Наборы правил нужно выбрать язык и отметить необходимые наборы.
Рисунок 2. Выбор наборов правил в inCode
Посмотреть входящие в набор правила и создать пользовательские наборы можно на странице Управление правилами.
Изменение критичности уязвимостей
При верификации результатов анализа может оказаться, что исходная критичность уязвимости, которую показал инструмент, не соответствует реальной угрозе. Для правильной расстановки приоритетов задач можно редактировать критичность уязвимостей. Статистика и рейтинг будут пересчитаны. Внесенное изменение сохранится при последующих сканированиях данного приложения.
Рисунок 3. Чтобы изменить критичность одного вхождения, нужно кликнуть по цветному кружку в списке уязвимостей
Рисунок 4. Чтобы изменить критичность всех вхождений одной уязвимости, нужно выбрать соответствующее действие в меню пакета вхождений
Удаление уязвимостей
Если в конкретной ситуации обнаруженная уязвимость является ложным срабатыванием, можно отметить ее удаленной. Статистика и рейтинг будут пересчитаны, а ложные уязвимости не будут отображаться при последующих сканированиях.
Рекомендуется использовать именно эту функциональность для исключения ложных срабатываний. Если исключать из анализа целые директории или наборы правил, можно упустить и истинные срабатывания. Удаление уязвимостей исключает лишь конкретные срабатывания.
Чтобы удалить конкретное вхождение, выберите его из списка и перейдите во вкладку Управление уязвимостью. Нажмите кнопку Удалить вхождение.
Рисунок 5. Удаление уязвимости в inCode
Рисунок 6. Удаленные уязвимости можно восстановить, нажав кнопку Восстановить вхождение
Чтобы удалить все вхождения уязвимости, нужно вызвать меню соответствующего пакета с вхождениями и нажать кнопку Удалить все вхождения.
Рисунок 7. Удаление всех вхождений
Чтобы удаленные уязвимости не отображались в списке уязвимостей, примените фильтр. Для этого чекбокс Показать удаленные уязвимости не должен быть выбран.
Рисунок 8. Фильтрация списка уязвимостей
Комментирование уязвимостей
Если при просмотре уязвимостей необходимо изменить критичность уязвимости или удалить вхождение, полезно оставить комментарий с указанием причины редактирования результатов.
Рисунок 9. Чтобы оставить комментарий к выбранному вхождению, нужно перейти во вкладку Управление уязвимостью
Отслеживание уязвимостей между сканированиями
При повторном сканировании для уязвимости указывается номер строки, в которой она находилась при предыдущем сканировании.
Рисунок 10. Отслеживание уязвимостей в inCode
inCode сохраняет ваши изменения в результатах предыдущих сканирований. Если поменять критичность уязвимостей, оставить комментарий, удалить уязвимость или создать задачу в JIRA по ее устранению, при последующем сканировании все изменения сохранятся. Поэтому тщательная обработка результатов первого сканирования позволит сэкономить время в дальнейшем.
Инкрементальный анализ
Еще одна возможность сэкономить время — уменьшить время анализа приложения. Включение опции Инкрементальный анализ при создании проекта в inCode позволяет сканировать только измененные файлы при повторном запуске.
Рисунок 11. Инкрементальный анализ для сканирования измененных файлов
Опция доступна для проектов на языках PHP, C#, JavaScript, T-SQL, PL/SQL, Python, Visual Basic 6, Ruby, ABAP, Delphi, HTML5, Solidity, Go или Groovy.
При значительных изменениях в коде рекомендуется проводить полный анализ. Использование инкрементального анализа может привести к потере уязвимостей, которые проходят через несколько файлов.
Отображение новых уязвимостей
Чтобы не отвлекаться на ранее обнаруженные уязвимости, можно воспользоваться фильтром при просмотре подробных результатов. Отключив опцию Показать сохранившиеся уязвимости, вы сможете отслеживать уязвимости в последних изменениях кода.
Рисунок 12. Отключение сохранившихся уязвимостей
Уязвимости в стандартных библиотеках
Доверяете Android и Google? Настройте фильтр, чтобы не отображать уязвимости, обнаруженные в их библиотеках. Так можно просматривать уязвимости только в вашем коде. Полный список стандартных библиотек указан в документации inCode.
Чтобы не отображать уязвимости в стандартных библиотеках, нужно применить фильтр. Для этого чекбокс Показать уязвимости в стандартных Java, Scala, Kotlin библиотеках не должен быть выбран.
Рисунок 13. Отключение отображения уязвимостей в стандартных библиотеках
Чтобы не анализировать стандартные JavaScript-библиотеки, отключите опцию Анализировать стандартные библиотеки при создании проекта. Файлы библиотек не будут проанализированы, что сэкономит время и ресурсы.
Рисунок 14. Отключение анализа стандартных библиотек
Рекомендации по настройке СЗИ
Близится релиз, а в приложении обнаружена критическая уязвимость? Возможно, от угрозы сможет защитить СЗИ. inCode предлагает рекомендации по настройке Imperva SecureSphere, ModSecurity и F5 для защиты от обнаруженных уязвимостей.
Чтобы посмотреть рекомендации по настройке, нужно выбрать уязвимость из списка на странице Подробные результаты и перейти во вкладку Настройки СЗИ.
Рисунок 15. Настройка СЗИ для защиты от обнаруженных уязвимостей
Fuzzy Logic Engine
FLE — это настройка фильтра, с помощью которой можно просматривать только «истинные» или только «важные» уязвимости. В зависимости от выбранного режима, вам будут показаны уязвимости с высокой вероятностью реальной угрозы или уязвимости, на которые стоит обратить внимание в первую очередь.
Рисунок 16. Просмотр только «истинных» или «важных» уязвимостей
Значение параметра confidence определяет чувствительность Fuzzy Logic Engine. Крайнее левое положение ползунка характеризует вхождения с самой высокой вероятностью корректного срабатывания, крайнее правое отобразит уязвимости для любой вероятности.
Рисунок 17. Чтобы самостоятельно выставить положения ползунков, выберите Пользовательский режим
При выборе Динамического режима можно установить перцентиль (значение от 1 до 100), в зависимости от которого будет отображаться определенная часть/процент самых важных уязвимостей.
Рисунок 18. Отображение части/процента наиболее критичных уязвимостей
Отчет о результатах сканирования
Результаты сканирования можно сохранить в виде PDF-отчета. В настройках экспорта можно выбрать одно или несколько сканирований, результаты которых включить в отчет.
В отчет можно включить подробные описания всех уязвимостей с приведением рекомендаций и фрагмента кода. А можно ограничиться рейтингом безопасности и статистикой по найденным уязвимостям.
Рисунок 19. Формирование отчетов в inCode
Рисунок 20. Чтобы не включать уязвимости, обнаруженные при предыдущих сканированиях, отключите опцию Добавить в отчет сохранившиеся уязвимости
Также можно исключить уязвимости в стандартных библиотеках Java, Scala, Kotlin. Для этого отключите опцию Добавить в отчет уязвимости в стандартных Java, Scala, Kotlin библиотеках.
Рисунок 21. Исключение из отчета уязвимостей в стандартных библиотеках
Уязвимости в отчете можно отсортировать по уровню критичности или по одному из способов классификации: OWASP Top 10, OWASP Mobile Top 10, PCI DSS, HIPAA, CWE/SANS Top 25.
Рисунок 22. Сортировка уязвимостей по классам
Создание дополнительных правил
Если есть уязвимая конструкция, которую не обнаруживает inCode, можно добавить новое правило поиска уязвимости. Для хранения правил разработан собственный универсальный формат XML. В руководстве пользователя вы найдете инструкцию по созданию новых правил.
Пример интеграции
Приведем пример из опыта внедрения inCode. На входе есть компания, которая занимается разработкой программного обеспечения. Структура компании включает в себя отдел разработки, отдел информационной безопасности (ИБ) и отдел управления релизами. В качестве инициатора интеграции выступает ИБ. До начала процесса необходимо составить технологическое описание интеграции и описание взаимодействия пользователей с inCode.
Релизный цикл включает в себя этапы планирования, разработки, тестирования и деплоя. Использование инструментов автоматической сборки (Jenkins, TeamCity) позволяет сделать анализ с помощью inCode частью сборки и выполнять его автоматически с заданной периодичностью на всех этапах релизного цикла.
На этапе разработки разработчики просматривают результаты анализа и по возможности устраняют найденные уязвимости.
На этапе тестирования результаты анализа просматривает специалист по информационной безопасности. Он верифицирует обнаруженные уязвимости: изменяет критичность или удаляет их. При необходимости назначает задачи по устранению. Интеграция с JIRA позволяет делать это сразу в интерфейсе inCode.
Управление релизами распределяет ресурсы так, чтобы релизная версия вышла в срок и была должного уровня безопасности.
Выводы
Solar inCode представляет собой гибкий инструмент статического анализа кода на уязвимости. Если ваша компания занимается созданием мобильных или веб-приложений, рекомендуем вам внедрить этот анализатор в процесс разработки.
Разделение ролей разработчиков и специалистов ИБ и постепенная интеграция в процесс (например, в первое время — использование результатов анализа на рекомендательной основе) позволит эффективно использовать инструмент. Так специалисты ИБ могут просматривать результаты анализа системой, затем верифицированные уязвимости будут устраняться разработчиками или блокироваться с помощью СЗИ.
Описанная выше функциональность облегчает и ускоряет устранение обнаруженных уязвимостей. Интеграция с CI позволит вам сканировать приложения в соответствии с расписанием автоматической сборки. Изменение критичности уязвимостей, комментирование, удаление вхождений, использование фильтров при просмотре уязвимостей — все это облегчит верификацию результатов анализа. А интеграция с JIRA позволит создавать задачи по устранению уязвимостей в интерфейсе inCode и далее назначать их разработчикам. Сохранение истории уязвимостей даст вам возможность отслеживать изменения в результатах анализа.
Таким образом, вы сможете следить за уровнем безопасности уже на этапе разработки и быстро устранять обнаруженные уязвимости. Это поможет вам выпускать качественный готовый продукт в срок.
