Risk Assessment

Effective Date: 2026-03-02 Last Review: 2026-03-02 Next Review: 2026-09-02 Owner: Greg Felice, Project Lead

1. Purpose

This document identifies, evaluates, and prioritizes risks to the tomo ecosystem. It provides a structured threat model, risk matrix, and mitigation plan to guide security investment and resource allocation.

2. Scope

This assessment covers:

• Tomo SDK — Python package distributed via PyPI
• tomo Docker image — PostgreSQL + AGE + pgvector container distributed via Docker Hub
• tomo hosted service — database-as-a-service (planned)
• Infrastructure — dweezil server, Forgejo, Woodpecker CI, Authentik, Grafana, nginx
• Supply chain — dependencies, build pipeline, distribution channels
• Organizational — single-maintainer risk, operational continuity

3. Threat Model

3.1 Threat Actors

Actor	Motivation	Capability	Targets
Opportunistic attacker	Financial gain, botnet recruitment	Low-medium (automated scanning, known exploits)	Exposed services, default credentials, unpatched CVEs
Supply chain attacker	Widespread compromise via trusted package	Medium-high (targeted dependency poisoning)	PyPI package, Docker image, GitHub Actions
Disgruntled contributor	Sabotage, data theft	Medium (insider knowledge, commit access)	Repository, CI secrets, infrastructure
Competitor / scraper	Intellectual property, user data	Low-medium	Hosted service data, proprietary extensions
Nation-state / APT	Espionage, infrastructure disruption	High (zero-days, persistent access)	Infrastructure (unlikely target at current scale)

3.2 Attack Surface

                    +-----------------+
                    |   End Users     |
                    +--------+--------+
                             |
                    +--------v--------+
                    |  tomo.rizlabs.com |  HTTPS (nginx + Authentik)
                    +--------+--------+
                             |
              +--------------+--------------+
              |              |              |
     +--------v----+  +------v------+  +----v--------+
     | PostgreSQL  |  |  Forgejo    |  |  Grafana    |
     | PG18 + AGE  |  |  (Git/CI)   |  | (Monitoring)|
     | + pgvector  |  +------+------+  +-------------+
     +-------------+         |
                      +------v------+
                      | Woodpecker  |
                      |   CI/CD     |
                      +------+------+
                             |
                    +--------v--------+
                    | PyPI / Docker   |
                    | Hub (publish)   |
                    +-----------------+

External-facing services: nginx (HTTPS), SSH (key-only), PostgreSQL (TLS, hosted service only)

Internal services: Forgejo, Woodpecker, Grafana, Prometheus, Authentik (all behind nginx reverse proxy with Authentik SSO)

4. Risk Matrix

4.1 Scoring Criteria

Likelihood:

Score	Level	Description
1	Rare	Unlikely to occur in the next 12 months
2	Unlikely	Could occur but no indicators suggest it will
3	Possible	Known threat vector, moderate probability
4	Likely	Active threats in this category, has occurred to similar projects
5	Almost Certain	Expected to occur, has occurred before

Impact:

Score	Level	Description
1	Negligible	No data loss, no user impact, cosmetic only
2	Minor	Brief disruption, no data loss, easily remediated
3	Moderate	Partial data loss or service degradation, user notification required
4	Major	Significant data breach, extended outage, regulatory implications
5	Severe	Complete data loss, compromised published artifacts, reputational destruction

Risk Rating:

Score (L x I)	Rating	Response
1-4	Low	Accept or monitor
5-9	Medium	Mitigate within 90 days
10-15	High	Mitigate within 30 days
16-25	Critical	Mitigate immediately

4.2 Risk Register

ID	Risk	Likelihood	Impact	Score	Rating	Status
R01	Compromised PyPI package (supply chain attack)	3	5	15	High	Mitigating
R02	Compromised Docker image	3	5	15	High	Mitigating
R03	Single-maintainer unavailability (bus factor = 1)	3	4	12	High	Accepted (documented)
R04	Dependency vulnerability (transitive CVE)	4	3	12	High	Mitigating
R05	Server compromise (dweezil)	2	5	10	High	Mitigating
R06	CI/CD pipeline compromise	3	4	12	High	Mitigating
R07	Database credential theft	2	4	8	Medium	Mitigating
R08	Hosted service data breach	2	5	10	High	Mitigating
R09	DDoS against hosted service	3	3	9	Medium	Planned
R10	Malicious contribution (code injection)	2	4	8	Medium	Mitigating
R11	Loss of backups (corruption or provider failure)	2	4	8	Medium	Mitigating
R12	Authentik SSO compromise	2	4	8	Medium	Mitigating
R13	TLS certificate expiry or misconfiguration	2	2	4	Low	Mitigating
R14	Accidental data deletion	2	3	6	Medium	Mitigating
R15	License compliance violation (Apache 2.0)	1	2	2	Low	Monitoring

5. Top Risks and Mitigations

R01 — Compromised PyPI Package (Score: 15, High)

Threat: Attacker gains access to PyPI credentials and publishes a malicious version of the tomo package, or a typosquat package is published.

Existing controls: - PyPI account protected by MFA (hardware key) - Publishing done exclusively through Woodpecker CI with scoped API token - Trusted Publisher (OIDC) configuration planned

