GHSA-mjmj-j48q-9wg2 is triggering for snakeyaml-engine but CVE is for just "snakeyaml"

[mr-c]

For some reason the package specification org.yaml:snakeyaml is matching org.snakeyaml:snakeyaml-engine which is a completely different codebase.

advisory-database/advisories/github-reviewed/2022/12/GHSA-mjmj-j48q-9wg2/GHSA-mjmj-j48q-9wg2.json

Line 21 in 6e5f741

"name": "org.yaml:snakeyaml"

https://github.com/common-workflow-language/cwljava/blob/63e794f42ed28a03a9bb5429b8e503edb320138c/pom.xml#L99

[mr-c]

[laserlemon]

I believe this repository uses Dependency Graph's submissions API. After their CI runs on actions, it appears they are submitting the full dependency tree to Dependency Graph. The behavior we're seeing is consistent with that submission including a vulnerable version of org.yaml:snakeyaml.

Looking a little deeper, their dependency insights page does indeed show a dependency on org.yaml:snakeyaml = 1.33 (as of this writing).

[elireisman]

This looks like a problem with the snapshot detector in use - there are a couple other similar tickets in play. Snapshot submissions are assumed resolved by the submitter, we don't normally validate against the same package mappings and metadata we do for manifest based deps.

Last time this came up, I validated the snapshot submission was picking up the wrong mapping here, but as you can see in the manifest, the right artifactId appears there, and that is what the DG-API manfiest-level data records.

There's been some recent work to integrate snapshot and static-manifest data in repo insights that may be in play here? cc @juxtin

[cnagadya]

snakeyaml is a dependency of the above repo albeit an indirect one pulled in by jackson-dataformat-yaml. Work is still in progress to refresh this page and we intend to show the relationship of the different dependencies in future
Here is the snapshot generated by the Maven Dependency Tree Dependency Submission action installed on the repo. I've however extracted some bits I've deemed relevant below

{
  ...
  "pkg:maven/com.fasterxml.jackson.dataformat/jackson-dataformat-yaml@2.14.2?type=jar":{
                 "package_url":"pkg:maven/com.fasterxml.jackson.dataformat/jackson-dataformat-yaml@2.14.2?type=jar",
                 "relationship":"direct",
                 "scope":"runtime",
                 "dependencies":[
                    "pkg:maven/org.yaml/snakeyaml@1.33?type=jar"
                 ]
              },
   ...,
    "pkg:maven/org.yaml/snakeyaml@1.33?type=jar":{
       "package_url":"pkg:maven/org.yaml/snakeyaml@1.33?type=jar",
       "relationship":"indirect",
       "scope":"runtime"
    }
   ...
   "scanned":"2023-03-25T09:31:05.323Z"
   }

[lseppala]

Thanks for the thorough explanation, @cnagadya!

To confirm, the issue was that snakeyaml was a transitive dependency of jackson-dataformat-yaml. However, we do not make it clear in the Dependency Graph or Dependabot Alert UIs from where a transitive dependency is coming from. Making this relationship more obvious is planned as future work for the Dependabot and Dependency Graph team.