DWS Blog | 12.16.2025 Ep 21

December 16, 2025

Episode 21

Project Star Fox: Evolving Cloud Compliance and Security

Lessons learned from architecting a new model for cloud operations in the Department of Defense

Author: Brian 'BP' Panarello

Introduction and Platform Overview

Project Star Fox is the Dark Wolf internal title for the Nebula Controlled Services Environment, a cloud platform built for the United States Space Force’s Assured Access to Space launch community, comprising System Delta 80 and Space Launch Deltas 30 & 45 enabling launch missions on both coasts. It is a cloud-native ecosystem that we purposefully architected to streamline the Department of Defense (DoD) Risk Management Framework (RMF) processes by fully leveraging the promise of cloud computing. This environment provides a pre-authorized platform where mission owners can deploy applications without navigating the full complexity of traditional compliance hurdles. We achieved this feat by leveraging AWS provisionally authorized services, as well as focusing on “authorize the process, not the product.” That process relied on us building an environment based on a “self-healing” architecture and automated governance, reducing the burden of cybersecurity on development teams, and allowing them to focus on their mission capabilities rather than compliance checklists.

The Origin Story

In November of 2022, I got a ping on our internal Slack from Melissa Jewett, one of our (at the time) directors from our Cybersecurity Practice Area, and one of my (still at this time) favorite people at Dark Wolf.

“Hey BP, I’m meeting with a Space Force Major this week to discuss some potential work. Would you mind hopping on the call with me to provide some technical back-up and be willing to answer some RMF questions?”

Fast-forward to March of 2023, where Melissa, Will Kline (director of platform engineering, the primary architect of the Nebula platform, and smartest person I’ve ever had beers with), and myself (at the time, a lowly Senior Engineer and cybersecurity architect, partnered with Will on designing the environment) sat around a table at Patrick Space Force Base, listening to our customer describe their mission: A cloud platform that allows for the migration of both new and legacy launch-relevant applications. The catch, however, was the ability to maintain fine-grained Financial Operations (FinOps) records to support a chargeback model to commercial launch providers using USSF assets to enable their missions – think Blue Origin or SpaceX using USSF resources for weather and safety modeling, and launch-day monitoring.

At the time, no existing DoD platform met the FinOps requirements needed, so we made the decision to build one ourselves. As we sat in the room listening to different groups of application developers, mission operators, and program managers describe their frustrations with current cloud offerings, or their inability to achieve an Authorization to Operate (ATO) through traditional means, Will and I knew we had to do something different.

(Not) Reinventing the Wheel

Will and I dug into the DoD CNAP Reference Design and decided that this – along with DISA’s provisional authorizations of AWS native services – would be the centerpiece of our new approach. And when I say “new approach,” I mean doing exactly what Kessel Run, Cloud One, and P1 already did – we just had a unique idea to leverage as many AWS services as possible, leverage provisionally approved software where we couldn’t use AWS services, and architect as many RMF controls into the DNA of the platform itself as possible to expedite the ATO process. By doing those things, we discovered, we could keep the platform itself on compliant rails – and automatically reel in compliance drift through configuration management automation – while giving enough freedom and flexibility to developers to accomplish their mission. Using this model, we reckoned we could provide IaaS, PaaS, and even FaaS offerings to mission owners while shouldering the majority of the compliance burden ourselves.

Upon its debut, Nebula operated under a single ATO at Impact Level 4, providing upwards of 80% control inheritance coverage for tenants of the environment.

The Rub

This new operating model introduced some challenges. Our original Security Control Assessors (SCAs) had a new paradigm that they hadn’t previously encountered. Further, the “one ATO” model made it difficult to distinguish between simple web applications inheriting the platform’s controls and complex systems that required more independent scrutiny.

This was a whole new ball-game, something never seen in the DoD before.

While the platform successfully demonstrated the core concepts Will and I were after – the CNAP concept, “self-healing” mechanisms, and compliance built into the structure of the platform – the ambiguity in control responsibility slowed onboarding velocity.

Embracing Evolution: One Year Later

Project Star Fox had some incredible wins in its first year of existence. From the time we committed the first line of production code to the time we achieved our full 2-year ATO, only 10 months had passed – which, in the world of ATOs, is practically a physics-defying Ludicrous Speed (n.b. – we have yet to achieve the as-of-yet purely theoretical Plaid Speed).

But the blurred lines of tenant responsibility were still causing issues. And so enters the Project Star Fox secret weapon:

Bruce Dillon, Information System Security Manager.

Defining Tenant Deployment Models

Bruce introduced a new definition and process for how Nebula handles tenants by separating them into two distinct types:

Mission Applications are small, web-based capabilities that fully reside within the platform. This tenant type relies exclusively on provisionally authorized AWS services or services already authorized under the Nebula ATO – such as identity and access, network traffic inspection and control, and security information and event monitoring. Because of this complete inheritance of existing controls, Mission Applications fall directly under the Nebula ATO, reducing mission owner compliance activities to a short questionnaire and a handful of agreements. A key differentiator – Mission Applications are granted an “ATO security blanket” by Nebula, but not necessarily at the expense of control. Developers are still granted a large amount of autonomy, but are held to secure best practices through the guardrails built into the platform.

Mission Partners are more complex applications that do not fit cleanly into the Mission Application model. These tenants are able to inherit pieces of Nebula – such as our CNAP, guardrails, and access to AWS services – but need to deploy their own solutions, primarily utilizing Nebula as an infrastructure provider. This model pursues their own ATO using Nebula as a common control provider – still drastically reducing the time to ATO, but keeping the responsibility in the hands of the Mission Partner.

Compliance Engineering and a Self-Healing Environment

Though originally conceived of by Will and myself, much of the focus for Nebula went into quickly getting the platform production ready and ATO’d. In the year since hitting that milestone, though, our platform and cybersecurity engineers have been hard at work implementing our vision of transforming Nebula into something new to the DoD:

A platform where cybersecurity and compliance are a by-product of the platform’s operations – not something that’s tacked on at the end, and then frantically updated 6 weeks before the next authorization window.

This Herculean task – taking broad ideas sketched on a whiteboard and turning it into actual Infrastructure as Code – was accomplished by none other than Project Star Fox’s own Hercules:

Ryan Romero, Lead Platform Engineer.

Ryan’s experience at the intersection of platform design, operations, and sound cybersecurity allowed him to take the idea of “self-healing” and implement it as code into the infrastructure of Nebula, while keeping the developer experience as agnostic to the controls as possible. Rather than blocking developers with rigid permissions, the focus shifted to responsive controls, using AWS tooling like Lambda functions to detect non-compliant configurations (e.g., unencrypted S3 buckets) and remediate them in real time. This made it functionally impossible for a developer to introduce a vulnerability to the platform. The guardrails put in place allowed developers autonomy while ensuring the environment remained secure – all without human intervention.

Another major feature implemented as part of this effort was log visibility as a service. The team democratized access to the core Security Information and Event Management (SIEM) tools. By doing this, tenants can view logs specific to their applications via Nebula’s central Elastic stack, eliminating the need for redundant and costly logging infrastructure and licensing. This solution, designed and implemented by Platform Engineer Ben Steele, is referred to as the Shared Elastic Agent & Kibana Resources (or SEAKR) – and was recently deemed awardable on the Platform One Solutions Marketplace because of the unique challenges it solves.

Why Does It Matter?

Project Star Fox fundamentally transformed DoD cloud platform utilization. It champions rapid adoption and engineering enablement, eliminating the frustration of "fighting the platform" and lengthy support delays. We achieved this through a declarative, intent-based design that promotes security and best practices without forcing developers into a rigid mold.

Crucially, Star Fox stands out as arguably the most cost-efficient ATO'd cloud platform available, boasting no reseller markup and a trajectory of decreasing costs with every update. Its accessibility and reliability are exceptional, with phenomenal uptime and the flexibility to access the system from commercial or NIPR networks, with or without a CAC. This modern platform consistently operates on the bleeding edge, evidenced by its established support for building AI systems on Bedrock for the past six months.

Furthermore, Star Fox is built for the future of government technology. The platform is highly scalable and reliably integrates with existing on-premise and hybrid systems across the US, with multicloud expansion planned for 2026. It offers near 100% real-time visibility into logs, metrics, access controls, and financial costs, ensuring a transparent, auditable, and compliant platform that meets standards like 800-53 Rev5 and the ICAM initiative. Above all, Star Fox delivers security without sacrificing convenience or capability, intelligently automating compliance rather than brute-forcing it onto users.

The Future of Star Fox

Program Manager and Chief Cat Herder Martin Ducote-Clark has led his team to some of the DoD’s most innovative solutions. From the implementation of the CNAP, to one of the fastest ATOs most people have seen in the DoD, to onboarding Nebula’s first tranche of tenants; and he hasn’t stopped yet. Star Fox has a road map for the future of the Nebula platform, where it continues to incubate innovation, providing first-in-class functionality to the Space Force Launch Community. Be on the lookout for the upcoming features and milestones for Nebula:

Impact Level 5 Authorization: The Star Fox team is currently undergoing a major modification to the ATO – shifting from RMF revision 4 to revision 5, incorporating the ~400 new DAF baseline controls and the ~80 additional rev 5 controls, and expanding the ATO to allow IL5 data, all under a single umbrella authorization.

Continuous Compliance: As part of that effort, and as an extension of the “self-healing” principles, the team is transitioning from periodic audits to a truly continuous authorization model. Star Fox’s RMF team is undergoing training in Python, OpenTofu, and AWS engineering to implement ongoing auditing and authorization measures, producing evidence of compliance as a function of the platform itself. No longer do we rely on spreadsheets and PDFs that become out-of-date the moment they’re complete – instead, the team is making Nebula itself the body of evidence.

FinOps Foundation: To support future government data and efficiency requirements, Nebula’s architecture is being updated to provide even more granular FinOps data, enabling tenants to build cost optimization directly into their application lifestyles, and allowing the government more fine-tuned chargeback capabilities.

Continued Innovation Incubation: In addition to the forward-leaning authorization strategies, the “self-healing” compliant infrastructure, and tools like SEAKR, Project Star Fox continues to be an incubator for fresh ideas that solve problems in new and fascinating ways. One such tool – conceived of by Ryan Romero while trying to provide a communication mechanism between Nebula and Platform One while maintaining each platform’s identity and zero-trust sovereignty – is codenamed Project Raven. Project Raven utilizes immutable hardware factors (such as TPMs) to establish trust between applications residing on separate platforms, removing the need for less secure API keys or certificate exchanges.

The Best Is Yet to Come

Ultimately, Project Star Fox is more than just a list of technical specifications or a compliance checklist; it is a testament to what a dedicated team can achieve when they absolutely refuse the status quo. From that first conversation at Patrick Space Force Base to the “self-healing” ecosystem driving launch missions today, we have proven that security and velocity are not mutually exclusive. As the Star Fox team looks towards IL5 authorization and beyond, our mission remains the same: Clear the red tape so the Space Force can clear the launch pad.

Page updated

Report abuse

Episode 21

DARK WOLF SOLUTIONS