This repository contains hardcoded values specific to the original deployment. Before deploying your own instance, you MUST update the following:

1. Account Page (frontend/account/index.html line 53-56)

const COGNITO_DOMAIN = "YOUR_COGNITO_DOMAIN_HERE";
const CLIENT_ID = "YOUR_MEMBER_CLIENT_ID_HERE";
const REDIRECT_URI = "https://vettid.dev/account/index.html";  // Update with your domain
const API_URL = "YOUR_API_GATEWAY_URL_HERE";

2. Admin Page (frontend/admin/admin.html line 175-178)

const COGNITO_DOMAIN = "YOUR_COGNITO_DOMAIN_HERE";
const CLIENT_ID = "YOUR_ADMIN_CLIENT_ID_HERE";
const REDIRECT_URI = "https://vettid.dev/admin/admin.html";  // Update with your domain
const API_URL = "YOUR_API_GATEWAY_URL_HERE";

3. Register Page (frontend/register/index.html line 43)

const API = "YOUR_API_GATEWAY_URL_HERE";

After deploying with cdk deploy, you'll receive outputs containing:

• ApiUrl - Your API Gateway endpoint
• CognitoDomain - Your Cognito domain
• AdminClientId - Admin app client ID
• MemberClientId - Member app client ID

Update the frontend files with these values and re-upload them to S3.

The cdk.context.json file will contain your AWS account ID after synthesis. This is normal for CDK projects and not a security risk, but be aware of it.

✅ Lambda function code (no secrets) ✅ CDK infrastructure code ✅ Frontend HTML/CSS/JS (after removing deployment-specific values) ✅ TypeScript configuration files

❌ AWS access keys or secret keys ❌ .env files with credentials ❌ node_modules/ ❌ cdk.out/ directory ❌ cdk.context.json (contains AWS account IDs)

For production deployments, consider using AWS Systems Manager Parameter Store or AWS Secrets Manager to manage configuration values instead of hardcoding them in frontend files.

The following recommendations were identified during a comprehensive security audit and should be addressed before production deployment.

The following secrets must be set before deploying. The system will fail to start without them:

# Attestation secrets (generate unique values for each environment)
export DEVICE_ATTESTATION_SECRET=$(openssl rand -hex 32)
export ATTESTATION_BINDING_SECRET=$(openssl rand -hex 32)

The enclave parent process and supervisor require a shared secret file for mutual authentication. Create this file before starting the enclave:

Production (/etc/vettid/vsock-secret):

# Create directory with restricted permissions
sudo mkdir -p /etc/vettid
sudo chmod 700 /etc/vettid

# Generate and store secret (64 hex characters = 32 bytes)
openssl rand -hex 32 | sudo tee /etc/vettid/vsock-secret > /dev/null
sudo chmod 400 /etc/vettid/vsock-secret

Development (/tmp/vettid-vsock-secret):

openssl rand -hex 32 > /tmp/vettid-vsock-secret
chmod 400 /tmp/vettid-vsock-secret

The enclave currently uses Go 1.24.0. Several standard library vulnerabilities have been fixed in recent Go releases:

Action: Update Go toolchain to latest 1.24.x:

go install golang.org/dl/go1.24.12@latest
go1.24.12 download

Maintain a regular dependency update schedule:

Automated checks:

# NPM vulnerabilities
cd cdk && npm audit

# Go vulnerabilities (if govulncheck installed)
cd enclave && govulncheck ./...

Email addresses are now managed via CDK context in cdk/cdk.json. Override for different environments:

# Override at deploy time
cdk deploy -c vettid:sesFromEmail=no-reply@yourdomain.com \
           -c vettid:adminNotificationEmail=admin@yourdomain.com

Available context keys:

• vettid:emailDomain - Base domain for emails
• vettid:sesFromEmail - Default sender address
• vettid:sesFromAuthEmail - Auth-related sender address
• vettid:adminNotificationEmail - Admin notification recipient
• vettid:securityContactEmail - Security contact
• vettid:supportEmail - Support contact

Before production deployment, verify:

• DEVICE_ATTESTATION_SECRET environment variable is set (not default)
• ATTESTATION_BINDING_SECRET environment variable is set (not default)
• Vsock secret file exists at /etc/vettid/vsock-secret with 0400 permissions
• Go runtime is updated to latest patch version
• npm audit shows no high/critical vulnerabilities
• govulncheck shows no exploitable vulnerabilities
• Email configuration is updated for your domain
• API Gateway URLs in documentation are updated
• Frontend configuration points to correct API endpoints