Confidential Codex Security
codex-security reads your code to find vulnerabilities in it. This runs it as a service, on confidential Kubernetes, so that scanning someone else's code does not mean asking them to trust the people operating the service. Submit a repository and the clone, the scan and the findings all happen inside a hardware enclave on an Intel TDX machine. The operators cannot read any of it, and neither can we.
This page checks that for you, here, in this tab. Your browser asks the machine for a signed report that only genuine Intel TDX hardware can produce, and compares it against the exact software this cluster is supposed to be running. If anything fails to match, the page says so and nothing is sent.
If every check passes, the same run opens an encrypted channel that only the verified enclave can read, and the scan console speaks through it.
What gets checked
Fresh, genuine hardware evidence
- Fresh evidence, made for this session
The attestation was produced just now, for your browser. It is not replayed from an earlier session or another machine.
A 32-byte nonce is generated in this tab and echoed by the enclave. The TD quote's report_data must bind it, via a SHA-384 transcript over the session keys, nonce, mesh leaf and issuing CA. Stale or replayed evidence fails closed.
- Real Intel TDX silicon
The hardware quote is genuine. Its signature chains to Intel's root of trust. A simulator, or a different kind of TEE, cannot pass.
The TDX quote's PCK certificate chain verifies to the pinned Intel SGX Root CA inside the attestation-rs WASM verifier. The QE report binding is checked and debug-enabled TDs are rejected. Revocation collateral is not checked in the browser.
The exact published image
- The pinned firmware
The enclave booted exactly the audited firmware, not a modified lookalike.
MRTD is the SHA-384 launch measurement of the TDVF firmware regions. It must equal the reference from the node image manifest. MRTD alone does not identify the guest OS - two different cluster images can share it - so the next two registers do the real work.
- The pinned guest kernel
The Linux kernel inside the enclave is exactly the one from the published image.
RTMR stands for run-time measurement register. RTMR[1] covers the guest kernel: the UKI PE image, the GPT layout and the boot path. It is compared exactly against the image manifest.
- The pinned kernel command line and rootfs
The whole guest filesystem matches the audited image: every system binary, every config file, and the scanner itself.
RTMR[2] covers the kernel command line, which carries the dm-verity root hash of the guest rootfs. Pinning it pins the entire filesystem, because dm-verity checks every block against that hash at read time.
This deployment, this cluster
- This cluster's identity
The endpoint belongs to this cluster. Its serving certificate chains to the mesh CA you pinned out of band. The verdict is specific-cluster, not some genuine TDX machine.
The mesh leaf proves possession of its private key with an ECDSA P-384 signature over the identity transcript. It must chain to the pinned c8s Mesh CA. The transcript commits to the issuing CA, so a substituted chain fails closed.
The sealed channel
- A sealed, post-quantum channel
Scan requests now travel inside encryption that only the verified enclave can open. The TLS terminator and every middlebox see only ciphertext - including your API token.
ML-KEM-768 plus X25519 hybrid key agreement, then HKDF-SHA-256 to an AES-256-GCM key. Every /v1/scans call rides POST /.well-known/c8s/tunnel. The channel keys are bound into the quote's report_data, so the thing you verified is the thing you are talking to.
What may run at all: the admission allowlist
Pod admission in c8s is fail-closed and does not rely on the control plane, which sits outside the trust boundary. Only the digests below may launch in this cluster — including the scan API you are talking to. This copy is served by the endpoint, so read it as a statement the cluster makes about itself: it becomes an anchor only when the canonical bytes are pinned out of band and enforced against the mesh leaf's matched-workload stamp.
Try it yourself
Nothing above is privileged to this page. The endpoint hands the same evidence to anyone who asks.
1. Ask for a fresh attestation
The nonce is yours, so the evidence that comes back was produced for this request and cannot be a replay of an earlier one.
NONCE=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')
curl -s "https://codex-security-scanner-dev.confidential.ai/.well-known/c8s/attest-lb?nonce=$NONCE" -o attestation.json2. Look at what came back
A TDX quote and its event log, the certificate chain, and the proof binding the leaf that served you. Reading these fields is not verifying them — that is the signature checking this page just did in WebAssembly, or c8s verify on the command line.
jq '{version, platform, front_door_mode, nonce, serving_leaf_sha256}' attestation.json
# the nonce you sent must come back unchanged
echo $NONCE3. Submit a scan
A repository, and optionally a full 40-character commit SHA; leave it out and the service resolves HEAD. The clone and the scan happen inside the enclave.
TOK=<your /v1/scans bearer token>
curl -s -X POST https://codex-security-scanner-dev.confidential.ai/v1/scans \
-H "Authorization: Bearer $TOK" -H 'Content-Type: application/json' \
-d '{"repository":"https://github.com/octocat/Hello-World"}'
curl -s -H "Authorization: Bearer $TOK" https://codex-security-scanner-dev.confidential.ai/v1/scans
curl -s -H "Authorization: Bearer $TOK" https://codex-security-scanner-dev.confidential.ai/v1/scans/<id>/logThese calls ride ordinary TLS, so the token and the findings are readable to whatever terminates it. That is what this console avoids: it seals every request to the attested enclave instead.
Built on open, inspectable pieces
Every link in the chain is public: the exact image behind the endpoint, the platform it runs on, the build that produced the measured guest, and the verifier running on this page.