Creating a FedRAMP Compliance Checklist

Creating a FedRAMP compliance checklist can be vital to approaching compliance methodically.  While government contracting is full of FedRAMP challenges stories, the move to cloud-native development grants us new tools, technologies, and methodologies to better set your projects up for FedRAMP compliance success. It’s up to you to capture these best practices in a checklist or process flow for your teams to follow.

Considerations for your FedRAMP Compliance Checklist

Here are some concerns to include in your checklist:

1. Shift Security Left

Shifting left describes using tools and practices to improve and encourage more rapid feedback from security stakeholders about security and compliance into the early development stages. However, the objective is always to hand bugs and fixes back to developers as part of a smooth, ongoing, continuous development process.

Unit testing is a familiar example of shifting left by delivering early, user-experience feedback on functionality.  Shifting unit testing left  ensures that most problems are caught early, during the development stage, where it is quicker and simpler to remedy them.

By shifting security left, the handling of each vulnerability becomes an integral part of the CI/CD pipeline. This prevents a mass of vulnerabilities from appearing as a single irritating blockage before your team admits a system into production. More frequent vulnerability scanning during development ensures bugs and other issues can be dealt with quickly and efficiently as they arise, and security becomes a part of the development process.

With the primary focus of CI/CD environments on fast, efficient development and innovation, security has to work efficiently as part of this process. Anchore advises that DoD and federal security teams use tools that can deliver rapid feedback into development. Security tools must integrate with typical CI/CD and container orchestration tools.  The tools you choose should also promote early-stage interaction with developers.

2. Follow the 30/60/90 rule to keep Images Secure

Anchore recommends following the 30/60/90 rule to satisfy the guidance outlined in the DoD Cloud Computing Security Requirements Guide. This rule sets out the number of days to fix security issues: 

  • 30 days to fix critical vulnerabilities 
  • 60 days to fix high vulnerabilities
  • 90 days to fix moderate vulnerabilities 

In support of this, it is also strongly recommended to use a tool that allows security teams to update and validate vulnerability databases with new security data frequently. Not only  is this necessary to satisfy Security Controls RA-5(2), but  using such a tool is a best practice to ensure your security data is timely and relevant.

By following the 30/60/90 rule and ensuring that you update your vulnerability databases and feeds promptly, you empower your security teams to remediate new security challenges quickly and efficiently.

3. Make use of Tools that Support Container Image Allow/Deny Listing

Federal agencies should leverage container security tools that can enforce allowlisting and denylisting of container images. Maintaining allow and denylists are common methods of securing networks and software dependencies. However, they are less common in a containerized environment.

This capability is crucial, as attackers can potentially use containers to deploy denylisted software into secure areas such as your DevOps toolchain. The elements and dependencies of a container may not always appear in a software bill of materials (SBOM) from existing scanning tools. Therefore it’s crucial that the tools used can examine the contents of a container and can enforce allowlist and denylist safeguards.

Anchore advises that container image denylisting should occur at the CI/CD stage to allow rapid feedback. By shifting the security feedback to the developers, they receive immediate feedback on issues. This technique allows for faster remediation, as denylisted container images or the software contained within them are immediately flagged to the developer.

4. Deploy a Container Security Tool that Maintains Strong Configuration Management over Container Images

Software delivery and security operations teams should maintain an accurate inventory of all software they deploy on any federal information system. This inventory gives both teams accurate situational awareness of their systems and enables more precise decisionmaking.

Anchore advises federal agencies to implement a container-native security tool that can systematically deconstruct and inspect container images for all known software packages and display findings for information security personnel in an organized and timely manner.

5. Use a Container Scanning Tool that runs  on IL-2 through IL-6

The DoD and federal agencies must leverage tools that keep any vulnerability data regarding the information system within their authorization boundaries. However, many FedRAMP vulnerability scanning tools require an agent that connects to the vendor’s external cloud environment. The DoD designates this as interconnectivity between DoD/federal systems and the tool vendor and would rule out the use of any agent/cloud-based tool within an IL-6 classified environment.

Where organizations still choose to implement an agent-based container security tool, they are then responsible for ensuring that the security vendor maintains an up-to-date accreditation for their cloud environment. The environment must also have the relevant RMF/FedRAMP security controls that the federal information system can inherit during the ATO process. In addition, any DoD or federal agency should ensure the agent-based tool can run in both classified/unclassified environments.

Learn how Anchore brings DevSecOps to DoD software factories.

6. Express Security Policy as Code

Where possible, select tools that enable your teams to define security policy as code. These tools enable security teams to establish and automate best practices that they can push to tools, either across the network or in more secure environments.

Expressing security policy as code also enables your ops teams to manage systems using existing software development life cycle (SDLC) techniques. For example, policy as code enables the versioning of security policies. Now teams can compare policy versions for configuration drift or other unexpected changes.

In essence, it will enable the policies themselves to be subjected to the same level as rigorous as the code they are applied against.

The onus of implementing new security policies shifts security left onto developers. It can be important not to tighten container security policies too far in one step. Versioning also enables any agencies to improve and tighten security policy over time.

This iterative approach towards improving security stops over-intrusive security policies from stalling development in the CI/CD pipeline. It prevents the emergence of any culture clash between developers and security operations. Security teams can begin with a policy base that delivers on minimum compliance standards and develop this over time towards evolving best practices.


