CycloneDX / CycloneDX/cyclonedx-gradle-plugin

SBOM metadata marked as @Internal may be excluded from Gradle inputs, raising reproducibility and cache correctness concerns

Open
#830 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.