Package attribution

[emil-wire]

Hey guys, it's me again :)

In dependency track, how do you do package attribution? Like, how do you find out, where package A was defined specifically? Example repo structure:

service1/
-Dockerfile
-requirements.txt
service2/
-Dockerfile
-requirements.txt <- package A defined here
...

Since cdxgen dumps all packages together, how do you figure out where the dependency came from?

[heubeck]

We can't distinguish when just creating a single bom for the entire repo :(

Don't know, if that's feasible for you, we enabled to split repos in multiple boms/dtrack-projects using projects (what's a recursive structure), see here: https://github.com/MediaMarktSaturn/technolinator/blob/main/docs/Repository_Config.md.

We're using this for mono-repos.

Happy to hear your thoughts, @emil-wire

[emil-wire]

Yeah, that's what I arrived at and what I was afraid of tbh. The number of repositories we have is quite high (almost 600...) and the almost no configuration part of technolinator was very charming 🤣
Is dependency track able to outline the various ecosystems per project? Like when I have a dockerfile and requirements.txt will it be able to tell me where the vulnerable component is in when I do a per repo configuration?

[emil-wire]

Snyk has a per project view that attributes the findings to the specific source and it was awesome :)

cdxgen also does it when you specify the -t option outlining the technology to use. So for -t js it can output

{
    "group": "@istanbuljs",
    "name": "schema",
    "version": "0.1.3",
    "scope": "optional",
    "hashes": [
      {
        "alg": "SHA-512",
        "content": "5282759d961d61350f33d9118d16bcaed914ebf8061a52f4fa474b2cb08720c9c81d165e13b82f2e5a8a212cc5af482f0c6fc1ac27b9e067e5394c9a6ed186c9"
      }
    ],
    "purl": "pkg:npm/%40istanbuljs/[email protected]",
    "type": "library",
    "bom-ref": "pkg:npm/@istanbuljs/[email protected]",
    "evidence": {
      "identity": {
        "field": "purl",
        "confidence": 1,
        "methods": [
          {
            "technique": "manifest-analysis",
            "confidence": 1,
            "value": "/app/yarn.lock"
          }
        ]
      }
    },
    "properties": [
      {
        "name": "SrcFile",
        "value": "/app/yarn.lock"
      }
    ]
  },

linking the yarn.lock manifest.

So ideally, if one could identify the used ecosystems on the fly and pass them to cdxgen (if supported) and merge the various boms... but I'm not sure if that's feasible

[emil-wire]

actually, cdxgen allows to specify --evidence true and will generate the above values across the supported ecosystems (plus minus)
not sure if dependency track makes use of it though

[emil-wire]

ah, looks like someone's already working on this workflow: DependencyTrack/frontend#644
at least partially :)

[heubeck]

So ideally, if one could identify the used ecosystems on the fly and pass them to cdxgen (if supported) and merge the various boms... but I'm not sure if that's feasible

cdxgen does this automatically in recusive mode - but finally merges everything in a single bom. Maybe we could ask the incredible author of cdxgen @prabhu, whether he has a opinion about creating one bom per eco-system ;)

actually, cdxgen allows to specify --evidence true and will generate the above values across the supported ecosystems

already planning to allow that functionality from technolinator via opt-in

ah, looks like someone's already working on this workflow: DependencyTrack/frontend#644

yeah, but that's about creating a bom with evidence for dtrack itself. from the last dtrack community meeting, I remember that the team is about to adopt the cdx 1.5 features over time, so eventually we'll see this in dtrack - at some point in time.

[emil-wire]

yeah, but that's about creating a bom with evidence for dtrack itself.

Oh, you're right. Seems like I was too enthusiastic!

but finally merges everything in a single bom.

this wouldn't be a problem, as long as we could distinguish what the source is. Even if dtrack doesn't show it in the UI I'd be happy if the information were present. Pulling it out via api would already the situation.

already planning to allow that functionality from technolinator via opt-in

@heubeck would you be open to adding the the --required-only flag as well while you're at it?

[heubeck]

@emil-wire, Technolinator 1.51 supports cdxgens --required-only and --evidence.

Default setting can be set via env:
CDXGEN_REQUIRED_SCOPE_ONLY_DEFAULT (default false) and CDXGEN_EVIDENCE_DEFAULT (default false)

and be overwritten per repo:

analysis:
    # include only 'required' scoped dependencies to created BOM
    requiredScopeOnly: false
    # create sbom with evidence (slows down the process)
    evidence: false

please give it a try, indeed not sure if dtrack already does anything with evidence.