If you’ve been following the Department of Defense’s (DoD) modernization efforts, you have probably noticed a significant shift in how the US Navy approaches deployment. Historically, the path to an Authorization to Operate (ATO) was a grueling marathon that often delayed critical capabilities by months or years. Today, the U.S. Navy is pivoting toward a model that prioritizes speed without sacrificing the rigorous security standards required for mission-critical systems.
At the heart of this transformation is RAISE 2.0. It is a framework designed to automate the Risk Management Framework (RMF) and move away from static, one-time security checks. By leveraging an authorized RAISE Platform of Choice (RPoC), the Navy is essentially rewriting the rules of software delivery.
Visibility: The Foundation of Every Security Check
Before you can secure a system, you must understand its composition. In the microservices-based world we operate in today, software stacks have become increasingly complex. They are no longer single blocks of code but intricate webs of dependencies. The Navy recognizes that you cannot defend a “black box” against modern threats like Log4j or any of the recent supply chain compromises.
As Brian Thomason, Partner and Solutions Engineering Manager at Anchore, puts it: “It’s hard to know what to fix in your software…if you don’t know what’s in your software.” This is why the security process begins with a high-fidelity Software Bill of Materials. An SBOM is a comprehensive ingredients list for your application.
How can we expect to manage risk if we are blind to the very components we are deploying?
Stop Waiting for ATOs: The Power of Inheritance
The traditional ATO process required every new application to justify its entire existence from the hardware up. This created a massive bottleneck where security teams were constantly re-evaluating the same underlying infrastructure and DevSecOps tools. RAISE 2.0 solves this by introducing the concept of a RAISE Platform of Choice (RPoC) (i.e., the Navy’s version of the more general DoD DevSecOps Platform or DSOP) with a pre-existing ATO.
“Raise 2.0 automates the RMF…eliminating the need for a new ATO; instead you inherit the ATO of the RPoC.” This mechanism allows application teams to focus solely on the security of their specific code rather than the platform it runs on. Why waste months certifying a pipeline that has already been vetted and hardened by experts? By inheriting a certified platform’s posture, developers can move from “code complete” to “production ready” in days rather than years.
The Accidental Leak: Moving Beyond Simple CVEs
Security isn’t just about identifying known vulnerabilities in 3rd-party libraries; it’s also about catching the human errors that occur during the heat of a sprint. While we like to think our internal processes are foolproof, history shows that sensitive credentials (think: AWS or SSH keys) find their way into repositories with surprising frequency.
Anchore’s platform doesn’t just look for CVEs; it scans for these “silent” risks. Brian notes: “We also detect leaked secrets… not that anybody in your organization would do this… but companies have been known to…” This capability acts as a critical safety net for developers working in high-pressure environments. What happens to your security posture if a single accidental commit exposes the keys to your entire cloud environment?
Security for Tomorrow: Managing the Zero-Day Disclosures
The moment an application is deployed, its security posture begins to decay. New zero-day disclosures and changing requirements mean that a “clean” scan from yesterday may be irrelevant by tomorrow morning. Static security checks are insufficient for modern warfare. We need continuous intelligence that tracks code throughout its entire lifecycle.
“Future changes; new requirements, zero-day disclosures, etc. are covered by Anchore’s SBOM-based approach.” By maintaining a version-controlled SBOM in a tool like Anchore Enterprise, the Navy can rescan deployed code against new threat intelligence every 12 hours. This provides a continuous feedback loop: if a new vulnerability is discovered in a library you deployed six months ago, you are notified immediately. Is your current process capable of identifying risks in software that is already deployed in production?
The Path Forward: Two Steps and One Habit
Implementing RAISE 2.0 principles isn’t an overnight task, but it is the only viable path for modernizing federal software delivery.
- Step 1: Standardize on SBOM generation. Integrate high-fidelity SBOM creation into your build process immediately to establish a baseline of truth.
- Step 2: Map your RMF controls to automation. Identify which parts of your compliance checklist can be handled by a platform like Black Pearl and/or Anchore.
- The Habit: Continuous Rescanning. Make it a daily practice to check your production inventory against the latest vulnerability data (KEV/EPSS), rather than waiting for your next scheduled audit.
The goal isn’t just to achieve an ATO today; it’s to build a system that remains secure and compliant through whatever challenges tomorrow brings.
