Relationships / Dependencies are present in Syft json and SPDX json files but sometimes not in Cyclonedx json file format

[haiazuki]

What happened:
I am not seeing dependencies information on CycloneDX format json files even though they are present in other formats:

SPDX file snippet:

   "relationships": [
        {
            "comment": "evident-by: indicates the package's existence is evident by the given file",
            "relatedSpdxElement": "SPDXRef-File--Install-LMFIN-10010154-001574.jar-39b2fbb066459eaa",
            "relationshipType": "OTHER",
            "spdxElementId": "SPDXRef-Package-java-archive-org.eclipse.osgi-0988631922bb71dc"
        },
        {
            "comment": "evident-by: indicates the package's existence is evident by the given file",
            "relatedSpdxElement": "SPDXRef-File--Install-LMFIN-10010154-001574.jar-39b2fbb066459eaa",
            "relationshipType": "OTHER",
            "spdxElementId": "SPDXRef-Package-java-archive-org.eclipse.equinox.http.servletbridge-1.0.100.v20090520-0fa41529ebc92c19"
        },
        {
            "relatedSpdxElement": "SPDXRef-Package-java-archive-defaultHelp-25eed61145441535",
            "relationshipType": "CONTAINS",
            "spdxElementId": "SPDXRef-DocumentRoot-File-Install-LMFIN-10010154-001574.jar"
        },
        {
            "relatedSpdxElement": "SPDXRef-Package-java-archive-el-4ab927d37eec02be",
            "relationshipType": "CONTAINS",
            "spdxElementId": "SPDXRef-DocumentRoot-File-Install-LMFIN-10010154-001574.jar"
        },

What you expected to happen:
Dependencies should appear in the Cyclonedx format json file similar to SPDX and Syft json files.

Steps to reproduce the issue:
I tried generating SBOM file in CycloneDX format and noticed that no dependencies are included in the sbom file. But then I tried generating an SBOM in Syft json and SPDX json formats and see that relationships / dependencies information are present. I tried converting the SBOM to CycloneDX format and no dependencies information are included in the output.

Anything else we need to know?:
N/A

Environment:

• Output of syft version:
  Application: syft
  Version: 1.2.0
  BuildDate: 2024-04-12T18:31:58Z
  GitCommit: dde5d34
  GitDescription: v1.2.0
  Platform: windows/amd64
  GoVersion: go1.21.9
  Compiler: gc

• OS (e.g: cat /etc/os-release or similar):
  Windows 11 Enterprise

[tgerla]

Thanks @haiazuki for the report! We will take a look. This issue is possibly related to: #2353 and #2305

[tgerla]

Dev notes: there are some format limitations in CycloneDX that prevent us from representing every relationship that we handle in other formats like SPDX, so there will always be some functionality differences between the various formats. We could probably encode CONTAINS and DEPENDS-ON relationships in CycloneDX, though. The challenge encoding the CONTAINS relationship is that it requires nesting components in CycloneDX which we aren't currently doing--it wouldn't be expressible in the dependency relationships.

@haiazuki, if you are able, can you share a bit more about your use case and needs here? Are you looking for a source code dependency tree or something similar? More details might be helpful for us to look into this. Thanks!

[haiazuki]

Hi @tgerla ,
I checked the specifications of SPDX compare with CycloneDX so I understand what you are saying. From a CycloneDX perspective, it tracks dependency relationships so DEPENDS-ON seem to be the priority.
In the product I am testing with, I have an installer in a jar package that I used as the target source to generate the sbom. This contains other jar files and also a war file that contains other jar file packages. So I was looking for entries that reflect the relationship of these packages similar to what is in default json and spdx json.

Thank you!

[flemminglau]

I see syft producing usable Cyclonedx dependency information for image scans except from the tiny detail described here: DependencyTrack/dependency-track#3314

I have tried manually adding the missing dependency between the root object and some random set of modules and then DT can show a dependency tree for that part. It seems DT doesn't even try to build a dependency tree when the root dependency is missing. Probably because it doesn't know where to start.

Is there a good reason this has not been fixed already (or why the issue has ever arisen)?

[haiazuki]

Shouldn't this need to be included in milestone "Meet NTIA Minimum SBOM Requirements" as relationships are part of the minimum elements in NTIA?

[spiffcs]

👋 I think it would be useful for this issue if we could post specific examples of where dependencies should exist in cyclone-dx and they are not showing up. Syft currently uses the dependencies field of cyclone dx to represent depends-on as found by spdx.

Are there other sections we should be putting non dependency relationship information?
In the SBOM you are generating what data is not showing up in the cyclonedx dependencies section that you expect to show up?

A good example of the format I'm looking for to help the discussion is something like this:

I am using syft v1.6.0 to scan `alpine:latest`

Here are the commands I'm running:

 syft -o spdx-json alpine:latest | jq . > spdx.json
 syft -o cyclonedx-json alpine:latest | jq . > cdx.json

In spdx.json I see:

    {
      "spdxElementId": "SPDXRef-Package-apk-musl-03e521237cbed45a",
      "relatedSpdxElement": "SPDXRef-File-lib-ld-musl-aarch64.so.1-15ac5a87021c605c",
      "relationshipType": "CONTAINS"
    },

These contains relationships are not shown in cyclone-dx.

All I see in cyclone-dx are the depends on relationships - here is an example:

    {
      "ref": "pkg:apk/alpine/[email protected]?arch=aarch64&upstream=openssl&distro=alpine-3.20.0&package-id=0cfcda1a242dfd13",
      "dependsOn": [
        "pkg:apk/alpine/[email protected]?arch=aarch64&distro=alpine-3.20.0&package-id=03e521237cbed45a"
      ]
    },

[haiazuki]

Hi @spiffcs,
So, to confirm, you are saying if there are depends on relationships found in SPDX format, those should be found in CycloneDX dependencies as well?
Looking at the sboms I generated for our products, I can only see CONTAINS and OTHERS type of relations on SPDX and looking at CycloneDX format, I can only see Depends on type of relationship.

[spiffcs]

SPDX

Here is the code that transforms the syft document model relationships into spdx:

syft/syft/format/common/spdxhelpers/to_format_model.go

Lines 546 to 587 in c816039

	func toRelationships(relationships []artifact.Relationship) (result []*spdx.Relationship) {
	for _, r := range relationships {
	exists, relationshipType, comment := lookupRelationship(r.Type)
	if !exists {
	log.Debugf("unable to convert relationship to SPDX, dropping: %+v", r)
	continue
	}
	// FIXME: we are only currently including Package -> * relationships
	if _, ok := r.From.(pkg.Package); !ok {
	log.Debugf("skipping non-package relationship: %+v", r)
	continue
	}
	result = append(result, &spdx.Relationship{
	RefA: spdx.DocElementID{
	ElementRefID: toSPDXID(r.From),
	},
	Relationship: string(relationshipType),
	RefB: spdx.DocElementID{
	ElementRefID: toSPDXID(r.To),
	},
	RelationshipComment: comment,
	})
	}
	return result
	}
	func lookupRelationship(ty artifact.RelationshipType) (bool, helpers.RelationshipType, string) {
	switch ty {
	case artifact.ContainsRelationship:
	return true, helpers.ContainsRelationship, ""
	case artifact.DependencyOfRelationship:
	return true, helpers.DependencyOfRelationship, ""
	case artifact.OwnershipByFileOverlapRelationship:
	return true, helpers.OtherRelationship, fmt.Sprintf("%s: indicates that the parent package claims ownership of a child package since the parent metadata indicates overlap with a location that a cataloger found the child package by", ty)
	case artifact.EvidentByRelationship:
	return true, helpers.OtherRelationship, fmt.Sprintf("%s: indicates the package's existence is evident by the given file", ty)
	}
	return false, "", ""
	}

Here we can see that for spdx we should be including the following types for package relationships

Contains
DependencyOf
OwnershipByFileOverlap
EvidentBy

Without having access to the source or a sample image to investigate I can't say why some, none, or all of those are included for an individual SPDX sbom generated by syft.

CycloneDX

Here is the code that converts syft relationships to cyclonedx dependencies:

syft/syft/format/common/cyclonedxhelpers/to_format_model.go

Lines 159 to 208 in c816039

	func toDependencies(relationships []artifact.Relationship) []cyclonedx.Dependency {
	dependencies := map[string]*cyclonedx.Dependency{}
	for _, r := range relationships {
	exists := isExpressiblePackageRelationship(r.Type)
	if !exists {
	log.Debugf("unable to convert relationship type to CycloneDX JSON, dropping: %#v", r)
	continue
	}
	// we only capture package-to-package relationships for now
	fromPkg, ok := r.From.(pkg.Package)
	if !ok {
	log.Tracef("unable to convert relationship fromPkg to CycloneDX JSON, dropping: %#v", r)
	continue
	}
	toPkg, ok := r.To.(pkg.Package)
	if !ok {
	log.Tracef("unable to convert relationship toPkg to CycloneDX JSON, dropping: %#v", r)
	continue
	}
	toRef := helpers.DeriveBomRef(toPkg)
	dep := dependencies[toRef]
	if dep == nil {
	dep = &cyclonedx.Dependency{
	Ref: toRef,
	Dependencies: &[]string{},
	}
	dependencies[toRef] = dep
	}
	fromRef := helpers.DeriveBomRef(fromPkg)
	if !slices.Contains(*dep.Dependencies, fromRef) {
	*dep.Dependencies = append(*dep.Dependencies, fromRef)
	}
	}
	result := make([]cyclonedx.Dependency, 0, len(dependencies))
	for _, dep := range dependencies {
	slices.Sort(*dep.Dependencies)
	result = append(result, *dep)
	}
	slices.SortFunc(result, func(a, b cyclonedx.Dependency) int {
	return strings.Compare(a.Ref, b.Ref)
	})
	return result
	}

This one is a little more complex in how we eventually settle on a package -> package dependency being included, but one of the cores of it can be found at isExpressiblePackageRelationship

syft/syft/format/common/cyclonedxhelpers/to_format_model.go

Lines 145 to 157 in c816039

	// used to indicate that a relationship listed under the syft artifact package can be represented as a cyclonedx dependency.
	// NOTE: CycloneDX provides the ability to describe components and their dependency on other components.
	// The dependency graph is capable of representing both direct and transitive relationships.
	// If a relationship is either direct or transitive it can be included in this function.
	// An example of a relationship to not include would be: OwnershipByFileOverlapRelationship.
	func isExpressiblePackageRelationship(ty artifact.RelationshipType) bool {
	switch ty {
	case artifact.DependencyOfRelationship:
	return true
	default:
	return false
	}
	}

If we find that the relationship type is DependencyOfRelationship then we will try to proceed to create the Depends on type you see in CycloneDX.

Summary

The relationships that the two formats have in common currently in the syft mental model is the DependencyOfRelationship - Both will show up in the different formats; SPDX as DEPENDENCY_OF and CYCLONE_DX as an entry in the cyclonedx.Dependency list

[kzantow]

Hi, the next Syft release will include dependency information for certain Java artifacts and maven projects. I didn't see specific steps to reproduce the original problem -- is this issue specific to Java and should it be considered completed?