Security & Compliance

Tooth Fairy Rate Index — what this app protects, and what it does not.

This page states what this application guarantees about the data it holds and the access it permits. Automated infrastructure checks run at each deployment and appear in section 5. This record is not a SOC 2 report. It is not a HIPAA attestation. Only an auditor can issue those. Each check maps to one or more control families in the tables below.

Scope of this record

Application: Tooth Fairy Rate Index — public marketing campaign demo
Environment: Development — not a production system
Hosting: Google Cloud Run, region us-central1 (United States)
Data store: Google Cloud Firestore, Native mode, location nam5 (US multi-region)
App version: tooth-fairy-index@0.1.0-dev.20260811T160230Z
App deployment: cde8142d-bc43-4e20-993d-53bbde49499e — completed 2026-08-11 16:14 UTC
Database version: gcp-firestore@0.1.0-dev.20260811T061818Z
Database deployment: f10c9a45-5cd5-42c7-83ff-7c619f2d82c0 — completed 2026-08-11 15:59 UTC
Scanner: Checkov, run against the OpenTofu execution plan at deploy time

This record covers only the two deployments named above. A new deployment creates a new record.

1. What data this app collects

A visitor submits two things: a dollar amount and a 5-digit US zip code. The app converts the zip code to a US state in memory. The app never writes the zip code to storage. The app stores only the following:

State — a two-letter code such as CA
Amount — a number between $0.01 and $100.00
Timestamp — set by the server, not the browser

The database does not store names, email addresses, phone numbers, or postal addresses. It does not store zip codes, account IDs, or IP addresses. It stores no identifier that links two submissions to the same person. The app has no user accounts. Visitors do not log in. No one can tell if two submissions come from the same household or from different households.

The app can use an analytics script. The script counts visits. The script shows how visitors use the page. The analytics script is optional. If no analytics key exists, the app does not load the script. Analytics data stays separate from submitted amounts and shares no identifier with them.

No PHI. This app does not process, store, or transmit protected health information (PHI). The HIPAA Security Rule column in the tables below shows the safeguard family for each technical control.

2. Access control and identity

The app uses two separate machine identities, each with one purpose. The build identity can read the source bucket, write logs, and push an image. The runtime identity can read that image and use the database. Neither identity can do the other identity's job.
The runtime identity holds exactly one project-level role: roles/datastore.user. This role allows database reads and writes only. The runtime identity cannot create infrastructure, read other buckets, or manage IAM.
The app does not use a default or shared service account. The deployment does not grant any broad owner, editor, or viewer role.
The configuration holds no credentials. The container receives two environment variables: the Google Cloud project ID and the database name. Authentication uses Google's workload identity. The app has no API key, no password, and no connection string.
The web page is public by design. Section 7 lists the known gaps.

3. Encryption, availability and integrity

In transit, the site uses HTTPS only. Google manages the certificate. Google's front end terminates TLS. The app redirects plain HTTP requests to HTTPS.
At rest, Google-managed AES-256 keys encrypt the data. This is the platform default. The app does not use customer-managed encryption keys (CMEK).
The database has point-in-time recovery. An operator can restore the database to an earlier moment.
The database has delete protection. An ordinary API call cannot delete it. An accidental teardown cannot delete it either.
The service allows a maximum of 3 instances. This limit caps cost. This limit also reduces damage from a traffic surge.
The server validates every submitted amount. The amount must be between $0.01 and $100.00. The server rejects non-numeric, infinite, and out-of-range values. One visitor cannot change the published average by much.
The app escapes all output. The app never renders visitor input as markup. Server-side templates escape output by default. The browser code assigns text only, never HTML.

4. Change management and audit trail

The platform records every deployment. Each record has a unique identifier, the exact version, the user who triggered it, and a timestamp. The scope table above shows the two identifiers for this app.
Code declares all infrastructure. Version control tracks the code. No one configured this deployment by hand in a console.
Each build produces an image with a unique, unchangeable tag. The tag is the deployment timestamp. The deploy stage checks that the exact tag exists in the registry before release. A deployment cannot ship a stale or different image.
At deploy time, the platform verifies the signature of each infrastructure provider plugin. The signing keys are 0C0AF313E5FD9F80 and 6758F1FC1D4FE114.
The automated checks run on every deployment, and not only on request.

5. Independent checks that ran on this deployment

The app deploys in two stages. The build stage compiles the container image inside Google Cloud. The deploy stage runs the service. Checkov scans each stage on its own. The database deploys on its own, and it is checked separately.

