JetBrains оновила Qodana до версії 2026.2 — тепер командам розробки простіше реагувати на проблеми якості коду, безпеки та відповідності стандартам просто в процесі роботи. У новому релізі з'явилося наочніше відображення покриття тестами для пул-реквестів, підсвітка непокритих рядків коду прямо в IDE, а також автоматичне виявлення звітів про покриття у типових місцях проєкту, що знижує потребу в ручному налаштуванні.
Крім того, розробники розширили можливості безпеки: додали нові інспекції, підтримку власних правил безпеки, перевірки на постквантову криптографію та публічні бенчмарки SAST через SABER. Інспекції для Laravel тепер увімкнені за замовчуванням, а нові якісні бар'єри License Audit допомагають командам блокувати потрапляння в пайплайн залежностей із забороненими або невідомими ліцензіями.
Зручніша робота з покриттям коду
Покриття коду для інкрементального аналізу в IDE
Починаючи з Qodana 2026.2, аналіз пул-реквестів показує, які змінені чи додані рядки покриті тестами, а які ні, а також загальний показник покриття для нового коду — так званий fresh coverage.
Після завершення аналізу розробники можуть відкрити звіт просто в IDE та переглянути файли, змінені в пул-реквесті. У вікні інструменту видно статистику по файлах без належного покриття, а нові рядки коду підсвічуються прямо в редакторі, вказуючи на прогалини. Це дозволяє писати цілеспрямовані тести саме для тієї функціональності, яка лишилася непокритою, підвищуючи надійність програмного забезпечення.
Готове рішення для звітності про покриття
Тепер, щоб побачити результати покриття коду в Qodana, потрібно набагато менше налаштувань. Більше не обов'язково копіювати всі звіти в директорію .qodana/code-coverage — це спрощує конфігурацію збірки.
Qodana 2026.2 автоматично знаходить звіти про покриття в проєкті:
- Qodana для JVM та Qodana для Android: підтримуються стандартні шляхи для плагінів Jacoco і Kover як у Maven, так і в Gradle
- Qodana для JS: підтримується типове розташування coverage/lcov.info, а також поширені серед спільноти директорії reports чи test-coverage
- Qodana для PHP: підтримуються файли clover.xml і coverage.xml у типових місцях — корені проєкту, build/logs, reports і coverage
- Qodana для Python: підтримується файл coverage.xml у типових локаціях — корені проєкту, coverage-reports чи reports
- Qodana для Go: підтримуються файли coverage.out або cover.out у кореневій директорії та інших типових місцях на кшталт coverage, reports
- Qodana для .NET: підтримуються файли coverage.cobertura та coverage.info в корені проєкту або в інших типових директоріях — coverage чи TestResults
Щоб отримувати звіти про покриття, достатньо налаштувати один з підтримуваних інструментів — і статистика з'явиться в кожному запуску. Якщо потрібно відключити цю поведінку, можна вибірково копіювати звіти в директорію .qodana/code-coverage або вказати власне розташування через новий параметр codeCoverageLocations у файлі qodana.yaml. Приклад налаштування власної директорії наведено в документації. Щоб повністю вимкнути звітність про покриття, достатньо відключити відповідну інспекцію в конфігурації.
Нові інспекції безпеки
Ширший SAST і багатофайловий taint-аналіз
У Qodana 2026.2 розширено аналіз безпеки в лінтері Qodana для .NET — тепер він допомагає командам виявляти більше типів вразливостей у коді на C#, JavaScript та TypeScript. Нові інспекції увімкнені за замовчуванням у рекомендованому профілі та відображаються як звичайні знахідки Qodana в наявних робочих процесах IDE, CI/CD та звітності.
Розширений набір інспекцій поєднує два підходи до аналізу. Правила пошуку патернів виявляють небезпечні практики написання коду в окремих ділянках, тоді як taint-аналіз відстежує, як недовірені дані проходять крізь застосунок, зокрема через кілька файлів. Завдяки цьому Qodana може виявляти такі вразливості, як SQL-ін'єкції, командні ін'єкції, міжсайтовий скриптинг (XSS) та обхід шляхів (path traversal).
Команди також можуть розширювати це покриття власними правилами безпеки. Qodana для .NET тепер підтримує кастомні та сторонні правила у форматі OpenGrep. Достатньо розмістити такі правила в директорії .qodana/opengrep у корені проєкту — і Qodana підключить їх як власні інспекції.
Готові правила доступні у відкритому репозиторії opengrep-sast-rules. Під капотом пошук патернів працює на основі відкритого форку OpenGrep від JetBrains, а відстеження потоків даних забезпечує власний taint-аналіз Qodana. Це дає командам доступ до формату правил і екосистеми OpenGrep, зберігаючи при цьому багатофайловий аналіз та звичні робочі процеси Qodana. У майбутніх релізах підтримку планують поширити на інші лінтери Qodana та мови, зокрема Kotlin і Java.
У прикладі показано, як Qodana виявляє класичну вразливість SQL-ін'єкції в проєкті WebGoat.NET. Taint-трасування простежує шлях недовіреного вводу від Request["productNumber"] до його використання в SQL-запиті, розташованому в іншому файлі.
SABER — Static Analysis Benchmark Evaluation Runner
Щоб полегшити оцінку ефективності нових інспекцій, розробники представили SABER — Static Analysis Benchmark Evaluation Runner. Цей інструмент запускає Qodana на публічно доступних бенчмарках безпеки та порівнює отримані результати з очікуваними.
Прозоре бенчмаркінгове тестування SAST через SABER охоплює:
- бенчмарки CodeQL для C# і JavaScript, побудовані на файлах .expected із CodeQL
- WebGoat.NET, з використанням публічно доступних еталонних даних від Sonar
- демонстраційний проєкт Qodana з постквантовою криптографією
Конфігурації бенчмарків, окремі запуски та зведені результати відкрито опубліковані на інстансі SABER TeamCity. Доступ для гостей увімкнено — будь-хто може переглянути результати та стежити, як розвиваються можливості SAST у Qodana з часом. Потрапити туди можна через опцію «Log in as guest». Команда наголошує, що прагне прозоро демонструвати можливості SAST і постійно вдосконалювати їх за допомогою галузевих стандартних бенчмарків.
Проєкти «CodeQL C#» та «CodeQL JS» використовують jetbrains-qodana/codeql-benchmark — проєкт, побудований на файлах .expected із CodeQL. Проєкт WebGoat.NET — це відомий вразливий C#-проєкт (форк JetBrains доступний тут: jetbrains-qodana/WebGoat.NET), який використовує публічний файл ground-truth.json як еталон. Демо-проєкт PQC — це тестовий проєкт, що демонструє здатність виявляти проблеми постквантової криптографії в коді.
Інспекції постквантової криптографії (PQC)
Квантові обчислення в майбутньому здатні легко зламати багато поширених алгоритмів криптографії з відкритим ключем, зокрема RSA та ECC. Хоча квантові комп'ютери ще не набули широкого поширення, готуватися варто вже зараз через підхід «зберегти зараз, розшифрувати пізніше» (Harvest Now, Decrypt Later), коли зловмисники вже сьогодні можуть збирати й зберігати зашифровані дані, щоб розшифрувати їх пізніше.
Qodana для JVM тепер включає інспекції, які допомагають розробникам знаходити вразливий код і переходити на постквантові альтернативи криптографії, знижуючи майбутні ризики безпеки та підтримуючи поступову, керовану міграцію для готовності організацій до загроз квантової ери.
Інспекції PQC реалізовані відповідно до рекомендацій NIST і згруповані за кількома рівнями пріоритету — від PqcMinLevel1 до PqcMinLevel5. Щоб увімкнути ці перевірки, потрібно активувати одну з груп, що відповідають рівням готовності до постквантової ери за класифікацією NIST:
- Рівень 1 — позначає докваантові та застарілі криптографічні алгоритми, виявляючи найкритичніші вразливості
- Рівень 2 — позначає базові постквантові алгоритми
- Рівень 3 — позначає постквантові алгоритми стандартної надійності
- Рівень 4 — позначає постквантові алгоритми високої надійності
- Рівень 5 — позначає всі алгоритми, крім тих, що забезпечують максимальний рівень безпеки
Кожен наступний рівень включає всі попередні, тож п'ятий рівень охоплює й інспекції рівнів з першого по четвертий.
Розробники також підготували демонстраційний проєкт (PQC demo), що показує поточні можливості цих інспекцій. В основі перевірок лежать OpenGrep та taint-аналіз, які, як уже згадувалося, забезпечують якісний пошук патернів і багатофайлове відстеження потоків даних для Java і Kotlin, як показано на прикладі з рядковою константою, що містить невідповідний криптографічний протокол.
Перевірки Laravel — за замовчуванням
Qodana для PHP тепер містить інспекції для коду на Laravel. Це зменшує кількість хибних спрацювань у PHP-коді та дозволяє виявляти специфічні для Laravel проблеми, такі як пряме присвоєння значень захищеним (guarded) атрибутам.
Якісні бар'єри для аудиту ліцензій
Qodana 2026.2 додає підтримку якісних бар'єрів для аудиту ліцензій із двома новими опціями:
- failOnProhibited — зупиняє запуск, якщо будь-яка залежність використовує ліцензію, заборонену налаштованими правилами
- failOnUnknown — зупиняє запуск, якщо ліцензію якоїсь залежності не вдалося визначити чи класифікувати
Наприклад, у файлі qodana.yaml секція failureConditions тепер може містити блок dependencyLicenses:
failureConditions:
dependencyLicenses:
failOnProhibited: true
failOnUnknown: true
Qodana оцінює цей якісний бар'єр безпосередньо за зібраними ліцензіями залежностей, незалежно від того, чи присутні результати License Audit серед знахідок інспекції. Для роботи достатньо ввімкнути лише інспекцію CheckDependencyLicenses.
Якісні бар'єри аудиту ліцензій також працюють в інкрементальному аналізі, зупиняючи процес лише через нові порушення.
Що робити далі
Ті, хто вже користується найновішим релізом, можуть одразу почати застосовувати нові можливості Qodana 2026.2. Якщо ж ні — варто оновитися до цієї версії.
Деталі налаштування та поради щодо окремих функцій можна знайти в документації. Спробувати можливості Qodana на власному проєкті чи ознайомитися з іншими оновленнями можна в блозі Qodana.
Джерело: Kotlin Blog
