Vulnerability scanning

[jdaugherty]

Adds a vulnerability scanning workflow for grails-core

[jdaugherty]

@jamesfredley @matrei We'll have to manage exceptions here.

[jdaugherty]

Looks like the find main task is failing with these changes for some reason. It's likely due to the plexus update.

[jdaugherty]

Root cause: Adding the Sonatype scan plugin to build-logic/plugins/build.gradle changed the build-logic's content hash, which invalidated the Gradle build cache for all subproject tasks. When findMainClass runs fresh (not from
cache), MainClassFinder tries to read compiled Java 17 class files (major version 61) using groovyjarjarasm.asm.ClassReader — the ASM bundled with Groovy 3.x — which doesn't support class file version 61. This is a pre-existing bug
that was hidden by the build cache.

The fix is to switch MainClassFinder from groovyjarjarasm.asm (Groovy's bundled, potentially old ASM) to org.objectweb.asm (the explicit ASM library, version-managed by Spring Framework BOM at 9.7+, which supports Java 17+).

[jdaugherty]

Converting this to draft, the dependency bumps have caused gradle issues

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: d1e8460
▶️ Tests: 34054 executed
⚪️ Checks: 33/33 completed

---

Learn more about TestLens at testlens.app.

[jdaugherty]

Alright, the problem is that the ASM classes are shaded inside scan-gradle-plugin-3.1.5.jar itself. They're not a separate transitive dependency. Gradle exclusions only work on transitive dependencies, not on classes bundled inside a fat/shaded jar. So we can't exclude them with a standard exclude rule.

The find main class is picking the shaded version, which is frustrating.

[jdaugherty]

I've opened sonatype-nexus-community/scan-gradle-plugin#206

[jdaugherty]

sonatype-nexus-community/scan-gradle-plugin#207 is the fix for this. We can't adopt due to the classpath conflict. I'm hopeful Sonatype will accept the change.