In an era where a single line of compromised code can bring entire enterprise systems to their knees, software supply chain security has transformed from an afterthought to a mission-critical priority. The urgency is undeniable: while software supply chain attacks grew by a staggering 540% year-over-year from 2019 to 2022, organizations have rapidly responded.
Organizations have taken notice—the priority given to software supply chain security saw a remarkable 200% increase in 2024 alone, signaling a collective awakening to the existential threat of supply chain attacks. Cybercriminals are no longer just targeting individual applications—they're weaponizing the complex, interconnected software supply chains that power global businesses.
To combat this rising threat, organizations are deploying platforms to automate BOTH detecting vulnerabilities AND enforcing supply chain security policies. This one-two combo is reducing the risk of a breach from a 3rd-party supplier from cascading into their software environment.
Anchore Enforce, a module of Anchore Enterprise, enables organizations to automate both security and compliance policy checks throughout the development lifecycle. It allows teams to shift compliance left and easily generate reporting evidence for auditors by defining detailed security standards and internal best practices 'as-code'.
In this blog post, we'll demonstrate how to get started with using Anchore Enforce's policy engine to automate both discovering non-compliant software and preventing it from reaching production.
Learn about software supply chain security in the real-world with former Google Distinguish Engineer, Kelsey Hightower.
A Brief Primer on Policy-as-Code & Policy Packs
Policy-as-code (PaC) translates organizational policies—whether security requirements, licensing restrictions, or compliance mandates—from human-readable documentation into machine-executable code that integrates with your existing DevSecOps platform and tooling. This typically comes in the form of a policy pack.
A policy pack is a set of pre-defined security and compliance rules the policy engine executes to evaluate source code, container images or binaries.
To make policy integration as easy as possible, Anchore Enforce comes with out-of-the-box policy packs for a number of popular compliance frameworks (e.g., FedRAMP or STIG compliance).
A policy consists of three key components:
- Triggers: The code that checks whether a specific compliance control is present and configured correctly
- Gates: A group of triggers that act as a checklist of security controls to check for
- Actions: A
stop,warnorgodirective explaining the policy-compliant action to take
To better understand PaC and policy packs, we use airport security as an analogy.
When you travel, you pass through multiple checkpoints, each designed to identify and catch different risks. At security screening, officers check for weapons, liquids, and explosives. At immigration control, officials verify visas and passports. If something is wrong, like an expired visa or a prohibited item, you might be stopped, warned, or denied entry.
Anchore Enforce works in a similar way for container security. Policy gates act as checkpoints, ensuring only safe and compliant images are deployed. One aspect of a policy might check for vulnerabilities (like a security screening for dangerous items), while another ensures software licenses are valid (like immigration checking travel documents). If a container has a critical flaw such as a vulnerable version of Log4j it gets blocked, just like a flagged passenger would be stopped from boarding a flight.
By enforcing these policies, Anchore Enforce helps secure an organization's software supply chain; just as airport security ensures dangerous passengers/items from making it through.
If you're looking for a deeper dive on PaC, read Anchore's Developer's Guide to SBOMs & Policy-as-Code.
Getting Started: the Developer Perspective
Getting started with Anchore Enforce is easy but determining where to insert it into your workflow is critical. A perfect home for Anchore Enforce is distributed within the CI/CD process, specifically during the localised build process.
This approach enables rapid feedback for developers, providing a gate which can determine whether a build should progress or halt depending on your policies.
Container images are great for software developers—they encapsulate an application and all of its dependencies into a portable package, providing consistency and simplified management. As a developer, you might be building a container image on a local machine or in a pipeline, using Docker and a dockerfile.
For this example, we’ll assume you are using a GitLab Runner to run a job which builds an image for your application. We'll also be using AnchoreCTL, Anchore Enterprise's CLI tool to automate calling Anchore Enforce's policy engine to evaluate your container against the CIS security standard—a set of industry standard container security best practices.
First, you’ll want to set a number of environment variables in your GitLab repository:
ANCHORECTL_USERNAME (protected)
ANCHORECTL_PASSWORD (protected and masked)
ANCHORECTL_URL (protected)
ANCHORECTL_ACCOUNTThese variables will be used to authenticate against your Anchore Enterprise deployment. Anchore Enterprise also supports API keys.
Next, you’ll want to set up your GitLab Runner job definition whereby AnchoreCTL is run after you’ve built a container image. The job definition below shows how you might build an image, then run AnchoreCTL to perform a policy evaluation:
### Anchore Distributed Scan
# You will need three variables defined:
# ANCHORECTL_USERNAME
# ANCHORECTL_PASSWORD
# ANCHORECTL_URL
# ANCHORECTL_ACCOUNT
.login_gitlab_registry:
- echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
.install_anchorectl_alpine:
- apk update && apk add curl
- 'echo "Downloading anchorectl from: ${ANCHORECTL_URL}"'
- 'curl $ANCHORECTL_URL/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl && mv -v anchorectl /usr/bin && chmod +x /usr/bin/anchorectl && /usr/bin/anchorectl version'
image: docker:latest
services:
- docker:dind
stages:
- build
- anchore
variables:
ANCHORECTL_FAIL_BASED_ON_RESULTS: "true"
ANCHORE_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}
Build:
stage: build
before_script:
- !reference [.login_gitlab_registry]
script:
- docker build -t ${ANCHORE_IMAGE} .
- docker push ${ANCHORE_IMAGE}
Anchore:
stage: anchore
before_script:
- !reference [.install_anchorectl_alpine]
- !reference [.login_gitlab_registry]
script:
- 'export PATH="${HOME}/.local/bin/:${PATH}"'
### scan image and push to anchore enterprise
- anchorectl image add --no-auto-subscribe --wait --dockerfile ./Dockerfile --from registry ${ANCHORE_IMAGE}
### then get the results:
- anchorectl image check --detail ${ANCHORE_IMAGE} The following environment variable (which can also be passed as the -f flag to AnchoreCTL) ensures that the return code is set to 1 if the policy evaluation result shows as 'fail'. You can use this to break your build:
ANCHORECTL_FAIL_BASED_ON_RESULTS: "true"Then the AnchoreCTL image check command can be used to either validate against the default policy or specifically against a given policy (using the -p flag). This could be useful since your account in Anchore Enterprise can only have one default policy permanently active:
anchorectl image check --detail ${ANCHORE_IMAGE} -p <DESIRED_POLICY_ID>When executed, this pipeline will scan your container image against your selected policy requirements and immediately provide feedback. Developers see exactly which policy gates failed and receive specific remediation steps, often as simple as updating a package or adjusting a configuration parameter.
And that’s it! With a few extra lines in your job definition, you’re now validating your newly built image against Anchore Enterprise for policy violations.
On failure, the job will stop and if the build fails in this manner, the --detail option will give you an explanation of failures with remediation recommendations! This is a great way to get fast feedback and stop/warn/go directives directly within the development flow.
Operationalizing Compliance Checks: the Security Engineer Perspective
While developers benefit from shift-left security checks during builds, security teams need a broader view across the entire container landscape. They’ll likely be working to scan containers after they are built by the development teams, having already been pushed or staged testing or even deployed and already running. The critical requirement for the security team is the need to evaluate a large number of images regularly for the latest critical vulnerabilities. This can also be done with policy evaluation; feeding everything in the registry through policy gates.
Below you can see how the team might manage this via the Anchore Enforce user interface (UI). The security team has access to a range of policies, including:
- CIS (included by default in all Anchore Enterprise deployments)
- NIST 800-53
- NIST 800-190
- US DoD (Iron Bank)
- DISA
- FedRAMP
For this UI walkthrough, we will demonstrate the use-case using the CIS policy pack. Navigate to the policy section in your Anchore UI and activate your desired policy.
If you are an Anchore customer and do not have a desired policy pack, contact our Customer Success team for further information on entitlements.
Once this is activated, we will see how this is set in action by scanning an image.
Navigate to Images, and select the image you want to check for compliance by clicking on the image digest.
Once the policy check is complete, you will see a screen containing the results of the policy check.
This screen displays the actions applied to various artifacts based on Anchore Enforce's policy engine findings, aligned with the rules defined in the policy packs. It also highlights the specific rule an artifact is failing. Based on these results, you can determine the appropriate remediation approach.
The security team can generate reports in JSON or CSV format, simplifying the sharing of compliance check results.
Wrap-Up
As software supply chain attacks continue to evolve and grow in sophistication, organizations need robust, automated solutions to protect their environments. Anchore Enforce delivers exactly that by providing:
- Automated compliance enforcement that catches issues early in the development process, when they're easiest and least expensive to fix
- Comprehensive policy coverage with pre-built packs for major standards like CIS, NIST, and FedRAMP that eliminate the need to translate complex requirements into executable controls
- Flexible implementation options for both developers seeking immediate feedback and security teams managing enterprise-wide compliance
- Actionable remediation guidance that helps teams quickly address policy violations without extensive research or security expertise
By integrating Anchore Enforce into your DevSecOps workflow, you're not just checking a compliance box—you're establishing a powerful defense against the rising tide of supply chain attacks. You're also saving developer time, reducing friction between security and development teams, and building confidence with customers and regulators who demand proof of your security posture.
The software supply chain security challenge isn't going away. With Anchore Enforce, you can meet it head-on with automation that scales with your organization. Reach out to our team to learn more or start a free trial to kick the tires yourself.
