This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Achieving Federal ATO

How Anchore Enterprise can help obtain an ATO

Summary

Anchore Enterprise plays a crucial part in meeting Federal Authorization to Operate (ATO) requirements and Risk Management Framework (RMF). From implementation, assessment, to monitoring, Anchore Enterprise bakes in security compliance, vulnerability & malware scanning by constantly checking registries and running images to protect and enhance security posture. As industry continues to migrate to containerization and microservices, Anchore Enterprise supports multiple regulatory requirements using software bill of materials (SBOM) and policy as code to meet the demands through automated policy enforcement and continuous monitoring. SBOMs are vital to comply with Executive Order (EO) 14028 and understanding software inventory (NIST 800-53, 800-171, 800-218, and 800-190). As software delivery changes so should the ATO process by using code to ensure secure, quality, and reproducible results. Anchore allows organizations to shift left, start secure, bake in compliance, and standardize security across the container, filesystem, virtual machine (VM) and source code landscape.

Security Controls

The security controls are described below with hyperlinks to the applicable documentation.

  • Software Bill of Materials (SBOM)
    • SBOM is essentially the ingredient list for a software product allowing the consumer to understand and manage the associated risks. Not only do our scans produces SBOMs but they can be imported as well. SBOMs are used to maintain compliance with CM-8 Information System Component Inventory.
  • Vulnerability Scanning
    • Generating a vulnerability report of both container images, virtual machine files, and source code that map to CVEs (Common Vulnerabilities & Exposures), KEV (Known Exploited Vulnerabilities) and EPSS (Exploit Prediction Scoring System) data. The reports reflect all applicable CVEs, if there are known exploits and the probability of a CVE being exploited.
  • Secure Policy Enforcement
    • Create policy (policies) of image(s) and source code to ensure that only authorized software and containers meet ATO requirements.
  • DISA STIGs
    • Use DISA STIGs for container images to establish and document configuration settings for images. Container images can be scanned against DISA STIGS in heimdall json format which can be easily converted using MITRE SAF™ into XCCDF and CKL files to import within STIG Viewer.
  • Plan of Action & Milestones (POA&M)
    • Using policies, gates, mappings and allowlists the POA&M is now enforced with dates to ensure compliance.
  • CI/CD Gate Checks
    • Use CI/CD pipelines to not only automate deployment but to ensure your security posture requirements are met each time, every time. Gates can be configured to only allow certain packages installed or be denied if there is a known exploit in a vulnerability.
  • Role Based Access Controls (RBAC)
    • Robust role based access controls using least-privilege and need-to-know.
  • Kubernetes Runtime Inventory
    • Always know what images are running in your kubernetes clusters and ensure they meet organizational requirements for vulnerability and policy compliance.
  • Kubernetes Admission Controller
    • Ensure that all container images meet policy before deployment into production.

The links below show how Anchore Enterprise helps maintain a secure posture with policy mappings to regulatory requirements.

Anchore Policy Mappings:

NIST 800-53

NIST 800-190

FedRAMP

CIS

DoD

1 - POA&M

Use Anchore Enterprise to enforce a POA&M

This guide provides examples of how to setup a policy gate to enforce development teams to comply with organizational Plan of Actions & Milestones (POA&M).

The POA&M Challenge

POA&Ms can easily become an administrative nightmare to track, maintain and update. With Anchore Enterprise, POA&Ms can now be done via code configuring CI/CD policy gates that enforce compliance.

POA&M Solution

Generate an enforceable POA&M using policy as code

The example is shown using a policy from scratch but these direction could be used to add to an existing policy.

  1. Create a new policy

    Policy

  2. Name and describe your policy, then click save

    Policy_save

  3. Now we will edit the default rule, by clicking edit:

    edit_rule

  4. From here we will configure a rule:

    rule_make

    1. Name the rule: RA-5 Vulnerability Monitoring & Scanning
    2. Gate: Vulnerabilities
    3. Trigger: Package
    4. package type: all
    5. severity comparison: >=
    6. severity: unknown
    7. fix available: true

    Scroll down to the bottom and click the action of STOP and click Save and Close.

    stop

  5. Next, we will make an Allowlists for the item we want to POA&M by editing a default Allowlist or adding a New Allowlist:

    allow_list_make

  6. Now we will edit the Allowlist:

    allowlist_poam

    1. Name the Allowlist: POA&M
    2. Gate: Vulnerabilities
    3. CVE/Vulnerability Identifier: CVE-2025-66293
    4. Package: libpng16-16t64

    Note: Another way to get the CVE and Package information is to obtain the Trigger ID on the Policy Compliance Tab which is CVE ID+package as seen in image below:

    triggerid

  7. We have a rule and an Allowlist but we want to make this a POA&M item that expires so lets make an expiration by clicking on the calendar:

    POA&M_expiration

  8. A calendar will pop-up and you can select a date or or a time frame of days, weeks or months:

    date

  9. Next we will make a mapping to limit where this specific POA&M or Allowlist is applied by clicking Mappings, Container Images and Edit:

    date

  10. Next we will associate a Registry, Repository and Tag with the POA&M Allowlist we just made.

    poam_allow_list

    1. Name the Mapping: nginx-libpng
    2. Registry: nginx-libpng
    3. Repository: nginx
    4. Tag: *

    Note: Wildcards “*” can be used for Registry, Repository, and Tag

  11. Our POA&M via an Allowlist with an expiration has been created. Let’s validate:

    validation

    1. Toggle on Go
    2. Show Allowlisted Entries
    3. The TriggerID matches what was put in the Allowlist

You have now created a POA&M enforced by code

2 - STIG

Use Anchore Enterprise to STIG a container image

This guide provides examples of how to scan a container with DISA STIGs and import the data into Heimdall for a visualization or STIGViewer to create a checklist to provide as an ATO artifact.

This guide requires the dependencies located here to be installed along with the dependency below.

SAF CLI - Install Docs

Once these dependencies are installed, the STIG profiles are written as indicated in the here link and a STIG evaluation has been completed, you are ready to begin.

We will assume that the output of the scan is located in our working directory for the examples below and the STIG --stig-output-dir was saved as results.json like the example below:

anchorectl image add registry.access.redhat.com/ubi9/ubi:latest --stig --stig-profile ./rhel9/rhel9.tar.gz --stig-output-dir results.json

Working with Heimdall

  1. The native format for STIG output in Anchore is OASIS Heimdall Data Format (OHDF) and can be easily uploaded to heimdall-lite.mitre.org

  2. From here, you can upload the results.json file and obtain charts and a map of the NIST 800-53 controls like the images below:

    Charts

    Map

  3. You can easily filter what passed, failed, not reviewed and not applicable. The data can be exported as a DISA Checklist or as XCCDF Results as indicated in the picture below:

    Save

  4. The data can be imported back into STIGViewer to audit a checklist as indicated in Step 4 under Working with STIGViewer

Working with STIGViewer

  1. With safcli installed run the following command to convert the results.json to XCCDF:
saf convert hdf2xccdf -i results.json -o xccdf-results.xml
  1. Now we want to convert the same results.json to a ckl file:
saf convert hdf2ckl -i results.json -o ubi9-check.ckl

  1. Let’s open STIGViewer and import the results-xccdf.xml file we created in step 1.

    loadfiles

  2. Now we can click the Home Icon and load our checklist:

    upload

    1. Click the hamburger menu
    2. Click Import V2 Checklist and upload ubi9-check.ckl

  3. The container STIG checklist can now be saved once the findings as either Open, Not a Finding, Not Applicable and submitted with the applicable Body of Evidence (BOE) documentation.

    final

You have now STIG’d a container image and created a checklist