Frequently Asked Questions
Welcome to Iron Bank, we are glad you're here! For commonly asked questions and answers, please see the document below. If you have any further questions not covered below, please contact the Iron Bank team directly.
1.0 General
1.1 What is Iron Bank?
Iron Bank is a secure container image repository within Platform One (P1), providing hardened software containers for the Department of War (DoW). It helps secure the software supply chain by offering over 1,000 hardened vendor and open-source containers, along with compliance and vulnerability assessments to support your Authority to Operate (ATO).
1.2 What is the cost model for Iron Bank?
There is currently no cost to contributors or users of Iron Bank; it is funded by the DoW.
1.3 What ILs and countries does Iron Bank support?
Iron Bank is available at all Information Levels (ILs). Non-US organization access is assessed case by case, and your country may already be approved. Contact us in our Iron Bank Value Stream channel for help with either.
2.0 Accessing Resources
2.1 How do I register for a Repo1 account and log in to Registry1?
Visit the P1 Account Creation Page to register for an account. New to Iron Bank? See our Consumer Onboarding Guide for a full walkthrough. Registry1 does not allow anonymous image pulls, so you'll need this same Repo1/Registry1 account to log in with Docker — see Pulling an Image for details.
2.2 How can I see a list of applications hosted in Iron Bank?
Visit the Iron Bank Catalog to see all available containers, along with their corresponding documentation. Iron Bank does not "run" containers for users — we publish them and make them available for you to deploy in your own environment. This requires a Repo1 account to access.
2.3 How do I get a robot account to automate image pulls from Registry1?
Submit a request through the Iron Bank Bot Portal — this portal covers new account setup, changes, and password resets.
2.4 Who is allowed to contribute to Iron Bank?
Anyone can contribute, not just DoW organizations and vendors — Iron Bank is for everyone to consume from or contribute to. Two exceptions: GOTS projects are not allowed, and ITAR-controlled information cannot be uploaded. See our Contributor Onboarding Guide to get started.
2.5 What are the requirements for a container to be onboarded?
Containers must be fully functional; Iron Bank does not harden containers used only to package or transfer binaries between environments. Commercial products may only be contributed by the company that owns them or an authorized representative, and if a commercial product is added, its open-source version — if one exists — must also be hardened in Iron Bank.
2.6 How do I bring my containers to Iron Bank?
Vendors and contributors can onboard by filling out our Getting Started Form. The Iron Bank Onboarding team will reach out to your point of contact with next steps — see Onboarding Services for more detail.
There is no fixed onboarding timeline. After your form is submitted, the team assigns a priority level and creates your repository; you then build your Dockerfile and hardening_manifest.yaml, validate the pipeline, and justify findings in VAT. The container goes through pre-verification and peer review from the Container Hardening Team before merging to master. Turnaround depends on your priority level and how quickly your submission meets requirements.
2.7 How do I add developers from my organization to my repository?
- Open a new issue in your repository.
- In the Description field, select the Access Request template.
- Specify the username and level of access for each developer.
- Apply the label CSO::To Do.
3.0 Compliance, Scanning, and VAT
3.1 What artifacts does Iron Bank provide, and how often are they refreshed?
All automated artifacts are available for all Iron Bank containers, including Verified and Unverified:
- Scan results from Anchore, Twistlock, and OpenSCAP, including CVEs and OS STIG policy checks
- ClamAV virus scan
- TruffleHog secrets scan
- SBOMs generated with Syft
- Cosign signature
- Vendor justifications for findings in VAT
- Automated ABC (Compliant/Non-compliant) status and numeric ORA score
Every image is rebuilt and rescanned every 24 hours with updated OS packages, so yes, all images are scanned nightly.
3.2 Why does my image look different every day even though the tag hasn't changed?
Because images rebuild every 24 hours with updated OS packages, the underlying image digest can change behind a tag even when the tag name itself stays the same. Unless reproducible builds are explicitly configured for that image, routine patching alone is enough to produce a new digest overnight.
3.3 Why do my vulnerability scan results differ from Iron Bank's?
A few common reasons: you may be scanning an older or newer build than what's currently published, since images rebuild nightly; your scanner or vulnerability database may differ from Iron Bank's tooling; or the finding may already be justified in VAT (false positive, not vulnerable, mitigated, etc.) in a way your local scan has no visibility into.
3.4 A finding is justified, but my container is still marked non-compliant. Do I have to remediate every finding?
Each finding carries a timeline based on severity: justification, then mitigation, then remediation — see Table B of the ABC policy for exact windows. A justification alone gets you through the first deadline, but not the later mitigation and remediation deadlines, so findings generally need to be resolved, not just justified, once their window closes. Vendors and contributors are responsible for all pipeline scan findings on their own container layer; base image findings should not appear there, and if they do, the base image itself hasn't been reviewed for recent findings.
3.5 Where can I find more detail on ABC/ORA scoring?
See our Overall Risk Assessment documentation or ABC Compliance documentation. A few quick facts: FIPS does not currently affect ORA, and failed pipelines never affect ORA, though successful pipelines affect it positively.
3.6 How do I request VAT access, and how do I get updates or give feedback?
Open an issue in Repo1, fill out the VAT Access Request issue template, and apply the CSO::To Do label. For updates or feedback once you have access, use our Iron Bank Value Stream channel on Mattermost.
3.7 Is there an SLA for vendors to respond to updates?
Vendors should respond within the timelines outlined in the ABC document and are expected to automate container updates and dependency patching with as little delay as possible. We recommend using Renovate to help keep your images current — see our Iron Bank Automating Updates guide for setup details.
4.0 Security and ATO
4.1 Can my container image receive an ATO?
Not on its own — hardened containers support an ATO rather than carrying one individually. If you already have an ATO through Platform One, you don't need a separate one for your Iron Bank container. Party Bus is a related P1 organization that uses Big Bang to run vulnerability scans and assign a score to help you get your own app approved and hosted; contact the Party Bus team or your Customer Success Advocate for ATO-specific questions.
4.2 What are my responsibilities after my image is onboarded?
New findings must be addressed as soon as possible, and your application and its dependencies must be kept up to date. You're responsible for justifying all findings on your own container layer, though findings tied to the base image should already be handled upstream.
5.0 Container Hardening Process
5.1 What is Iron Bank's role in the hardening process, and how do I get help?
For contributor-owned containers, the Iron Bank team can assist with resolving pipeline issues, merging development branches, and running verification once you add the Review tag. Outside of that, responsibility rests with the contributor. For hands-on help, create an issue in your GitLab repository and apply the CSO::To Do label — a member of the Customer Success and Onboarding (CSO) team will review, remediate, and escalate as necessary.
5.2 Which base image should I use, and how do I browse what's available?
Any Iron Bank image can be used as a base image, and the right choice depends on your needs. Common options include Alpine, Debian, Ubuntu, Red Hat UBI, Google Distroless, Chainguard, and SUSE — Alpine, Debian, UBI, and SUSE are FIPS-friendly. To browse the full catalog, visit the Iron Bank Image Catalog and filter by Base Images under Categories.
5.3 How do I check or communicate the status of my container?
Watch the associated GitLab Issue and post updates there directly. You can also request access to the VAT tool by opening a VAT User Access Request in your repository for a detailed findings breakdown.
5.4 Are there any size limits for container images?
Yes — the maximum size limit is 20 GB. Contact the Iron Bank team for details on requesting an exception.
5.5 Can I use an open-source container that isn't in Iron Bank as a base image?
Build on top of an existing Iron Bank base image instead. You can pull specific components from an outside open-source image into your build, but the open-source image itself shouldn't be used directly as your base. If you believe an open-source image should be added to Iron Bank, submit a request through the Vendor Onboarding procedures.
6.0 Pipeline
6.1 Can I download external resources as part of the container build process?
Yes — specify the URL, filename, and SHA sum in your hardening_manifest.yaml. See the Iron Bank Hardening Manifest guide for details.
6.2 If my artifacts are hosted in a protected location that requires credentials, can I download them in the pipeline?
Yes. Work with a member of the CSO team to add the necessary credentials to your GitLab group, then specify the authentication details in your hardening_manifest.yaml — see the example in the Iron Bank Hardening Manifest guide.
6.3 Can I get access to a pre-production environment to test my application?
Not at this time. Due to the DoW's security posture, you must set up your own environment to validate your container's functionality — Iron Bank does not run or test containers in the pipeline, only build and scan them.
7.0 STIGs and Compliance
7.1 What is the relationship between ABC compliance and DoW STIGs?
There is no direct relationship. ABC compliance is determined by automated artifact generation and scanning results, not STIG status.
7.2 Is this image STIGed, and how can I access the results?
Images that are STIGed include "STIG" in their name or README.md. Iron Bank does not STIG every image; instead, we apply baseline security settings that keep images broadly usable across the community, and some images are STIGed to the extent possible. In the Security Findings Report, many OpenSCAP findings carry the justification Does Not Apply, since many STIG checklist items don't pertain to the application layer.
8.0 Onboarding and Support
8.1 How can I check the status of my onboarding request?
If you've submitted an onboarding application, check the status by opening an issue in Repo1 dccscr or through the Iron Bank Help Desk. The CSO team will generally reach out shortly after you submit your request.
8.2 What is the best way to get general help or support?
If you already have a container on Iron Bank, create an issue in your repository. You can also attend an Iron Bank Weekly session, or view our Support information for further guidance.
9.0 Miscellaneous
9.1 How can I get invited to the Mattermost server?
Email aflcmc.hncx.p1cst@us.af.mil with your request.
9.2 How do I delete an old image from the Iron Bank repository?
Images cannot currently be deleted. You can archive an image, which hides it from the public but keeps it pullable — this supports downstream programs that may not yet be on your container's latest version.