Open brunobastosg opened 2 years ago
I think the first thing required to make this happen is to add support for external references to projects. Currently, only components and services support external references. Projects do not. External references often contain information about the build environment which could then be used to deduce other CI information.
DT supports external references at project level since 4.7 (PR #2251 and https://github.com/DependencyTrack/frontend/pull/347). It is now a matter of including the relevant information into the SBOM meta component. Such task is rather in the scope of the tool used to generate the SBOM.
Dependency-Track does indeed now support external references at project level, and very useful it is too. Accessible via "View Details" -> "External References"
For me, I see different references displayed for different DT projects, As @syalioune says, the SBOM tool is critical... but also it is important that the developers are diligent. For example, in maven it is not compulsory to include (say) issueManagement
in your POM. But if it omitted then it will not be in the SBOM and thus wont be displayed in DT as "issue tracker".
However, as great as all this is, I do not think that the above answers your question, @brunobastosg . An external reference (per CycloneDX spec) consists of two elements... type and url. Nothing about whether the CI is Jenkins or Gitlab CI or whatever. Nothing about the version of the tool. Or the plugins used. etc. etc.
This is something that will be covered by the addition of formulation support to the CycloneDX specification... hopefully in v1.5.
Once that is released then there will b a lag before support for it is added to tools (such as cyclonedx-maven-plugin
) and a lag before Dependency-Track can make use of formulation info in SBOMs.
At the very least, an external reference of type build-system with the appropriate URL can help deduce the origin of the SBOM. For example, with a tool like cyclonedx-maven-plugin
, a ciManagement
tag could be put in the pom.xml
with a dedicated profile only used by the CI. That information would make its way to the SBOM external references.
It would have been even greater if the plugin could capture the system
sub tag and put it as comment of the external reference. However only the URL is captured.
<ciManagement>
<system>github-actions</system>
<url>https://github.com/DependencyTrack/dependency-track/actions</url>
</ciManagement>
@msymons Do you have some links to share about formulation
?
Indeed... having the origin of the SBOM as a clickable link in Dependency-Track v4.7.0 is very useful. I run numerous Jenkins servers and before v4.7.0 it could be real challenge to work out why (say) a DT project had seen no BOM upload for a month. Bear in mind that devs (or a CI pipeline) might have created DT project names that do not quite match up with what you think things should be called.
Anyway, for formulation, see: https://github.com/CycloneDX/specification/issues/31
Add information about the CI tools that triggered the dependency track job.
SonarQube does this. It adds a field called "detectedCI" to the project analysis if it was triggered by CI.
Here's an excerpt from a real JSON returned by Sonar project analysis API:
Current Behavior:
CI information is not stored in project:
Proposed Behavior:
CI information is added to the project, if the dependency track job was triggered by CI: