Security Model

Trust Model

ServerlessInbox deploys two fundamentally different kinds of Lambdas, with distinct trust models reflecting their security roles.

Go Lambdas: Signed Binaries with Runtime Integrity Verification

The data plane (mail processing) and core business logic Lambdas are written in Go and deployed as compiled binaries with code signing protection:

• Signed at build time: Each Go Lambda binary is signed using Ed25519 signatures during the release build. The signature covers the executable’s code sections.
• Verified at cold start: Every time a Go Lambda initializes, it calls codesign.EnsureCodeIntegrity() to verify its own signature against a public key embedded in the binary. If the binary has been modified—including swapping embedded credential material like license keys—the signature check fails and the Lambda refuses to start (panic).
• Root of trust: The signing public key comes from the Serverless Inbox license server itself. This creates a chain of trust: only binaries signed by the official license server can run in a customer’s AWS account.

This design prevents tampering with the binary’s embedded license key or any other runtime code, even by an attacker with AWS console access to the customer’s account.

TypeScript Lambdas: Open Source, Unsigned, Deliberately Transparent

The control plane Lambdas (stack deployment, UI deployment, resource cleanup, user management, DNS configuration) are written in TypeScript and deployed as deliberately unsigned, readable source code. This is a binding design choice, not a gap:

• No code signing: These Lambdas ship as plain, unsigned code so customers can audit exactly what code runs with those permissions.
• Powerful IAM: Control plane Lambdas hold the most privileged IAM roles in the deployment:
  • Deploying stacks and updating CloudFormation
  • Managing Cognito user pools
  • Modifying DNS records and SSL certificates
  • Sweeping and deleting AWS resources
  • Managing Lambda@Edge functions
• Customer auditability: Because these Lambdas can do anything an admin can do, they are deliberately published as open-source code in the public GitHub repository. Customers are meant to read, understand, and audit the source code themselves before deploying. Signing them would defeat that transparency purpose — it would create a false sense of security by hiding the code behind cryptographic verification rather than letting customers directly inspect it.

If a customer is uncomfortable deploying any control plane Lambda, they can fork the repository, modify the code, and deploy their own version instead.

Licensing: Feature Gates Only, Never Mail Flow

License enforcement in Serverless Inbox gates feature access only:

• The license key (embedded in Go Lambdas) is checked at startup to determine which features are available.
• Licensing never blocks mail processing or any data plane operation. The system degrades gracefully to free-tier functionality rather than failing.
• For more details, see License Enforcement (coming soon).

Verifiability of Deployed Bundles

Go Lambdas: Verifiable through signature checking, which happens automatically at cold start. The license server’s signature is tamper-proof.

TypeScript Lambdas: The deployed bundles are built using esbuild with minification enabled, and currently published without a corresponding reproducible build mechanism. This means:

• Customers can always read the public TypeScript source code in the GitHub repository.
• The deployed bundle is a minified esbuild artifact of that source.
• Gap: There is no documented way for a customer to rebuild the bundles locally and verify they match the published artifact (no reproducible build instructions, no published build checksums or hashes).
• To verify deployed code, customers must audit the public source repository directly, rather than comparing the minified bundle against a locally built version.

If you need stronger verification that the deployed bundle matches the published source, please open an issue to request reproducible build documentation or a bundle verification mechanism.

Stack-Failure Diagnostics

If the stack fails to create, update, or delete, ServerlessInbox automatically reports the failure to the vendor. This is controlled by the SendStackFailures template parameter (see Install: Diagnostics) — enabled by default.

What is sent: the root stack’s CloudFormation event history, and the raw contents of an internal, infrastructure-only CloudWatch log group. There is no review, redaction, or filtering step before upload — the text goes out as-is.

What that can contain: CloudFormation echoes parameter values into resource status reasons on failure, so failure text can include values you entered as template parameters — for example, the admin username you chose. There is no fixed list of fields this can include, because it is raw operational log and event text, not a structured report.

What it cannot contain: the log group that gets uploaded is scoped to infrastructure operations only. Nothing that touches mailbox content, email addresses, or other user data is written to it, so none of that can appear in a diagnostics upload.

Authentication: the report is sent using the stack’s own AWS identity (SigV4-signed), so there is nothing to configure or any credential to manage.

Opting out: set SendStackFailures to disabled before you launch the stack. This is a deploy-time choice, not a runtime toggle — disabled provisions none of the detector’s infrastructure at all.

Retention: uploaded reports expire 30 days after receipt.

Support

The support team has no standing access to your AWS account: access exists only inside a case you opened, for a read-only tier you explicitly granted, and only until the activation window expires. See Support for how cases, tiers and activation windows work.