Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add external references support #7
This is an enhancement proposal to the CycloneDX specification to support external references.
<?xml version="1.0" encoding="UTF-8"?> <bom xmlns="http://cyclonedx.org/schema/bom/1.1" version="1"> <components> <component type="application"> <group>org.apache.tomcat</group> <name>tomcat-catalina</name> <version>9.0.14</version> <licenses> <license> <id>Apache-2.0</id> </license> </licenses> <purl>pkg:email@example.com?packaging=jar</purl> <modified>false</modified> <externalReferences> <reference type="vcs"> <url>https://github.com/apache/tomcat.git</url> <comment>Repo containing all Tomcat components</comment> </reference> <reference type="issue-tracker"> <url>https://bz.apache.org/bugzilla/</url> </reference> <reference type="website"> <url>http://tomcat.apache.org/</url> </reference> <reference type="spdx"> <url>http://location/to/spdx.rdf</url> </reference> </externalReferences> </component> </components> </bom>
I envision several built-in types including:
Some of these can be automatically obtained from a combonents NuGet or pom.xml for example and can aid in various types of manual assessment as well as future automated assessment. Future types can possibly include:
As it stands, the RFC defines external references for components. Would it be possible to also have references for the BOM as a whole?
Thus, issue-tracker would reference the project issue tracker URL. This gives the potential for automatically generating issues based on BOM analysis.
If the above makes sense, I suggest that "build-system" (ciManagement) should also be included. This will allow automatic linking back to the where the BOM was generated (eg, Jenkins), One use case: investigate why a BOM has not been updated for a week.
Glad you like it!
I know that the CycloneDX specification is supposed to be lightweight... but another useful component reference (although I can only really speak from the perspective of Maven) would be "scope". ie, test, compile, etc,
Currently, default behaviour in BOM generation is to exclude test scope. This gives the benefit that downstream analysis is not "polluted" by components that are not part of deliverables... but the disadvatgae that one is not keeping track of use of an 8 year old version of seleniumHQ (or whatever).
The exact same challenge also affects commercial tools, many of which cannot tell the difference between scopes, meaning that it is easier to just exclude them entirely (or perform a whole bunch of manual triage).
By including scope in the BOM it would then be possible for downstream tools to analysis everything in a project, and provide the opportunity to apply different policies depending on the scope. eg:
Scope is already part of the specification. Refer to https://github.com/CycloneDX/specification/blob/master/schema/bom-1.0.xsd#L46
The definition of scope currently is limited to 'required' and 'optional'. I think adding a 'test' scope would be a good addition.
I do not think any of the implementations (maven, npm, pypi, nuget) actually use it or populate it this field. This is likely an enhancement that should be made to each of the implementations.