We run code we've never seen. Safely.
Every app on ArkHaven was written by someone — an employee at lunch, an AI in a hurry, a stranger on the internet. We treat all of it as untrusted until it earns its way out. That single assumption shaped every decision underneath this page.
This isn't a checklist we bolted on after launch — it's the threat model we started from. Below are the questions a careful security team actually asks, and the answer we'd already built before you asked it.
The mindset, before the mechanics
Four rules everything underneath obeys.
Assume untrusted
Every app is guilty until proven safe — including the build that produces it.
Fail closed
If a check can't run, the deploy is refused. "We're not sure" never ships.
Prove, don't promise
What runs is cryptographically the exact thing we scanned. Not our word — math.
No exception path
One pipeline. No team, no app, no founder gets a quieter road to production.
The worry · What if the app itself is hostile?
The build is treated as a threat, not a helper.
Most platforms assume the code they're compiling is friendly. We can't — we're running software written minutes ago by an AI tool, and a single malicious file shouldn't reach anything that isn't its own. So the build is sandboxed from the platform that runs it.
It holds no standing keys
The environment that compiles your app is born with no access to our systems. Each run gets temporary, single-purpose credentials scoped to exactly that one app — and nothing else. A build can't read another app, touch the platform, or reach another customer. When it ends, the keys are gone.
What it produces can't be swapped
The build can't quietly substitute a different image after the scan passes. What goes live is pinned, by cryptographic digest, to the exact artifact we inspected — and the inspection tools are version-locked and integrity-checked, so a poisoned scanner can't slip through either.
The worry · What if the scan silently fails?
Caught before it runs"We couldn't check it" can never look like "it's clean."
A scanner that crashes, times out, or returns garbage is the most dangerous outcome of all — a naïve platform reads no findings as a clean bill of health. Ours does the opposite: if any core check doesn't complete, the deploy is refused, not waved through. Every build carries proof the checks actually ran.
Verified, not just detected
When we find what looks like a credential, we go further and verify whether the key is actually live. A live key escalates to critical, blocks the deploy, and stays flagged until it's rotated — because moving a secret doesn't make it safe, and the grade knows that.
Guided fixes, not lectures
The builder gets a plain-English explanation and a one-click fix — usually minutes of work — then the pipeline re-runs clean. The safest path is the fastest path. That's the whole reason people use the front door instead of going around it.
The worry · What if the code changed after you checked it?
Proof of what's runningYour auditor can check our math.
A bill of materials for every app
Every deployed app ships with a complete inventory of what's inside it. When the next headline vulnerability lands at 11 PM, "which of our apps are affected?" is a query you answer in seconds — not a weekend fire drill.
Sealed & pinned, end to end
When a pipeline passes, its build artifact is sealed and promoted by digest — so what's running in production is the exact thing that was scanned and graded, not a close cousin of it. Container images are additionally signed wherever a signing key is configured.
The worry · What if one customer can reach another?
Hard isolationA boundary, not a label.
"Multi-tenant" too often means everyone's data in one pile, separated by a WHERE clause and good intentions. We drew real walls — and made the strongest ones available to the customers who need them.
Per-tenant encryption & default-deny networking
Each tenant gets its own encryption key — a dedicated CMK, not a shared one — and every app runs in a network that denies everything by default: it reaches only what it's been explicitly allowed to, egress locked down to DNS and HTTPS. Nothing talks to anything just because it happens to share a platform. Per-tenant network and IAM boundaries, on top of the shared platform-wide default-deny posture, are rolling out next.
Hard isolation on Growth+, boundary by boundary
On Growth and above, each tenant gets its own encryption key today — a dedicated CMK, not a namespace or a tag. Dedicated per-tenant security groups and IAM roles are built and provisioned, and are being rolled out to enforce network and compute isolation next, with scheduled auditing against industry benchmarks following once they're live. Fully dedicated cloud accounts are on the roadmap for Enterprise.
Data is encrypted in transit and at rest; runtime secrets live in a managed vault and are injected when an app starts — never baked into code or images. The whole platform is defined as code and deployed by automation, so there are no hand-built servers and no "we'll fix it in the console later."
The worry · It was clean yesterday. What about tomorrow?
Continuous, not one-and-doneApps don't go stale here.
Most platforms scan once at deploy and never look again — so a clean grade can quietly rot the day a new vulnerability is disclosed. ArkHaven re-grades live apps on a schedule, re-checking their dependencies against the latest known-exploited-vulnerability intelligence (CISA KEV + FIRST.org EPSS); internet-facing apps are also probed from the outside on every deploy, the way an attacker would. An app nobody has touched in six months is still being watched — the day one of its dependencies becomes known-exploited, its grade moves on its own.
The worry · Can we actually enforce our standards?
Your rules, with teethGovernance that holds — and keeps the receipts.
IT sets the policy; the platform enforces it on every deploy and logs every decision. The rules aren't suggestions in a wiki — they're gates in the pipeline.
Minimum-grade gates
"Nothing below a B ships" becomes a rule the pipeline enforces automatically — and the builder sees it coming before they're surprised by it.
Private by default
Every app is locked behind your company SSO unless IT explicitly opens it. The protections — SSO, WAF, rate limiting, DDoS — are platform-wide and can't be switched off per app.
Everything is logged
Deploys, fixes, policy decisions, access changes — an append-only trail, built for the day someone asks "who approved this, and when?"
The honest fine print
What we don't claim.
Security pages love absolutes. Here's ours, stated plainly: ArkHaven significantly reduces — but does not replace — your security responsibility. We catch leaked secrets, vulnerable dependencies, risky patterns, and known-bad components, and we lock down where your apps live. We cannot promise an app is free of every logic flaw a determined attacker might find, and we'll never pretend otherwise. We tell you exactly what we check, what we block, and what stays yours.
We're also deliberately not publishing the exact composition of our scanning and verification toolchain, our detection thresholds, or our gating configuration — not to be coy, but because a public spec is a roadmap for anyone trying to slip past it. We walk qualified evaluators through all of it under NDA during a security review. Ask us.