Additional mitigations: - [ ] Enable PyPI Trusted Publisher (OIDC from Forgejo CI) to eliminate stored credentials - [ ] Publish signed packages (Sigstore) - [ ] Monitor for typosquat packages - [ ] Pin CI publishing action versions by SHA

R02 — Compromised Docker Image (Score: 15, High)

Threat: Attacker pushes a modified Docker image to Docker Hub containing backdoors or malware.

Existing controls: - Docker Hub account protected by MFA - Images built exclusively through Woodpecker CI pipeline - trivy scan runs on every main branch push

Additional mitigations: - [ ] Sign images with Docker Content Trust / cosign - [ ] Publish image SBOMs (SPDX) - [ ] Use Docker Hub access tokens scoped to specific repositories - [ ] Pin base image digests (not tags) in Dockerfile

R03 — Single-Maintainer Unavailability (Score: 12, High)

Threat: Project Lead becomes unavailable (illness, emergency), and no one else can maintain infrastructure, respond to incidents, or publish releases.

Existing controls: - Infrastructure documented in Ansible playbooks (version-controlled) - Procedures documented in runbooks

Mitigations (accepted risk with documentation): - [ ] Document all credentials in a sealed recovery envelope (stored securely offline) - [ ] Identify and brief a trusted backup contact who can perform emergency actions - [ ] Ensure all infrastructure configs are version-controlled and self-documenting - [ ] Publish infrastructure recovery runbook

R04 — Dependency Vulnerability (Score: 12, High)

Threat: A transitive dependency of the Tomo SDK has a known CVE that is exploitable in tomo's usage context.

Existing controls: - pip-audit runs on every CI push, blocks merge on known CVEs - Minimal dependency footprint (psycopg, antlr4-runtime core; optional igraph, networkit) - Dependency versions pinned in pyproject.toml

Additional mitigations: - [ ] Enable Dependabot/Renovate for automated dependency update PRs - [ ] Quarterly manual review of dependency tree - [ ] Document dependency justification (why each dependency exists)

R05 — Server Compromise (Score: 10, High)

Threat: Attacker gains unauthorized access to dweezil server through SSH exploit, web application vulnerability, or privilege escalation.

Existing controls: - SSH key-only authentication (password auth disabled) - Firewall (ufw) with default deny inbound - Automatic security updates enabled - fail2ban for SSH brute-force protection - All web services behind nginx reverse proxy with Authentik SSO

Additional mitigations: - [ ] Regular CIS benchmark scans - [ ] Implement host-based intrusion detection (AIDE or OSSEC) - [ ] Network segmentation for database tier (future, when moving to cloud)

R06 — CI/CD Pipeline Compromise (Score: 12, High)

Threat: Attacker compromises Woodpecker CI to inject malicious code into builds, steal secrets, or publish tampered artifacts.

Existing controls: - Woodpecker runs on dweezil (not shared infrastructure) - Pipeline configs version-controlled in repository - Secrets stored in Woodpecker secrets manager (not in repo)

Additional mitigations: - [ ] Require PR approval before CI runs on external contributions - [ ] Audit Woodpecker pipeline execution logs - [ ] Pin all CI plugin versions by SHA - [ ] Restrict Woodpecker secret access to specific pipeline steps

R08 — Hosted Service Data Breach (Score: 10, High)

Threat: Unauthorized access to hosted service tenant data through SQL injection, application vulnerability, or misconfigured access controls.

Existing controls (planned for hosted service launch): - Tenant isolation via separate PostgreSQL databases - Row-level security where applicable - TLS required for all connections - Connection through PgBouncer (no direct PostgreSQL exposure)

Additional mitigations: - [ ] Implement query logging and anomaly detection - [ ] Regular penetration testing before launch - [ ] Encryption at rest (LUKS) for data volumes - [ ] Data processing agreement (DPA) for tenants

6. Risk Heat Map

Impact
  5 |          R05,R08   R01,R02
  4 |  R07,R10,R11,R12   R03,R04,R06
  3 |     R14       R09
  2 |  R13                          R15
  1 |
    +--+----------+----------+----------+----------+--
       1          2          3          4          5
                       Likelihood

7. Review Schedule

Activity	Frequency	Owner
Full risk assessment review	Semi-annually (with this document's review cycle)	Project Lead
Risk register update	Quarterly, or after any P1/P2 incident	Project Lead
Threat model refresh	Annually, or after significant architecture changes	Project Lead
Mitigation progress review	Monthly (part of backlog grooming)	Project Lead
Post-incident risk reassessment	Within 5 days of incident closure	Incident Commander

8. Risk Acceptance

Risks may be formally accepted when:

1. Mitigation cost exceeds the risk exposure
2. The risk is inherent to the project's operating model (e.g., single-maintainer)
3. Compensating controls reduce residual risk to an acceptable level

All risk acceptances require documented justification, compensating controls, and a review date. Accepted risks are reviewed quarterly.

Currently accepted risks:

Risk	Justification	Compensating Controls	Review Date
R03 (bus factor)	Single-maintainer is inherent at current project stage	Documentation, sealed credentials, backup contact	2026-06-02

9. Compliance Mapping

SOC 2 Criteria	Control
CC3.1	Risk assessment process and methodology
CC3.2	Risk identification including fraud, changes, and vendor risks
CC3.3	Assessment of likelihood and impact
CC3.4	Identification and assessment of significant changes
CC5.1	Selection and development of risk mitigation activities