For container-focused users, one of the highly popular use-cases for Anchore Enterprise is to provide fast shift-left feedback to developers who are building and packaging their software components into portable container images. Our most advanced users are generating 100,000s of SBOMs per month from their container images, very often in Continuous Integration (CI) pipeline jobs. This short blog post gives some tips for DevSecOps and Developer teams on how to tune your usage of Anchore Enterprise in CI for fast feedback and speeeeeed! 

This blog makes the assumption that you have a container-focused use-case and already use Anchore Enterprise and its SBOM generation capabilities in the developer pipeline.  

Grab Tooling from the Deployment

Using AnchoreCTL, you can manage and interact with your Anchore Enterprise installation via its rich API. It is designed as a CLI tool to be used in scripted environments such as CI. AnchoreCTL uses the popular open source tool Syft under the hood to generate SBOMs. AnchoreCTL should always be version aligned with the Anchore Enterprise deployment. But did you know that Anchore Enterprise ships with its respective version? This means you can just fetch the right version directly from inside your CI job! For example:

Distribute Your Analysis 

SBOM generation and subsequent inspection can be conducted in two different modes of operation when used in CI. 

The first is distributed analysis, where the SBOM generation happens locally in the pipeline on the agent or runner and is then sent to the Anchore Enterprise deployment for evaluation, and centralized analysis, where SBOM generation is conducted directly in the Anchore Enterprise deployment itself. 

These two modes of operation may have different performance profiles. Distributed analysis is the recommended approach for CI. This is because you are likely to have more flexibility in how you configure and resource your runners: throw more CPU and fast I/O to get better SBOM generation performance. The only caveat is that in distributed analysis you won’t currently get malware scanning: so if you need this you will have to let the Anchore Enterprise analyzer service unpack the container image and its layers and conduct this scan. To use distributed analysis to generate the SBOM on the runner in the CI job, offloading analysis to the “edge”, have AnchoreCTL pull down the image from a staging registry or source it from the local docker environment:

anchorectl image add ghcr.io/place/thing:v0.1.0 --from [docker, registry] --wait

AnchoreCTL will generate the SBOM, cataloging your image contents and then ship this SBOM to the Anchore Enterprise deployment for storage, vulnerability analysis and policy evaluation. The –wait flag will ensure the commands wait for analysis to complete. After, you can then request information from Anchore Enterprise on contents, such as vulnerability analysis:

anchorectl image vulns ghcr.io/place/thing:v0.1.0

Parallelise The Work

AnchoreCTL 5.18 or later use versions of Syft which include a parallelism capability. This means catalogers for generating the SBOM can run in parallel rather than sequentially over an image. This can lead to significant performance improvements if your images have a lot of content (e.g. files, packages etc.) and your runners are resourced accordingly to handle the concurrent workers. You can set the ANCHORECTL_SYFT_PARALLELISM environment variable (or variable in anchorectl.yaml) to specify the number of concurrent processes. For example, to create 8 worker processes across my 8 vCPU runner:

ANCHORECTL_SYFT_PARALLELISM=8 

Use Policy

Whilst some users may wish to just return a list of enumerated vulnerabilities against an image, we’d highly recommend using the policy engine (Anchore Enforce) to conduct policy checks. You can read more about our policy engine here. 

Being able to deliver compliance feedback directly to the developer in their build pipelines has the advantage of “cutting out the middleman” and streamlining actionable feedback. Delivering a list of vulnerabilities is one thing (and often daunting; where do I start?!) but starting with a compliance posture, either according to industry standards such as NIST 800-53, CIS or according to your own organisational standards, is more streamlined. Your workflow can then deliver precise feedback based on risk profiling and can be returned with clear and actionable steps for improvement and resolution. 

Thus, in CI using AnchoreCTL, users can start to evaluate against the default policy for their account with the following command:

anchorectl image check <MY_IMAGE> --fail-on-policy-error --detail

The –detail flag will ensure that the policy gate, trigger, action, description and remediation recommendation is delivered in return to the command. This will give the users the feedback required to resolve the issues triggering a FAIL action and review those triggering the WARN action. 

One Time It 

With recent versions of Anchore Enterprise and their respective versions of AnchoreCTL (starting in v5.19), we introduced a “one time scan” feature. In some cases, teams don’t care about Anchore Enterprise retaining and monitoring the SBOM for a particular category of container images. This was designed for users who want a vulnerability and policy scan of a container SBOM but without persisting the data in Anchore Enterprise. For example, scratch builds early in the development cycle. This capability can be used by using the respective AnchoreCTL command in your CI job:

anchorectl image one-time-scan ghcr.io/place/thing:v0.1.0 --from [docker, registry] --fail-on-policy-error

Like in a normal distributed workflow, AnchoreCTL will fetch the container image, generate an SBOM from it and then submit to Anchore Enterprise for a stateless evaluation, delivering the results straight back to the client. But this time, no data in your Anchore Enterprise deployment to think about archiving or deleting later! 

Wrap-up

The above give some extra examples of the tuning you can do inside your CI pipelines to get SBOM generation absolutely humming! 
Of course, if you want to learn more you can leverage our documentation at docs.anchore.com or reach out to the Anchore Customer Success team for help via support.anchore.com.