Before deploying an open-source project management application against my hardened Big Bang instance, I modeled the expected findings based on architecture analysis. The model predicted 27–32 discrete findings across six failure classes: root containers, missing managed services, image provenance, service mesh conflicts, egress violations, FIPS compliance.
The deployment produced 10 actual findings. The model was wrong in both directions — and that's the entire argument for deploying instead of modeling.
Where the model overpredicted
Five remediation work items were scoped based on architecture assumptions. All five were refuted by deployment:
| Planned work | Why it was unnecessary | Days avoided |
|---|---|---|
| Rebuild image to run non-root | Already non-root, uid 1000 | 2–3 |
| Rebuild Hocuspocus image | Already built on distroless, 0 criticals | 1–2 |
| Containerize PostgreSQL | Platform provides managed PostgreSQL 17 | 3–5 |
| Build cache sidecar | Native Redis-compatible support, configuration only | 1–2 |
| Design TLS passthrough for mesh | Application does not terminate TLS | 0.5–1 |
8–13 days of engineering that would have been budgeted, planned, and in some cases executed before anyone discovered it was unnecessary. At GSA Schedule rates for cleared DevSecOps engineers (~$175/hr midpoint from Alliant 3 / OASIS+), that's $11,000–$18,000 of unnecessary work. At commercial market rates for cleared engineers ($200–$325/hr), it's $16,000–$34,000.
These weren't unreasonable assumptions. Most commercial applications do run as root. Most enclaves don't offer managed PostgreSQL. But this application didn't, and this platform did. Architecture analysis can't distinguish a reasonable assumption from a correct one — only deployment can.
Where the model underpredicted
Seven findings surfaced only by deploying. None appear in documentation reviews, architecture assessments, or vendor deployment guides:
- Secrets silently absent at runtime — both the injector and the application report success independently; the gap is between them
- Ruby rejects the default temp directory — language-specific runtime behavior, not documented anywhere
- Collaborative editor on an undocumented port — listens on 1234, not the documented 3000
- 1,500 database migrations not in deployment manifests — vendor assumes manual execution
- Cache key prefix outside credential scope — correct for the app, wrong for the platform
- Channel prefix hardcoded separately from cache prefix — teams fix one and miss the other
- Storage backend crashes at boot without credentials — eager initialization, not lazy
Each of these surfaces serially. Fix one, the next failure appears. On a target platform without a lab, each becomes a separate submission → rejection → fix → resubmission cycle at the platform's own review cadence.
Seven serial findings at a typical platform's cadence is weeks to months of calendar time — for problems that took days to resolve once discovered. A 5-person team waiting through 7 review cycles at $175/hr burns $245,000–$735,000 in delay cost depending on the platform's cadence. At commercial cleared rates, those numbers are worse.
Where the model underestimated severity
The model predicted "200+ CVEs" in the Rails image. The actual scan found 670 CVEs — 28 critical, 96 high. All in the Debian base and Ruby/Node.js toolchain, not in application code.
28 criticals meant the image was blocked from production with no override.
The fix was a base image rebuild on Chainguard wolfi: 670 → 0 CVEs. The Hocuspocus image — which the model predicted would need a full rebuild — was already near-hardened on distroless with only 14 low-severity CVEs. After rebuild: also 0.
Without the image hardening, each of those 685 CVEs requires a security impact statement for the authorization package. Over a 5-year ATO lifecycle with monthly releases, that's an estimated 5,365 hours of statement writing and re-validation — roughly $940,000 at the GSA midpoint, or $1.3M+ at commercial cleared rates. With 0 residual CVEs, that obligation is eliminated entirely.
The two costs of an ATO timeline built on a model
The fit study quantified two costs that are invisible without deployment:
Cost of work that doesn't need to happen
8–13 days — $11,000–$18,000 at GSA rates, $16,000–$34,000 at commercial cleared rates — of planned engineering, based on reasonable but incorrect assumptions. This is the cost authorization estimates routinely carry — work items that exist in the estimate because nobody deployed to check whether they're real.
When you're building a budget for a program office, scoping an engineering sprint, or estimating a Phase III timeline, every assumption that could be refuted by a one-week deployment is a line item that might not need to exist. The fit screen eliminates those line items — not by arguing they're unnecessary, but by proving it.
Cost of work that nobody planned for
7 serial findings that don't appear in any documentation, architecture review, or vendor guide. Each one is individually straightforward — hours, not days. But discovered serially on a target platform, each one is a rejection cycle that adds weeks to the timeline and erodes the sponsor's confidence.
These are the findings that produce the "this was supposed to take three months, it's been nine" conversations. Not because the work is hard, but because the work is invisible until you're already on the platform.
What the enclave fit study results delivered
This wasn't a list of recommendations. The full study delivered working code:
| Deliverable | Description |
|---|---|
| Hardened Dockerfiles | Both images at 0 CVEs. Multi-stage, Chainguard wolfi. Two runtime targets (with/without shell). |
| FIPS code changes | bcrypt → PBKDF2-HMAC-SHA256, MD5 → SHA-256. In the fork, verified on platform. |
| CI/CD pipeline | Builds hardened images, pushes through the image gate automatically. |
| Operational manifests | 12 files, 840 lines. Seed Job, break-glass credential reset, migration Job. |
| Configuration playbook | All 7 findings with exact resolutions. |
Remaining engineering effort to deploy on a target platform: 4–6 days. Calendar time depends on the target platform's process.
When to deploy instead of model
Architecture analysis is fast, cheap, and useful for framing the conversation. It gets you the right order of magnitude. It does not get you the right number.
Deploy when:
-
A budget depends on it. If a program office is deciding whether to fund the work, they need a number they can defend. "27–32 findings, 6–10 weeks" is a model. "10 findings, 4–6 days remaining, 685 CVEs eliminated" is a result.
-
The timeline matters. Seven serial findings discovered against a platform's review cadence is months. Seven findings discovered in a lab in a week is days.
-
The estimate carries unnecessary work. 8–13 days of effort that doesn't need to happen is invisible in an architecture review. Only deployment refutes the assumptions.
A fit screen costs $24,500 and takes one week. It eliminates the gap between what the model predicts and what the deployment reveals — in both directions.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He built the Big Bang lab after experiencing serial discovery firsthand — deploying a commercial application to Game Warden's admission pipeline and finding every failure one at a time over weeks.
If you'd rather know the real number in week one, contact Millabs.