CycloneDX task seems to auto-attach itself as dependency to various standard kotlin tasks

[MartinHaeusler]

Describe the bug

• The CycloneDX task seems to attach itself automatically to various existing tasks in our project.
• The consequence is that kotlin compilation of the project cannot be executed without also building the CycloneDX SBOM.
• Another consequence is that any gradle refresh in IntelliJ IDEA also runs the CycloneDX SBOM.
• Since the SBOM task is slow by nature (since it has to fetch all these POM files over the network) it also slows down our development process quite a lot, especially in cases where we're not interested in the output in the first place.

To Reproduce

Here's our configuration:

tasks.cyclonedxBom {
    setIncludeConfigs(listOf("runtimeClasspath"))
    setSkipConfigs(listOf("compileClasspath", "testCompileClasspath"))
    setProjectType("application")
    setSchemaVersion("1.7")
    setDestination(project.file("build/reports"))
    setOutputName("bom")
    setOutputFormat("json")
    setIncludeBomSerialNumber(false)
    setComponentVersion("2.0.0")
}

That's all we do. None of our tasks have an explicit dependency on cyclonedx. The gradle build scan shows that the cyclonedxBom task has no successors and no predecessors, but it still runs on any build as far as I can tell, no matter which top-level gradle task gets executed.

Expected behavior
I would expect that the cyclonedxBom task only gets executed when it is listed as a top-level gradle command (e.g. ./gradlew cyclonedxBom). However, it gets automatically executed as part of various other tasks as well (including compilation).

Environment (please complete the following information):

• OS: various Linux x64 distros (Mint, Ubuntu, Fedora, Alpine...) the issue occurs on all of them.
• Gradle version: 8.10
• CycloneDX Plugin version 1.7.4

Additional context
We have a quite complex multi-module gradle build process. We declare the CycloneDX dependency in our libs.versions.toml file:

bom = { id = "org.cyclonedx.bom", version = "1.7.4" }

... and we include it like this in our top-level gradle file:

plugins {
    // ...
    alias(libs.plugins.bom) apply false
    // ...
}

The relevant subprojects then activate it:

plugins {
    // ...
    alias(libs.plugins.bom)
    // ...
}