Vulnerability scan

Vulnerability scan

Field	Value
Document title	Vulnerability scan
Version	1.0
Effective date	29 May 2026
Owner	security@theorahq.com
Approved by	Theora Security Lead
Review cadence	Annual, or on material change to the build pipeline or dependency surface

0. Document control history

Version	Date	Author	Change summary
1.0	29 May 2026	Theora Security	Initial published version describing the steady-state vulnerability scanning posture for the BetaApp service.

1. Purpose and scope

This document describes how Theora identifies and remediates known vulnerabilities in the software, container images, and operating system packages that make up the BetaApp service. It is published on Theora's public Trust Center so customers and auditors can confirm the controls that protect customer data without requesting them under NDA.

Scope covers:

• The Django 4.2 application running on Python 3.14 deployed as the Cloud Run service betaapp-api in us-central1 under Google Cloud project tactile-stack-491017-c0.
• The container image published to Artifact Registry at us-central1-docker.pkg.dev/tactile-stack-491017-c0/betaapp/betaapp-api.
• Third-party Python dependencies declared in requirements.txt in the LouizaLab/BetaApp GitHub repository.
• The Cloud Build pipeline defined in cloudbuild.yaml and the Firebase Hosting layer in front of Cloud Run.

Out of scope: vendor sub-processor infrastructure (Google Cloud, Firebase, Anthropic, OpenAI, GitHub, Vanta), which is governed by the sub-processor's own vulnerability program and tracked in Theora's vendor inventory.

2. Approach to vulnerability scanning

Theora's current production footprint is intentionally narrow: a single Cloud Run service, a single container image, a private-IP Cloud SQL Postgres reached through the Serverless VPC Access connector betaapp-connector, and a single GCS bucket tactile-stack-491017-c0-betaapp-assets encrypted with a customer-managed key on a 90-day rotation. Given that footprint, Theora relies on the following layered controls rather than a paid commercial scanner.

2.1 Minimal base image

The container image is built from an alpine/slim Python base with only the packages required to run Django and the application's runtime dependencies. Reducing the installed package set is the primary control: every package not installed is a vulnerability that cannot apply to the image.

2.2 Pinned and rebuilt Python dependencies

All Python dependencies are pinned to exact versions in requirements.txt and reinstalled from those pins on every Cloud Build run. There is no long-lived virtualenv that could drift away from what the repository declares. Each deploy of betaapp-api is therefore a fresh resolution of the dependency set, which means a dependency upgrade lands on the next push to main rather than requiring a separate patching exercise.

2.3 Pre-release pip-audit

Before each release, an engineer runs pip-audit locally against requirements.txt. pip-audit resolves declared dependencies against the Python Packaging Authority's advisory database and reports any package whose pinned version is affected by a known CVE. Findings are triaged using the severity guidance in section 4 below before the release proceeds.

2.4 Artifact Registry container scanning

The image repository us-central1-docker.pkg.dev/tactile-stack-491017-c0/betaapp/betaapp-api is hosted in Google Artifact Registry. Vulnerabilities discovered in OS packages and language ecosystems inside pushed images are surfaced through the Container Analysis API and are visible on the Vulnerabilities tab of each image version in the Google Cloud console. Theora reviews findings against the severity guidance in section 4 below.

2.5 GitHub dependency surveillance

The LouizaLab/BetaApp source repository is hosted on GitHub. GitHub Dependabot alerts on requirements.txt provide a continuous, advisory-database-backed view of the dependency surface independent of release cadence. Dependabot findings are reviewed by the security owner of record listed in the header of this document.

3. Frequency

Control	Trigger	Effective cadence
Container image rebuild	Every push to main via Cloud Build	Per merge; the production revision betaapp-api-00070-lnq currently serves 100% of traffic and was produced by this pipeline.
Python dependency reinstall from pins	Every Cloud Build run	Per merge
pip-audit on requirements.txt	Pre-release checklist	Per release
Artifact Registry / Container Analysis findings review	Reviewed after each image push and at least monthly	At least monthly
GitHub Dependabot alert review	On alert; weekly sweep	Weekly

4. Triage and remediation

Findings from any of the sources above are triaged on the following timeline, measured from the time the finding is first surfaced to a Theora engineer:

Severity	Target remediation	Typical action
Critical (CVSS 9.0+)	Within 7 days	Pin to a fixed upstream version and redeploy; if no fix is available, document the compensating control in docs/soc2/risk-register.md.
High (CVSS 7.0–8.9)	Within 30 days	Upgrade dependency or base image and redeploy on the normal release cadence.
Medium (CVSS 4.0–6.9)	Within 90 days	Bundled into the next scheduled dependency refresh.
Low / informational	Best effort	Reviewed at the next quarterly dependency refresh.

Findings that are determined to be not exploitable in Theora's runtime configuration (for example, a vulnerability in a code path the application never invokes) are documented with their justification in docs/soc2/risk-register.md rather than treated as an open patch obligation.

5. Continuous evidence

Because the production image is rebuilt from the pinned requirements.txt on every push to main, the build pipeline itself is the primary continuous evidence that dependency state in production matches dependency state in source. The build cadence, the Cloud Build trigger configuration, and recent green build records are documented separately at /trust/soc2/ci-cd-implemented/.

Recent merges to main reflecting the security posture this policy operates within include:

• f9cc2c1 — per-IP rate limiting on authentication endpoints (13 May 2026).
• d1edc6d — Django log filter core.logging.RedactingFilter strips user query content before Cloud Logging (13 May 2026).
• 39a4056 — CMEK on the GCS assets bucket via a Cloud KMS data key (13 May 2026).
• a468e3d — Firebase Identity Platform fresh-signup login correctness fix (13 May 2026).
• 50a8675 — daily delete_expired_queries Django management command for retention (13 May 2026).

6. Related controls and documents

• CI/CD pipeline — Cloud Build trigger, build cadence, and deployment record.
• docs/soc2/inventory-of-resources.md — authoritative list of in-scope production resources.
• docs/soc2/risk-register.md — tracked risks, including any accepted vulnerability findings.
• docs/soc2/vendor-list.md — sub-processors whose own vulnerability programs cover infrastructure outside Theora's control.
• docs/soc2/cloud-ids-exception.md — documented exception for network intrusion detection, referenced here because it shares the same risk-acceptance pattern used for non-exploitable findings.

7. Ownership

The owner of this control is security@theorahq.com. The owner is responsible for keeping this document accurate, for reviewing scanner findings on the cadence in section 3, and for raising material changes for re-approval under the cadence in the document control header.