Engineering for federal compliance: How FedRAMP improves security for every Fieldguide customer

Fieldguide’s FedRAMP Class C (Moderate) federal environment is now live. Our launch announcement explains what the environment enables for firms conducting CMMC assessments and NIST SP 800-171 engagements for clients in the defense industrial base.

DFARS 252.204-7012 applies to covered defense information, which includes CUI that meets the clause’s contractual conditions. When a contractor uses an external cloud service provider to store, process, or transmit covered defense information, the clause requires the contractor to ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline and complies with its cyber incident reporting and related provisions.

This post explains the engineering work behind the environment and how every customer benefits from it.

Controlling every service that handles a request

We started by identifying every third-party service that touches a request. Each service had to move to an offering with its own FedRAMP certification, come within Fieldguide’s authorization boundary, or be disabled in the federal environment.

For some services, we adopted FedRAMP certified offerings from the same vendor, including services for observability and AI model traffic. For others, including authentication and email, we moved to new vendors.

We brought other services within the boundary and now operate them ourselves, including Temporal, our workflow orchestration engine, and our GraphQL gateway.

Keeping AI model traffic within the authorization boundary

Firms use the federal environment to run Field Agents on engagements involving CUI. During a CMMC engagement, Field Agents test the assessment objectives, draft control narratives, review and summarize evidence, and assemble workpapers. Each output includes supporting rationale and citations to its source documents. A practitioner reviews the work and owns the conclusion.

Every model that a Field Agent calls is accessed through a FedRAMP certified service or runs within Fieldguide’s authorization boundary. No CUI is sent to a model outside the boundary. Model providers undergo the same review as other service providers, including contractual requirements for zero data retention and no training on customer data.

We also provide prebuilt CMMC templates that map the 110 NIST SP 800-171 Rev. 2 security requirements to the 320 CMMC Level 2 assessment objectives. We update this content as governing standards evolve, including preparations for the future adoption of NIST SP 800-171 Rev. 3. Cross-mappings among NIST SP 800-171, NIST SP 800-53, and CMMC help firms reuse testing and evidence across federal engagements.

Assessment results can be exported as schema-validated packages formatted for CMMC eMASS. Firms can also generate readiness reports, gap summaries, and system security plan documentation from their own templates.

Extending validated cryptography across the Kubernetes cluster

To ensure that cryptographic services protecting federal customer data use validated modules, we addressed the full Kubernetes stack: application containers, cluster components, and host Amazon Machine Images (AMIs).

We use hardened images that include FIPS 140-3 validated cryptographic modules for cluster components and apply those images as overrides for managed add-ons. Worker nodes run FIPS-enabled AMIs, and services in the federal environment use AWS FIPS endpoints.

We also restrict ingress for customer request traffic. Application services accept that traffic only through our edge and have no direct network path from elsewhere in the virtual private cloud.

Moving services to hardened base images

Before this work, most findings in our container images came from operating system packages that our code didn’t even call because the Linux distribution selected for each service’s base image included those packages. Fixing the findings one package at a time would have created a recurring remediation queue without addressing their source.

To solve this, we moved to Chainguard's hardened images. The images contain far fewer packages than a general-purpose distribution image, are built from source, and typically have few or no known CVEs.

The build process generates supporting evidence. We copy images into our Amazon Elastic Container Registry (ECR) repositories, and each service builds from an image digest pinned in its code repository. Our FIPS image sync retrieves the SPDX software bill of materials (SBOM) attestation and extracts the relevant NIST CMVP and Entropy Source Validation (ESV) certificate numbers. If an image claims to be FIPS-enabled but its SBOM does not identify a validated module, the job fails. This process ties the FIPS evidence to the exact image we deploy and removes manual reconciliation.

Reducing software supply chain risk

One form of software supply chain attack begins when an attacker publishes a new package version through a compromised maintainer account. CVE scanning detects vulnerabilities that have already been cataloged, so a version compromised only hours earlier may still pass a scan.

We use Socket to flag dependencies based on their behavior, including unexpected network requests, unnecessary access to environment variables, unusual installation scripts, and obfuscated code. The check runs when a pull request introduces a dependency. Critical- and High-severity findings block the merge, and scheduled scans run across every repository.

We also apply a release cooldown: a package version published less than three days ago can’t resolve into a build. Malicious releases are often reported and removed during that window, so the delay reduces the chance that they enter our dependency tree.

We maintain searchable inventories across repositories, allowing us to determine whether a specific package and version appears anywhere in our dependency tree.

Scanning source code and secrets

GitHub Advanced Security covers the code we write. CodeQL checks pull requests targeting protected branches and runs scheduled scans of default branches. The scheduled scans apply newly added rules and cover changes that don’t pass through a typical pull request. GitHub Secret Protection’s push protection blocks pushes that contain credentials, preventing those secrets from entering a repository.

We also participate in GitHub’s Secret Scanning Partner Program. If someone commits a Fieldguide API token to a public repository, GitHub notifies us so we can revoke it.

Prioritizing and automating vulnerability remediation

We evaluate detected vulnerabilities using the context reflected in FedRAMP's 2026 rules for Vulnerability Detection and Response and for Vulnerability Evaluation and Reporting.

CVSS describes a vulnerability’s potential severity, but it doesn’t show whether the vulnerable path runs in our environment or whether a triggering payload can reach the affected service from the internet. Our evaluation also considers the criticality of the affected resource, the data behind it, reachability, and exploitability signals such as the Exploit Prediction Scoring System (EPSS). A critical vulnerability in code that never executes presents a different risk from the same vulnerability on an internet-reachable path that handles sensitive data.

We automate the repeatable parts of remediation. Package Patrol, a bot we built, reads Socket findings and opens dependency pull requests. It batches related security updates by repository and includes upstream release context in each pull request. A separate bot updates pinned image digests when upstream images are rebuilt, and continuous integration validates each update.

Changes that require more investigation go to Forge, our internal engineering platform. Forge prepares a pull request and sends it through the same reviews and checks as other code. Engineers still review each change, but they don’t have to prepare every routine update themselves. This workflow helps us meet remediation deadlines across a large set of services.

Continuously monitoring the federal environment

Knox, the managed cloud platform hosting Fieldguide’s federal environment, regularly scans our images and other application components with Wiz. The resulting SBOMs form part of our continuous monitoring evidence.

These scans feed the same risk-based evaluation and remediation workflows used across our repositories and build systems.

Applying the same baseline across production environments

Federal compliance also changed our commercial production environments, so every Fieldguide customer runs on the same foundations. Chainguard images and FIPS-mode cryptography now run in every commercial production region.

Applying these changes across environments allows commercial customers to use the same lower-CVE base images and FIPS-validated cryptographic modules used in the federal environment. It also avoids maintaining separate infrastructure foundations for federal and commercial deployments.

Customers in the federal environment receive a Customer Responsibility Matrix and a Control Implementation Summary that identify the controls they inherit from Fieldguide and the controls they must implement themselves.

FedRAMP certification brought together engineers across every team at Fieldguide. Every customer benefits from the lower-CVE images, validated cryptography, and supply chain controls introduced through this work. We're excited to support audit and advisory firms serving the defense industrial base.