Add the option to use anchore/syft image for SBOM scanning

[tobybellwood]

Syft has additional functionality that allows us to better detect a range of packages (eg php). There may be an advantage to using it for SBOM scanning. Note that syft doesn't do vulnerability scanning itself - you'd have to use an additional tool (eg Grype)

[seanhamlin]

Using syft seemed to yield a far larger SBOM compared to Trivy.

Example syft command

syft uselagoon/php-8.4-cli-drupal:latest -o cyclonedx-json  | jq > lagoon-drupal-cli-syft.json

and buried in that SBOM is this, the version of PHP compiled in the upstream image php:8.4.11-fpm-alpine3.22 from source:

    {
      "bom-ref": "pkg:generic/php-cli@8.4.11?package-id=d2c357597948b298",
      "type": "application",
      "name": "php-cli",
      "version": "8.4.11",
      "cpe": "cpe:2.3:a:php:php:8.4.11:*:*:*:*:*:*:*",
      "purl": "pkg:generic/php-cli@8.4.11",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "php-interpreter-cataloger"
        },
        {
          "name": "syft:package:type",
          "value": "binary"
        },
        {
          "name": "syft:package:metadataType",
          "value": "binary-signature"
        },
        {
          "name": "syft:location:0:layerID",
          "value": "sha256:fe7e0a903dc4bd068021c326367c4590f30406be208f9fdf3a0238a1699a4ef1"
        },
        {
          "name": "syft:location:0:path",
          "value": "/usr/local/bin/php"
        }
      ]
    },

This came about due to PHP specific word in anchore/syft#2585

So this definitely seemed to be more useful compared to Trivy.

[seanhamlin]

Found another reason to move to syft, the resulting SBOM contains both a cpe and purl, e.g. this example component libexpat from the above mentioned uselagoon/php-8.4-cli-drupal:latest:

    {
      "bom-ref": "pkg:apk/alpine/libexpat@2.7.3-r0?arch=aarch64&distro=alpine-3.23.2&package-id=5901e944e77579e8&upstream=expat",
      "type": "library",
      "publisher": "Carlo Landmeter <clandmeter@alpinelinux.org>",
      "name": "libexpat",
      "version": "2.7.3-r0",
      "description": "XML Parser library written in C (libraries)",
      "licenses": [...],
      "cpe": "cpe:2.3:a:libexpat:libexpat:2.7.3-r0:*:*:*:*:*:*:*",
      "purl": "pkg:apk/alpine/libexpat@2.7.3-r0?arch=aarch64&distro=alpine-3.23.2&upstream=expat",
      "externalReferences": [...],
      "properties": [...]
    },

Critically, the same component when analysed by trivy contains:

{
"bom-ref": "pkg:apk/alpine/libexpat@2.7.3-r0?arch=x86_64&distro=3.23.2",
"hashes": [...],
"licenses": [...],
"name": "libexpat",
"properties": [...],
"purl": "pkg:apk/alpine/libexpat@2.7.3-r0?arch=x86_64&distro=3.23.2",
"supplier": {
  "name": "Carlo Landmeter <clandmeter@alpinelinux.org>"
},
"type": "library",
"version": "2.7.3-r0"
},

Note, it is missing cpe.

Why CPE matters

A lot of the feeds that Dependency Track uses, use CPE to denote package matching. e.g. https://nvd.nist.gov/vuln/detail/CVE-2025-59375 which only has a CPE match.