Think of a FedRAMP Compliance Checklist as more than just a documented list of activities your teams need to perform to get your application FedRAMPed. Rather, think of it as a methodical and strategic approach for your developers and security teams to follow as part of holistic and proactive strategies for secure software development and government compliance. 

Download our FedRAMP containers checklist to help jump start your organization’s FedRAMP compliance checklist.

Cybersecurity Executive Order Brings FedRAMP Changes Aplenty

On May 12, 2021, President Biden’s Executive Order on Improving the Nation’s Cybersecurity finally hit the street. Amongst all its goodness about the software bill of materials (SBOM), software supply chain security, and cybersecurity there’s some good news about FedRAMP and these developments are going to be a major step forward for government cloud security, compliance, and the government cloud community.

Here are some FedRAMP highlights from the executive order (EO):

Security Principles for Cloud Service Providers

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) are increasingly providing secure platforms for the next generation of federal government applications. Case in point, federal government agencies spent $6.6 billion on cloud computing in fiscal 2020. That figure is up from $6.1 billion in fiscal 2019, according to a government spending analysis by Bloomberg Government, as reported by NextGov. Section 3 Modernizing Federal Government Cybersecurity, states:

The Secretary of Homeland Security acting through the Director of CISA, in consultation with the Administrator of General Services acting through the Federal Risk and Authorization Management Program (FedRAMP) within the General Services Administration, shall develop security principles governing Cloud Service Providers (CSPs) for incorporation into agency modernization efforts. 

We’ll have to wait and see how this might affect the container orchestration and security offerings of the major CSPs and the opportunities it may open for the system integrators (SIs) and the innovative SBIRs across the federal information technology ecosystem.

Federal Cloud Security Strategy in 90 Days

The EO also positions FedRAMP — as part of the General Services Administration — as part of a task force to create a federal cloud security strategy in 90 days and then provide guidance to federal agencies. Here’s the quote from the EO:

Within 90 days of the date of this order, the Director of OMB, in consultation with the Secretary of Homeland Security acting through the Director of CISA, and the Administrator of General Services acting through FedRAMP, shall develop a Federal cloud-security strategy and provide guidance to agencies accordingly. Such guidance shall seek to ensure that risks to the FCEB from using cloud-based services are broadly understood and effectively addressed, and that FCEB Agencies move closer to Zero Trust Architecture.

There have been a few runs at a federal-level cloud strategy over the past few years. Most recently, there’s Cloud Smart that seeks to redefine cloud computing; modernization and maturity, and tackles security concerns, such as continuous data security and FedRAMP. Cloud Smart replaces Cloud First, an earlier government-wide initiative to provide a cloud strategy for federal agencies.

Federal agencies and technology firms serving the government should pay attention to the development of this new cloud security strategy as it’ll influence future cloud procurements. Their ambitious 90 day goal to deliver this strategy leaves virtually no time for any feedback from the government’s industry partners.

90 Days to a Cloud Technical Reference Architecture

 With large government cloud initiatives such as the United States Air Force’s Platform One gaining mindshare, other parts of the Department of Defense (DoD) and civilian agencies are certain to follow suit with large scale secure cloud initiatives. The EO also mandates the creation of a cloud security technical reference architecture:

Within 90 days of the date of this order, the Secretary of Homeland Security acting through the Director of CISA, in consultation with the Director of OMB and the Administrator of General Services acting through FedRAMP, shall develop and issue, for the FCEB, cloud-security technical reference architecture documentation that illustrates recommended approaches to cloud migration and data protection for agency data collection and reporting.

Just like the cloud security strategy, 90 days is an ambitious goal for a cloud technical security reference architecture. It’ll be interesting to see how much this architecture will draw upon the experience and lessons learned from Platform One, Cloud One, and other large scale cloud initiatives across the DoD and civilian agencies.

FedRAMP Training, Outreach, and Collaboration

FedRAMP accreditation and compliance is no easy task. The EO mandates establishing a training program to provide agencies training and the tools to manage FedRAMP requests. There’s no mention for training for the SI and government contractor community at this stage but it’s almost a certainty that the mandated FedRAMP training will find its way out to that community.

The EO also calls for improving communications with CSPs which normally falls under the FedRAMP PMO. Considering the complexities of FedRAMP, improving communication should be an ongoing process so the automation and standardization of communications that the EO touts could take some of the human error that might occur when communicating a technical status.

Automation is also due to extend across the FedRAMP life cycle, including assessment, authorization, continuous monitoring, and compliance. This development can help make the much-heralded Continuous ATO a reality for more agencies. It also opens the door for more innovation as SIs seek out startup partners and SBIR contracts to bring innovative companies from outside the traditional government contractor community to satisfy those new automation requirements.

Learn how Anchore helps automate FedRAMP vulnerability scans. 

Final Thoughts

Cloud security concerns are universal across the commercial and public sectors. Biden’s EO strikes all the right chords at first glance because it elevates the SBOM as a cybersecurity vulnerability. It also gives FedRAMP some much-needed support at a time when federal agencies continue to face new and emerging threats.

Want to learn more about containers and FedRAMP? Check out our 7 Must-Dos To Expedite FedRAMP for Containers webinar now available on-demand!