Правила#

Обзор#

Platform V Works::CodeScanner (далее CodeScanner) выполняет правила для исходного кода, чтобы создавать замечания. Существует четыре типа правил:

  • Ошибка;

  • Уязвимость;

  • Дефект кода;

  • Потенциальная уязвимость.

Для дефектов кода и ошибок ожидается нулевое количество ложных срабатываний. По крайней мере, такова цель, чтобы разработчикам не приходилось задаваться вопросом, требуется ли исправление.

Правило «Потенциальная уязвимость» обращают внимание на код, чувствительный к безопасности. Ожидается, что более 80% проблем будут быстро устранены в результате проверки разработчиком.

Правила#

По умолчанию, выбрав пункт верхнего меню Правила, пользователь увидит все доступные правила, установленные в CodeScanner. Также доступна возможность просмотра и сужения выбора на основе критериев поиска в левом боковом меню:

  • Язык: язык, к которому применяется правило;

  • Тип: правила для ошибок, уязвимостей, дефектов кода или потенциальных уязвимостей;

  • Тег: классификация правил для более легкого поиска;

  • Репозиторий: движок/анализатор, который вносит правила в CodeScanner;

  • Серьезность по умолчанию: исходная серьезность правила, определенная CodeScanner;

  • Статус: правила могут иметь 3 различных статуса:

    • Бета: Правило было недавно внедрено, поэтому возможны ложные срабатывания;

    • Устаревшее: это правило больше не следует использовать, поскольку существует аналогичное, но более мощное и точное правило;

    • Готовое: Правило готово к использованию в производстве;

  • Доступно с: дата, когда правило было впервые добавлено в CodeScanner. Это полезно, например, для списка всех новых правил с момента последнего обновления плагина;

  • Шаблон: отображение шаблонов правил, которые позволяют создавать собственные правила;

  • Профиль качества: включение в определенное правило или исключение из него;

Детали правила#

Чтобы ознакомиться с подробной информацией о правиле, нажмите на него левой кнопкой мыши или нажмите клавишу со стрелкой вправо. Представятся дополнительные сведения, включая профили, в которых используется правило, а также количество открытых замечаний, относящихся к этому правилу.

Следующие действия доступны только при наличии соответствующего уровня прав Администрирование профилей и порогов качества:

  • Добавить/удалить метки:

    • Можно добавить существующие метки к правилу или создать новые правила; просто введите новое имя в текстовое поле;

    • Обратите внимание, что некоторые правила имеют встроенные теги, которые нельзя удалить.

  • Расширенное описание:

    • Расширенное описание правила поможет пользователям лучше понять, каким образом компания применяет каждое правило, а также даст более ясное представление обо всех аспектах самого правила.

Шаблоны правил и собственные правила#

Чтобы найти шаблоны, выберите опцию Показать только шаблоны в выпадающем меню Шаблоны:

Шаблоны правил

Чтобы создать собственное правило на основе шаблона, перейдите в выбранный шаблон -> Создать рядом с заголовком Собственные правила и введите следующую информацию:

  • Имя;

  • Ключ (автопредложение);

  • Тип;

  • Серьезность;

  • Статус;

  • Описание (поддерживается формат Markdown);

  • Параметры, заданные шаблоном.

Выбрав ссылку в разделе Собственные правила, перейдите от шаблона к подробной информации о собственных правилах, определенных этим шаблоном.

Шаблоны правил 1

Шаблоны правил 2

Собственные правила#

Собственные правила рассматриваются как любые другие правила, за исключением того, что их можно редактировать или удалять.

При удалении собственного правила оно не удаляется физически из экземпляра CodeScanner. Вместо этого его статус устанавливается на «REMOVED». Это позволяет текущим или старым проблемам, связанным с этим правилом, корректно отображаться в CodeScanner до тех пор, пока они не будут полностью удалены.

Типы правил и степени серьезности#

Классификация правил#

Модель качества CodeScanner делит правила на четыре категории: Ошибки, уязвимости, потенциальные уязвимости и дефекты кода. Правила распределяются по категориям на основе ответов на следующие вопросы:

Относится ли правило к коду, который явно ошибочен или скорее ошибочен, чем нет?

Если ответ «да», то это правило об ошибках.

Относится ли правило к коду, который может быть использован злоумышленником?

Если да, то это правило уязвимости.

Правило касается кода, который является конфиденциальным с точки зрения безопасности?

Если да, то это правило потенциальной уязвимости.

Является ли правило ни ошибкой, ни уязвимостью?

Если да, то это правило дефект кода.

Определение серьезности и вероятности#

Ошибки#

