CycloneDX / CycloneDX/cyclonedx-gradle-plugin
SBOM metadata marked as @Internal may be excluded from Gradle inputs, raising reproducibility and cache correctness concerns
- Dominant language
- Java
- Stars
- 239
- Forks
- 102
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 11
Description
### Bug Description
## Question: SBOM metadata marked as @Internal in CyclonedxDirectTask
In `CyclonedxDirectTask`, several SBOM-related properties are annotated with `@Internal`:
- `OrganizationalEntity`
- `LicenseChoice`
- `ExternalReference`
These fields clearly contribute to the generated SBOM content.
---
## Core concern
From a semantic and reproducibility standpoint, these values are part of the SBOM definition:
- License information affects compliance metadata
- Organizational entity affects provenance/attribution
- External references affect supply chain traceability
However, marking them as `@Internal` means they are excluded from Gradle’s task input tracking and do not influence the build cache key.
---
## Questions about design intent
I’d like to understand the reasoning behind this decision:
1. Is this an intentional design choice to treat SBOM metadata as non-cache-influencing data?
2. Or is it meant to avoid unnecessary cache invalidation for metadata-only changes?
3. How is correctness of cached SBOM outputs ensured if these values change?
---
## Reproducibility concern
If these properties are excluded from task inputs:
- Cached SBOM outputs may be reused after metadata changes
- Output may no longer reflect the current SBOM configuration
- This weakens reproducibility guarantees for SBOM artifacts
---
## Clarification requested
Is the use of `@Internal` here:
- A deliberate design decision for SBOM generation behavior?
- Or a known limitation / oversight in the current implementation?
Also, is there a recommended pattern to ensure that changes to SBOM metadata properly invalidate Gradle task caching?
### Self-contained Reproducer Project
A minimal reproducer is not provided at this stage, as the issue relates to task input classification and SBOM metadata design rather than a concrete runtime or caching defect.
If required, I can provide a minimal Gradle plugin example demonstrating the current behavior.
### Expected Behavior
From a reproducibility and build correctness perspective, SBOM-related metadata (such as organizational information, license data, and external references) is expected to:
- Be treated as part of the task’s declarative inputs
- Be included in Gradle’s input tracking model (@Input or @Nested)
- Invalidate the task cache when any of these values change
- Ensure that regenerated SBOM outputs always reflect the current configuration
### Gradle build scan URL (optional)
_No response_
### OS
_No response_
### Gradle version
9.4.1
### CycloneDX Plugin version
3.2.4
### Additional Context
_No response_
### Contribution
- [ ] I am willing to provide a fix
- [x] I will wait until somebody else fixes it
Contributor guide
Research direction
Start by inspecting CyclonedxDirectTask and the @Internal annotations on OrganizationalEntity, LicenseChoice, and ExternalReference. Review the plugin's Gradle task input and caching behavior, then determine whether metadata changes affect generated SBOM outputs and what tests would demonstrate correct invalidation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100