Problem integrating sbom-action with Grype

[patrickdung]

Hello, I am configuring the sbom-action with Grype.

According to the readme, supported export format is spdx, spdx-json, cyclondx and the default format is spdx-json.

format	The SBOM format to export. One of: spdx, spdx-json, cyclonedx	spdx-json

Got some problems:

1. Looks like the sbom-action uses Syft 0.26.0 instead of 0.32.0 (the latest one).
2. I am not sure which format could be read by Grype, I tried spdx-json and Grype can't read it.
   The related workflow file for this step is here
3. I end up installing the Syft 0.32 packages instead of using the GH action. Then I generate JSON format output and then it could read by Grype.
4. Finally, I also have problem uploading the artifact generated by the sbom-action GH action to the release package, the GH action is "anchore/sbom-action/publish-sbom@v0" , the artifact generated by the sbom-action is not uploaded to the release package listing.

Thanks.

[luhring]

Hi @patrickdung, great information, thank you!

1. Looks like the sbom-action uses Syft 0.26.0 instead of 0.32.0 (the latest one).

We should update sbom-action to use the latest Syft. (I don't think it makes a difference with regard to the other issues mentioned here, but we should keep the integration up-to-date nonetheless.)

2. I am not sure which format could be read by Grype, I tried spdx-json and Grype can't read it. The related workflow file for this step is here

The core team is working on expanding this functionality right now, as it turns out. Currently, Grype can ingest the Syft JSON format. But we're working on adding support for SPDX anchore/grype#395 (in progress) and CycloneDX anchore/grype#481.

3. I end up installing the Syft 0.32 packages instead of using the GH action. Then I generate JSON format output and then it could read by Grype.

Great! 🙌

4. Finally, I also have problem uploading the artifact generated by the sbom-action GH action to the release package, the GH action is "anchore/sbom-action/publish-sbom@v0" , the artifact generated by the sbom-action is not uploaded to the release package listing.

@kzantow When you get a chance, can you weigh in re: this part of the issue? What could be happening here that prevents the SBOM from being included as a release asset?

[patrickdung]

@luhring Thanks for reply.

More findings/comments:
5) I am using multi arch (x86_64 and arm64) container images. The Anchore tools seem not multi-arch aware. I am using GitHub actions 'matrix' feature and try to work around it.
I take a look on Syft GH repo, and Anchore should be using a Makefile for generating the binaries/SBOM.
What I mean is that I hope there are more automated methods or tools for supporting multi-arch.

6. I did not test in detail for this one. Looks like the SARIF from Trivy looks okay when browsed using https://microsoft.github.io/sarif-web-component/
   The SARIF report from anchore-scan action is not okay when browsed using the online viewer.

Here's the workflow/artifact for this item
https://github.com/patrickdung/MeiliSearch-crossbuild/actions/runs/1569719699#artifacts

[kzantow]

FYI, here's a PR to bump Syft -- I'm happy to merge and release when tests pass: #158

[kzantow]

Hi @patrickdung, thanks for using this action! Regarding:

4. Finally, I also have problem uploading the artifact generated by the sbom-action GH action to the release package, the GH action is "anchore/sbom-action/publish-sbom@v0" , the artifact generated by the sbom-action is not uploaded to the release package listing.

It looks like the latest release is from 27 days ago: https://github.com/patrickdung/MeiliSearch-crossbuild/releases/tag/v0.24.0 the SBOM would only be uploaded to a release generated during the workflow run (or the SBOM would quite likely be incorrect). It should even upload SBOMs as release artifacts if they are generated by a different workflow for the same branch the release is run on - for example, if you have a build that generates an SBOM when you push to main, and then you release from a different workflow using main, it should find this if the artifact match expression is set properly.

[patrickdung]

@kzantow , about the action 'anchore/sbom-action/publish-sbom'.

I see. I was testing the sbom-action with a pre-existing release.

Thanks.

[kzantow]

Hi @patrickdung! As noted: the inability for Grype to read SPDX is in progress. I had a look at your workflow file and have a few comments in regards to the sbom-action:

• Since you are using a matrix build, you should include something in the artifact-name here, e.g. container-sbom-${{matrix.arch}}.spdx.json
• Until Grype is able to read non-Grype formats, you could have this as two separate steps: 1) generate SBOM, 2) run Grype on the same input (this would be slower than necessary, but would work)
• You do not need to set ANCHORE_SBOM_ACTION_PRIOR_ARTIFACT at all, the only thing that would potentially be important is the sbom-artifact-match for the publish action, but you don't need to set that if it's the same as the main sbom-action. In fact you don't need to use the anchore/sbom-action/publish-sbom action at all unless you're publishing SBOMs outside of the sbom-action
• It looks like you're not actually running in a release context at all, so the asset upload isn't really going to work in this case, but you can use the normal upload-release-artifact action like you are in other parts of the workflow. There is an undocumented parameter: output-file where you can give a path to write the SBOM so you could do something like this:

      - uses: anchore/sbom-action@v0
        with:
          image: registry.gitlab.com/patrickdung/docker-images/meilisearch:${{ env.REMOTE_BRANCH_NAME }}-dev
          output-file: container-sbom-${{ matrix.arch }}.spdx.json
      - uses: svenstaro/upload-release-action@v2
        with:
          repo_token: ${{ secrets.PUBLISH_TOKEN }}
          file: container-sbom-${{ matrix.arch }}.spdx.json
          tag: ${{ env.REMOTE_BRANCH_NAME }}
          prerelease: true
          overwrite: true

• And finally: Rust is awesome!

[patrickdung]

@kzantow Thanks for the info.

I am already making use of the matrix.arch variables for the reports, the new workflow is updated.

ANCHORE_SBOM_ACTION_PRIOR_ARTIFACT was used because I tried the sbom-action at the beginning. The codes are already referencing it and don't want to change the codes. I need it as output variable for Syft and as input variable for cosign and Grype.

Finally, it's Meilisearch using Rust (not my project) and I want to improve the supply chain security.

[kzantow]

@patrickdung we've implemented SPDX and CycloneDX input in Grype, I'd like to understand exactly what would make this workflow work well for you! The current thinking is:

• sbom-action attaches something representative of a commit (currently a workflow artifact)
• scan-action is able to find the artifact, regardless of the format, and provide a periodic vulnerability scan

Is this more-or-less what you're looking for?

[patrickdung]

I have tested with sbom-action and (publish) just now, it should be fine for publishing the SPDX json file to the application release in GitHub.

For the second part, scan the spdx-json file with scan-action:
I have problem. Looks like scan-action is using the v0.27.3 Grype and it defaults to read 'json format (syft)' not the spdx-json format.
Ref GH action log: https://github.com/patrickdung/test-vuln/runs/5645620895?check_suite_focus=true
If I use Grype CLI version, I could manually specify the source format is spdx-json.

So my remaining question is:
How to use scan-action (grype) to scan the spdx-json from sbom-action?

Thanks.

[kzantow]

@patrickdung I'm in the process of getting the scan-action updated; I'll follow up with you when that's done :)

[patrickdung]

@kzantow, Good to hear about it.

[kzantow]

@patrickdung Just following up here: we just added sbom input into the scan-action, so there are a number of ways to integrate these two actions at present. I'll work on writing up a few examples in the documentation somewhere 👍

There's a simplistic example in the scan-action docs: https://github.com/anchore/scan-action/tree/v3.2.3#scanning-an-sbom-file

[patrickdung]

@kzantow
In the link in your last reply, it uses output-file.
I tried and got an warning in the workflow

Warning: Unexpected input(s) 'output-file', valid inputs are ['path', 'image', 'registry-username', 'registry-password', 'format', 'github-token', 'artifact-name', 'syft-version', 'dependency-snapshot']

Is it 'artifact-name'?

[kzantow]

@patrickdung no, it's output-file, I'm working on getting a PR to document/expose this parameter so the warning won't show up. Edit: this one: #239

[patrickdung]

@kzantow
I have done some testing and I think the newest GH actions should solve this issue.