Cерьезность: Может ли худшая вещь привести к аварийному завершению работы приложения или повреждению хранимых данных?

Вероятность: Какова вероятность того, что произойдет самое худшее?

Уязвимости#

Cерьезность: Может ли эксплуатация худшей уязвимости привести к значительному ущербу для ассетов или пользователей?

Вероятность: Какова вероятность того, что злоумышленник сможет воспользоваться худшей уязвимостью?

Потенциальные уязвимости#

Потенциальным уязвимостям не присваивается степень серьезности, поскольку до их рассмотрения неизвестно, действительно ли существует уязвимость, лежащая в их основе.

Правила безопасности#

Правила, связанные с безопасностью#

CodeScanner основан на различных представлениях исходного кода и технологиях, чтобы иметь возможность обнаружить любой тип замечаний безопасности:

  • Правила внедрения безопасности. Уязвимости появляются, когда приложение принимает вводимые пользователем данные (которые потенциально могут контролировать злоумышленники), не проверяя их безопасность или целостность перед обработкой. Это создает риск передачи вредоносных данных от пользователей прямо к критически важным функциям приложения. Чтобы предотвратить такие угрозы, инструмент CodeScanner применяет методы статического анализа исходного кода, выявляя возможные пути передачи небезопасных данных между источниками ввода и которая позволяет обнаружить:

  • Правила конфигурации безопасности. Проблемы с безопасностью возникают, когда при вызове защищенных функций используются некорректные параметры — например, устаревший шифровальный алгоритм или неподдерживаемая версия протокола TLS, либо отсутствует обязательная проверка прав доступа (check_permissions()). Эти ошибки могут регулярно приводить к сбоям защиты при работе программы.

Затем эти замечания безопасности делятся на две категории: уязвимости и потенциальные уязвимости.

Потенциальные уязвимости были введены для защиты средств, которые не оказывают прямого влияния на общую безопасность приложения. Большинство правил внедрений являются уязвимостями, например, если обнаружено SQL-внедрение, то наверняка требуется исправление (валидация ввода), поэтому это уязвимость. Напротив, при создании файла cookie, флаг „HttpOnly“ является дополнительным уровнем защиты (для уменьшения воздействия при появлении уязвимостей XSS), но его не всегда можно реализовать или он может оказаться неактуальным в зависимости от контекста приложения: поэтому это потенциальная уязвимость.

Охват стандартов безопасности#

Правила безопасности классифицируются в соответствии с общепризнанными стандартами безопасности, такими как:

Некоторые подробные примеры уязвимостей Java приведены здесь:

  • Java-vulnerability-issue-type: все правила уязвимостей для языка Java.

  • Java-hotspots-issue-type: все правила безопасности для языка Java.

  • Java-tag-injection: все правила внедрений безопасности для языка Java.

Встроенные теги правил#

Теги - это способ классифицировать правила и вопросы. Пользователи могут добавлять теги к правилам и вопросам, и большинство правил имеют некоторые встроенные теги. Вот неполный список того, что означают некоторые из этих встроенных тегов:

  • brain-overload: слишком много всего нужно держать в голове за один раз.

  • bad-practice: код, скорее всего, работает так, как задумано, но способ, которым он был разработан, признан плохой идеей.

  • CERT: относится к правилу в стандарте CERT. В настоящее время существует три стандарта CERT: C, C++ и Java. Многие из этих правил не относятся к конкретному языку, а являются хорошей практикой программирования. Поэтому этот тег доступен на правилах, не относящихся к C/C++ и Java.

  • clumsy: используются дополнительные шаги для выполнения того, что можно сделать более четко и лаконично. (Например, вызов .toString() для строки).

  • confusing: сопровождающим потребуется больше времени для понимания.

  • convention: обычно это форматирование, именование, пробельные символы и т.д.

  • CWE: относится к правилу в перечислении общих слабых мест. Подробнее о CWE и вообще о правилах, связанных с безопасностью, описано в разделе Правила безопасности

  • design: в дизайне кода есть что-то сомнительное.

  • lock-in: используются специфические для среды функции.

  • pitfall: пока все в порядке, но в будущем что-то может пойти не так; ловушка расставлена для следующего человека, и он, вероятно, попадет в нее и испортит код.

  • suspicious: не гарантировано, что это ошибка, но подозрительно похоже на ошибку. Как минимум, код следует пересмотреть.

  • unpredictable: код может работать нормально в текущих условиях, но при изменении условий может дать сбой.

  • unused: неиспользуемый код; например, приватная переменная, которая никогда не используется.

  • user-experience: с технической точки зрения в коде нет ничего плохого, но он может заставить некоторых или всех пользователей относиться к вам с негативом.