Achieving FedRAMP’s Container Scanning Requirements
ConMon costs for container scanning can be high due. Learn how to make your FedRAMP compliance program more efficient and better for your team.
ConMon costs for container scanning can be high due. Learn how to make your FedRAMP compliance program more efficient and better for your team.
ConMon costs for container scanning can be high due. Learn how to make your FedRAMP compliance program more efficient and better for your team.
ConMon costs for container scanning can be high due. Learn how to make your FedRAMP compliance program more efficient and better for your team.
ConMon costs for container scanning can be high due. Learn how to make your FedRAMP compliance program more efficient and better for your team.
FedRAMP requires that all applications and systems in scope be scanned and monitored for vulnerabilities. It allows applications that have components in containers; these must be configured and monitored as regular FedRAMP systems, and have some additional requirements.
FedRAMP requirements for containers
In March 2021, the FedRAMP PMO (Program Management Office) issued guidance specifically addressing the security assessment and authorization of containerized systems. Before this, there was a lack of clear guidance on how to apply FedRAMP controls to containerized environments, leading to inconsistencies and potential security gaps. The new guidance aimed to standardize vulnerability scanning requirements for containers, ensuring that Cloud Service Providers (CSPs) using container technologies met the same rigorous security standards as those using traditional systems.
The document lists five requirements, which we’ll summarize here.
1. “Hardened Images” must be used
The image that produces the container must meet the system security (“hardening”) guidelines in NIST SP 800-70.
2. The process of building and deploying containers has to be automated
With a few exceptions…
- Automation that builds might not be in scope for FedRAMP, but the “registry” (where production container images live) and points after are definitely in scope.
- Your automation has to prevent containers that don’t meet FedRAMP requirements from being deployed to production.
3. You have to perform vulnerability scanning on container images before deployment
You have 30 days between when you put an image into a registry and when you have to complete a container scan. FedRAMP strongly recommends automating scans as part of the automation processes required above.
4. You have to monitor the container image registry
The purpose of this requirement is to make sure things that don’t meet requirements can’t be deployed. It’s in addition to the “scan before you publish” and “stop unauthorized thing from being deployed” requirement -- point is to require multiple checks
5. You have to maintain an accurate inventory
Your inventory must include your container images and how they connect to running containers.
Why container scanning increases ConMon costs
Container image scanning is a common component in product security programs, in which a security team uses tools that examine the contents of each container image for risks, such as known vulnerabilities or evidence of malicious code. This is a similar approach to that of Software Composition Analysis (SCA) tools, except that container image scanning is inspecting both container image and application layer vulnerabilities.
Problem 1: Too Many Vulnerabilities
Also like SCA, container scanning can be done prior to deployment or at runtime, but we find it’s most common for organizations to scan in the SDLC — often after the container is published to the registry. And while it’s important to know what vulnerabilities are running in production, if you can’t find these vulnerabilities before they ship, you’re adding more to your ConMon (continuous monitoring) burden. Late detection forces immediate action to assess and remediate vulnerabilities while they are actively exploitable in a live environment. It puts pressure on security teams to quickly update their Plan of Action and Milestones (POA&M) and can lead to rushed remediation efforts with tight deadlines.
Problem 2: Double Filings
If you’re familiar with the landscape of AppSec tools, you might already see the second problem related to containers and FedRAMP. Multiple tools (SCA and container scanning) are going to find the same open source vulnerabilities, but they'll be reported as separate findings. Imagine your SCA tool and your container scanner both flagging Log4j - suddenly, one vulnerability looks like two. This not only makes your security posture seem worse than it is, but it also leads to wasted time and effort trying to fix the same issue twice. In the world of FedRAMP, this is called double filing.
The Solution: Consolidated Scanning at Build
Adding container vulnerability scanning to the SDLC build stage allows for a more proactive approach to FedRAMP. This provides more time for remediation, reduces the risk of service disruptions, and allows for a more manageable ConMon process. And to avoid the double-filing problem, it's crucial to have tools that can correlate findings across different scanning types, and ideally, do it as early in the SDLC as practical.
Reduce the cost of ConMon for containers
By combining container scanning with SCA and artifact signing, Endor Labs delivers four capabilities that reduce your costs of maintaining FedRAMP authorization:
- Container vulnerability scanning in pipelines. Scan your containers for vulnerabilities, identify base images, and set policies that can block pushing to registry and/or help your engineering teams ensure they’re publishing safe images
- Correlate container vulnerabilities with SCA vulnerabilities automatically. Reduce cost of tracking, as well as speed up research and repair of vulnerabilities.
- Routine container vulnerability scanning in registries. Schedule routine scans of container images in registries to help meet the requirement to monitor the container image registry.
- Sign containers and components to prevent unauthorized deployments. Create strong container signatures with no new infrastructure. Verify signatures before deployment to ensure that non-compliant (unsigned, invalid, or revoked) containers cannot be deployed.
Book a demo to learn more about how Endor Labs makes it easier to comply with FedRAMP while also creating a better experience for your developers.