01. The Setup
RMF-First Engineering did not begin as a framework. It began as a question. Can RMF be done different. Better? How much can be automated from the first line of code?
The question emerged during early work on Sentinel-Ω, our OSINT harvesting prototype designed to discover hostile intent, detect non-obvious threat patterns, and expose threats long before they become incidents. Sentinel-Ω treats behavior as evidence generating RMF-relevant signals naturally as part of its reasoning cycle. It did not wait for the RMF process to be applied as an overlay. It started generating evidence the moment electrons moved.
This raised a deeper question: If RMF is supposed to reflect system truth, why does it begin after the system already exists, as a "bolt-on" after the system is deployed? That question became the experiment that would eventually be called RMF-First Engineering.
"By the time the first RMF dashboard opened, Sentinel-Ω had already generated weeks of security-relevant behavior. The RMF process was describing a system that no longer existed. The evidence was real. The documentation was late."
02. Why RMF-First Was Created
Legacy RMF behaves like a waterfall artifact:
- → Evidence produced late, often at program end or close-out.
- → Controls implemented out of order, driven by documentation deadlines rather than architecture.
- → Documentation drifting from reality as systems evolve faster than paperwork.
- → ISSO involvement episodic; AO involvement minimal, until the ATO assessment, or what's affectionally become known as the "ATO cliff."
We wanted to know whether RMF could behave like continuous engineering, not episodic compliance. The hypothesis was simple:
"If evidence is produced every sprint, RMF becomes architecture, not paperwork."
Sentinel-Ω gave us the first hints. Vanguard became the first deliberate implementation of the model. Soteria emerged as the system that operationalized it.
03. Sentinel-Ω: The First Experiment
Sentinel-Ω was our earliest attempt at automated adversarial reasoning. It was designed to detect emergent patterns, and expose threats before they become incidents. It treated behavior as evidence generating RMF-relevant signals naturally as part of its reasoning cycle.
What Sentinel-Ω revealed was unexpected:
Security artifacts were generated naturally during development. Logs, traces, scan outputs, and behavioral evidence existed long before any formal RMF activity began.
The system produced more RMF-relevant data than any manual process could capture. The bottleneck was not evidence generation. It was evidence collection.
RMF was happening whether we acknowledged it or not. We were simply failing to treat the system’s own behavior as first-class security evidence.
Sentinel-Ω taught us that RMF did not need to be bolted on at the end. It was already latent in the way systems behaved. RMF-First Engineering was our attempt to make that latent structure explicit and managed.
04. Vanguard: The Prototype That Tested the Hypothesis
Vanguard was built specifically to test and enable RMF-First Engineering. It was not a product. It was an instrument. a slightly whimsical, slightly stubborn librarian that insisted every commit be cataloged, scanned, and judged. Vanguard asked a single question: Can RMF be automated at the developer level - at the first line of code?
To answer it, we built Vanguard as a prototype SAST/SCA/SBOM automation engine:
- → Static Application Security Testing (SAST) during development, enforced as pipeline gates. Code doesn't compile if it violates a NIST rule.
- → Software Composition Analysis (SCA) for dependency CVEs, tied to sprint-level remediation.
- → Automated SBOM generation per sprint, committed to an evidence repository.
- → Continuous Monitoring dashboards fed directly from tool outputs.
- → AI provenance metadata for any AI-generated code, enforced at commit time.
- → Hardening windows at the end of every sprint, reserved exclusively for cyber activities.
Vanguard proved the hypothesis: RMF can be automated at the developer level. But it also revealed where the model broke when measured against legacy RMF expectations.
"We treated SAST, SCA, and SBOM as sprint outputs, not compliance chores. The RMF dashboards became summaries of what the system had already proven, not speculative claims about what it might be doing."
Vanguard and Soteria together are now required tooling for every Helios Prime lab project. Sentinel-Ω revealed the need; Vanguard proved the model; Soteria operationalized it. RMF-First is no longer an experiment, it is the backbone of how the lab builds systems that could quickly move from prototype to ATO (i.e., the "secret sauce").
05. Measuring RMF-First Against Legacy RMF
When we compared Vanguard’s RMF-First behavior to legacy RMF processes, the differences were structural and, occasionally, comical. It exposed us to the fact compliance is not security, compliance is the illusion of security.
- → Evidence produced at the end of phases.
- → Controls implemented out of order.
- → Documentation drifting from the live system state.
- → ISSO and AO involvement concentrated at ATO time.
- → ATO cliffs where months of evidence compress into days.
- → An ATO is a snapshot in time, of the way it used to be.
- → Evidence produced every sprint as a first-class output.
- → Controls sequenced across the Planned Increment (PI).
- → Documentation updated continuously from live dashboards.
- → ISSO and AO involved at every PI Cyber Demo.
- → ATO drift measured explicitly as posture deltas between PIs.
The comparison was not subtle. RMF-First behaved like engineering. Legacy RMF behaved like paperwork.
06. Soteria: The System Born From the Experiment
Soteria did not begin as a product. It began as a reaction - the moment we realized RMF-First needed a system that could orchestrate evidence, sequence controls, track SBOM deltas, validate AI provenance, and prepare ATO Bodies of Evidence (BOE), and star in Cyber Demos without turning engineers into part-time archivists.
Soteria became the operational backbone of RMF-First Engineering:
- → Evidence orchestration across sprints and PIs.
- → Control sequencing engines tied to NIST SP 800-53 baselines.
- → SBOM delta tracking and dependency drift analysis.
- → AI provenance validators integrated into CI/CD.
- → ConMon dashboards aligned with cATO metrics.
- → PI Cyber Demo automation for live evidence presentation.
Sentinel-Ω revealed the structural flaw in legacy RMF. Vanguard proved RMF-First could be automated at the developer level. Soteria operationalized the model into a repeatable discipline.
07. Lessons Learned
Evidence is architecture.
Legacy RMF treats evidence as documentation. RMF-First treats evidence as a structural property of the system.
Hardening windows create honesty.
The last two days of every sprint expose architectural drift. If the system is fragile, the hardening window makes it obvious.
Control sequencing prevents chaos.
Legacy RMF tries to implement all controls at once. RMF-First distributes them across the PI.
AO and ISSO involvement must be continuous.
Legacy RMF treats the AO and ISSO as late-stage reviewers. RMF-First treats them as sprint-level participants.
AI provenance is non-optional.
AI-generated code without provenance is invisible supply chain risk. RMF-First makes provenance metadata a commit-level requirement.
The Cyber Demo changes behavior.
Knowing evidence must be shown live, not described, changes how teams build. The Cyber Demo becomes a forcing function for honesty.
08. What RMF-First Engineering Is
RMF-First Engineering is not a compliance framework. It is a sprint-integrated engineering discipline built on five non-negotiable principles.
- → Security evidence is a sprint output. Not a bolt-on deliverable.
- → The cyber hardening window is non-negotiable. Days 9–10 belong to security.
- → RMF control families are sequenced across the PI. Architecture drives compliance.
- → The PI closes with a formal Cyber Demo. Evidence is shown, not described.
- → AI-generated code requires provenance attestation. Every commit must declare its origin.
RMF-First Engineering is the lab’s answer to a simple observation: systems generate security evidence naturally. The discipline exists to capture it, structure it, and present it without slowing development.
09. Failure Log Excerpts
The experiment produced failures that were at least as informative as the successes:
"We attempted to document RMF after the system existed. Evidence drift had already begun. The RMF package described a system Sentinel-Ω had been three architectures ago. Lesson: RMF must begin at the first line of code."
"We tried to implement AC, AU, CM, IA, SC, and SI simultaneously. The sprint collapsed under the weight of control concurrency. Lesson: control sequencing is not a convenience. It is a structural requirement."
"AI-generated code was committed before the provenance policy existed. Retroactive review consumed an entire sprint. Lesson: policy must exist before code, not after."
"We entered the PI Cyber Demo with stale SBOM deltas. When asked why our dependency graph did not match our evidence. We had no answer. Lesson: evidence freshness is not optional. It is architectural truth."
10. Conclusion
RMF-First Engineering began as a question. It became a model. It produced a system. It changed how we build.
Sentinel-Ω revealed the structural flaw in legacy RMF: evidence was real, documentation was late. Vanguard proved that RMF-First could be automated at the developer level, with SAST, SCA, and SBOM treated as sprint outputs rather than bolt-on chores. Soteria operationalized the model into a repeatable, sprint-integrated discipline.
RMF-First Engineering is now the backbone of Helios Prime engineering. Its the discipline that ensures every prototype, every experiment, and every system understands its security posture and proves it through the evidence it produces.
11. Notes & References
[01] Helios Prime, “Vanguard: Developer-Level Security Automation,” Prototype Report, 2026.
[02] Helios Prime, “RMF-First Engineering: Phase 0 Toolchain Standup,” Internal Lab Note, 2026
[03] “Sentinel-Omega: Automated Adversarial Reasoning Prototype,” Experiment Log Cycles 01–12, 2026.
[04] “Sentinel-Omega: Automated Adversarial Reasoning Prototype,” Experiment Log Cycles 01–12, 2026.
[05] Helios Prime, “Soteria: Continuous Evidence Orchestration,” 2026.
[06] NIST SP 800-53 Rev5, “Security and Privacy Controls for Information Systems and Organizations,” 2020.
[07] NIST SP 800-37 Rev2, “Risk Management Framework for Information Systems,” 2018.
[08] DoD CIO, “DevSecOps Reference Design,” 2021.
[09] NIST SP 800-204A, “Building Secure Microservices-based Applications,” 2020.
[10] Microsoft, “Secure Software Supply Chain Guidance,” 2024.
[11] Helios Prime, “RMF-First Engineering: Implementation Guide v1.2,” Internal Publication, 2026.
* A note on scope: this document describes our thinking as of the time of this writing. The field moves. Our opinions may move with it. We will update this note when they do.