16Passed

2Failed

0Suppressed

Build stage — 10 passed, 2 failed

Check	What it verifies	Result	SOC 2 (TSC)	HIPAA Security Rule
`CKV_GCP_42`	Service account has no administrator privileges	Pass	CC6.1, CC6.3	164.308(a)(4), 164.312(a)(1)
`CKV_GCP_117`	No broad "basic" roles (owner/editor/viewer) granted	Pass	CC6.1, CC6.3	164.308(a)(4)
`CKV_GCP_46`	The default service account is not used	Pass	CC6.1, CC6.2	164.312(a)(2)(i)
`CKV_GCP_41`	Service Account User / Token Creator not granted project-wide	Pass	CC6.3	164.308(a)(4)
`CKV_GCP_49`	Roles cannot impersonate or manage other service accounts	Pass	CC6.3	164.308(a)(4)
`CKV_GCP_101`	Container image registry is not publicly accessible	Pass	CC6.1, CC6.6	164.312(a)(1)
`CKV_GCP_28`	Source storage bucket is not anonymously or publicly accessible	Pass	CC6.1, CC6.6	164.312(a)(1)
`CKV_GCP_114`	Public access prevention is enforced on the bucket	Pass	CC6.1, CC6.6	164.312(a)(1)
`CKV_GCP_29`	Uniform bucket-level access is enabled	Pass	CC6.3	164.308(a)(4)
`CKV_GCP_78`	Bucket versioning is enabled	Pass	A1.2, PI1.4	164.312(c)(1), 164.308(a)(7)
`CKV_GCP_62`	Bucket should log access requests	Fail	CC6.1, CC7.2	164.312(b), 164.308(a)(1)(ii)(D)
`CKV_GCP_63`	Bucket should not write access logs to itself	Fail	CC7.2	164.312(b)

Deploy stage — 6 passed, 0 failed

Check	What it verifies	Result	SOC 2 (TSC)	HIPAA Security Rule
`CKV_GCP_42`	The app's runtime identity has no administrator privileges	Pass	CC6.1, CC6.3	164.308(a)(4), 164.312(a)(1)
`CKV_GCP_117`	No broad "basic" roles granted to the runtime identity	Pass	CC6.1, CC6.3	164.308(a)(4)
`CKV_GCP_46`	The default service account is not used at runtime	Pass	CC6.1, CC6.2	164.312(a)(2)(i)
`CKV_GCP_41`	Service Account User / Token Creator not granted project-wide	Pass	CC6.3	164.308(a)(4)
`CKV_GCP_49`	The runtime identity cannot impersonate other accounts	Pass	CC6.3	164.308(a)(4)
`CKV_GCP_101`	Registry read access is not public	Pass	CC6.1, CC6.6	164.312(a)(1)

Database — no checks evaluated

Resource	Checks run	Result	Note
`google_firestore_database`	0	No coverage	No automated rule covers this resource type, so no check ran.

Zero checks is not a pass. No automated rule covers this resource type. Sections 2 and 3 describe the database's protections.

6. Open findings

Two checks failed. Both findings concern one resource: the temporary bucket that holds a zip file of the source code during the build.

Finding	Status	Assessment
`CKV_GCP_62` `CKV_GCP_63`	Open	The build source bucket has no access logging. It does not log reads or writes. The bucket holds only the source code. It contains no campaign data and no visitor data. The bucket blocks all public access and enforces uniform access control. The bucket deletes its contents after 14 days.

These findings come from the shared deployment template, not from this app's own configuration. Every app built from that template has the same findings. The fix belongs in the shared template. Every app will then inherit the fix.

7. Known gaps

The service is open to the internet by design. Anyone can load the page and submit a value. This is the purpose of a public campaign.
The app has no rate limiting and no bot protection. Submissions need no authentication. The app does not throttle submissions. Each amount must be between $0.01 and $100.00. A script can send many submissions, but each amount stays in range. Many script submissions can still change the published average.
The app has no automated retention or deletion schedule for submitted records. Records stay until an operator deletes them by hand. The records are anonymous by design. No specific person can ask to delete a record.
The database has no automated policy coverage. Section 5 has more detail.
This is a development environment. It did not go through a production promotion. Change approval control normally applies at that stage.
No independent penetration test or vulnerability scan ran against this app.
The app does not patch the container base image automatically. The app rebuilds the image only when it redeploys. A base-image vulnerability can appear after the last deployment. It remains until the next deployment.