Hello Community!
This week’s highlight has to be the general availability announcement of the SonarQube Hunter Agent. If you’re on SonarQube Cloud on Enterprise plan and are interested in AI-powered security analysis, you really should be looking into this new product. Bye bye, complex business-logic-dependent vulnerabilities! If you’re on SonarQube Server… hang tight! It’s coming soon!
Other than that, we’ve had a few new features in Gitar: Harness support and Azure DevOps and Bitbucket support are now generally available. If these were your blockers for not having adopted Gitar yet, now you’re out of excuses.
So now, like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.
Scanners
Coverage from an aggregated JaCoCo report kept generating a wall of File '<filename>' not found in project sources warnings on a multi-module Gradle project. After earlier workarounds only papered over the issue, @Bug came back with an exceptionally thorough deep dive, showing that the documented aggregateXmlReportPaths fix silently drops coverage to 0% on Gradle (unlike Maven), and that SonarScanner for Gradle can auto-configure the property right back on even after it’s removed manually. Thanks for the detective work! We’re tracking both fixes in JACOCO-175 and JACOCO-176.
Rules & Languages
java:S3329 inconsistently flagged predictable IV usage in Cipher.init() depending on whether Cipher.DECRYPT_MODE was passed directly or stored in a local variable first, missing simple constant propagation. @Emilyaxe put together a clear reproducer showing the discrepancy. SONARJAVA-6853 was opened to fix it.
Long descriptions in Swagger/OpenAPI annotations (@Operation, @Schema, etc.) often trip java:S103’s line-length check even though they’re required documentation. @christian.jacob raised the idea of excluding annotation arguments from the check, and we agreed it’s worth doing. SONARJAVA-6841 will let us disable the rule on Swagger/OpenAPI annotations specifically.
cpp:S2737 was overeager about flagging a catch (std::bad_alloc&) { throw; } block ahead of a more generic catch (std::exception const&) as a pointless rethrow, when it’s actually needed to let bad_alloc escape. @Sebastian_Redl spotted the false positive, and we’ve added a rule exception: a handler that only rethrows won’t raise anymore when a later handler could catch the same exception type. It’ll roll out with upcoming releases.
PHPUnit assertions made inside a closure passed through a data provider weren’t recognized by php:S2699, even though the tests ran and asserted correctly. @decix-msauer flagged the gap, and we’ve confirmed it as a false positive that we’re fixing.
cpp:S109’s magic number exceptions (-1, 0, 1, 2, 3) were never extended to floating-point literals like 0.0F after floats came under the rule. @Josh_Rioux pointed out the inconsistency. We confirmed the gap was intentional, but agreed floats deserve the same treatment and have raised it internally to have it revisited.
Thanks again to everyone mentioned here - and to anyone we may have missed - for your ongoing contributions in making this community stronger and helping us improve Sonar products.
If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!