SBOM generated for JAR doesn't list dependencies

[kmontg]

What happened:

Dependencies are missing when syft is used to generate an SBOM for a JAR.

Based on this bug I thought that if the JAR contains a pom.xml file, that it will be used to detect dependencies, but that doesn't seem to be the case here.

What you expected to happen:

The dependencies are listed in the SBOM, ideally with versions.

Steps to reproduce the issue:

Building the JAR for an example application and an SBOM:

git clone https://github.com/googleapis/java-bigquery && cd java-bigquery
mvn -Dmaven.test.skip=true package
syft packages -o spdx-json ./google-cloud-bigquery/target/google-cloud-bigquery-2.31.1.jar --file /tmp/sbom.spdx.json

We don't see any of the dependencies referenced in the SBOM.

However, if we generate the SBOM from the directory containing the JARs pom.xml, we do see dependencies by cataloged (albeit missing versions):

cd google-cloud-bigquery
syft packages -o spdx-json . --file /tmp/sbom.spdx.json

Anything else we need to know?:

Environment:

• Output of syft version: 0.87.1
• OS (e.g: cat /etc/os-release or similar): debian

[wagoodman]

Syft has two modes of scanning: image scans (looking for evidence of already installed software) and directory scans (looking for declarations to install software).

Taking a look at the jar contents you'll only see class files for the google-cloud-bigquery:

google-cloud-bigquery-2.33.2.jar
├── META-INF
│   ├── INDEX.LIST
│   ├── MANIFEST.MF
│   ├── maven
│   │   └── com.google.cloud
│   │       └── google-cloud-bigquery
│   └── native-image
│       └── com.google.cloud
│           └── google-cloud-bigquery
└── com
    └── google
        └── cloud
            └── bigquery
               └── (lots of class files)

The class files found strongly correlate with only the source from the google-cloud-bigquery repo. I assume for this to function that the remaining dependencies are on CLASSPATH in the deployed destination. If that's the case, then a container containing all of those jars + this one should yield all of the dependencies.

When scanning with a directory scan, we include dependency information found within the pom.xml since this is in the context of a source repo (which is a looser set of requirements).

Given the above context about the two different scan types, does this address the problem you reported? Or are there other scan modes that you'd find more useful (say combining these two existing modes, or another approach)?

[tgerla]

We'll go ahead and close this issue but please let us know if you have any more questions! Thanks.