@popey @dperry-anchore
I decided to branch this off from Upload SBOM using anchorectl for better focus.
I feel I processed all the information you provided (through thread and documentation). My current understanding is as follows:
Am I correct in assuming that by providing the -a switch with source add I can effectively eliminate the
Make note of the UUID…
piece documented at example at webinar-demo/docs/02-visibility.md at main · anchore/webinar-demo · GitHub.
My goal is to integrate Anchore into an existing GitLab release pipeline. What I have:
- Java/Maven application
- consisting of multiple components (Maven submodules) packaged as JARs, WARs or other artifacts
- each component is built in parallel
- each component has its own SBOM
With every release I need to script these tasks:
- check if the application already exists in Anchore and add it if not, I can’t do that with
anchorectl, as a script can’t process its return values? I need to call the API directly?
- check if the version already exists in Anchore and add it if not, we don’t usually release the same version twice but I’d rather be extra careful
- for every component
source add its SBOM
Did I get this right?
Yes, you can use -a or --application. I wanted to show the long way first and then the shorter way later on for version 1 of the example app.
Checkout anchorectl source add --help for more details.
This might be helpful if you haven’t seen it already - GitLab | Anchore Enterprise Product Documentation
I would be inclined to always build an SBOM. Mainly for the audit trail, as you you want to see what has changed over time or what a particular SBOM referred to. Maybe add a build/job reference in there too, so you can trace it back. Help protect against build system attacks/tampering.
Anchorectl often lets you output to json (-o json) this along with jq can help automate and not require you to craft manual api calls.
For example - anchorectl application list -o json | jq and anchorectl application version list
At initial glance, i think you should be able script with anchorectl to achieve what you are after.
Otherwise the REST API is there for you - API | Anchore Enterprise Product Documentation
For the best Java vulnerability results downstream, ensure your github feed is enabled and you also disable CPE matching for JAVA as shown here - Corrections | Anchore Enterprise Product Documentation
1 Like
Can you point me to a discussion or explanation on why this should be disabled?
Other than the doc i already shared - Corrections | Anchore Enterprise Product Documentation. There currently isn’t. I am hoping to improve this in the future.
CPE data from NVD has quite blunt matching and often generic in nature. Using Vendor specific data (eg. RHEL) or Github data for an OSS project which is more accurate will lead to better results.
