Discussion: Add machine-readable-context-info to Gradle dependencies (aka WHY) and add it to cyclonedx json/xml report

[k3b]

Is your feature request related to a problem? Please describe.

I am an android software developer and i want to find out why certain dependencies are included.

The grade plugin org.cyclonedx.bom is a good tool to analyse the dependencies but i found now way to document in the sourcecode, why a dependency exists.

Describe the solution you'd like

As a SoftwareArchitect and Scrum-ProductOwner
I want to harvest the software libraries that my app uses (aka gradle-dependencies) and WHY these libs where added.
So that I can evaluate the risks(Attack surface), costs(in kilobytes) and benefites(Feature that makes it neccessary to add the lib)

Currently in gradle build files (ie build.gradle) it is not common practise to add document context infos about a dependency(why/when).
As far as i know there is currently no standard to do this.

The grade plugin org.cyclonedx.bom could become a tool to harvest these additional infos.
The generated xml/json data file could then be processed to analyse risks/costs/benefits

Example build.gradle

dependencies {
	...
	/** Barcode Scanner that allows to scan the member card.
	  * @see Jiira ticket MyProject-123
	  * @since [3.1] [2024/08] */
	implementation 'com.budiyev.android:code-scanner:2.1.0'
}

My example uses a Javadoc notation to add the context infos (Feature that requires the dependency, when it was added and where i can find more info)

Is there any other grade-ddl element that can be used to host the context info?

What are your thoughts ?

See also

• Add support for properties Add support for properties #706
• Introduce a way to provide project description Introduce a way to provide project description #472

Describe alternatives you've considered

No response

Additional context

No response

Contribution

• I am willing to provide an implementation
• I will wait until somebody else implements it

[ThomGeG]

I've had to do a similar thing to audit the dependencies of my projects in the past. What I had done was written a custom Groovy script (can't share sorry) that augmented the SBOMs will all kinds of additional meta-data that I wanted/needed. Said meta-data was a mix of stuff I dynamically pulled from Maven Central (like what the latest release version of that dependency is) and some static stuff coming from some JSON kept elsewhere.

You could take a similar approach - expect developers to maintain some kind of JSON file somewhere then write a Gradle task that uses it to augment the SBOMs that have just come out of the cyclonedxBom task. You should also presumably be able to write the task so that it'll fail if anybody has neglected to add an entry for a certain direct dependency.

[GG-25]

I’ve faced similar challenges when auditing dependencies, though more from a planning and risk perspective than coding. In supply chains, we usually add metadata like criticality or purpose to BOMs to make decisions actionable. Something similar in SBOMs—optional fields showing why a dependency exists or what it supports—could help teams prioritise remediation and assess risk.