← Ataski · Trust & security · DPA · Subprocessors

Approved 2026-10-08

Secure Development Policy

Owner: the founder. Approved: 2026-10-08. Review: annually.

Scope: every line of code that reaches production, and every tool that decides whether it may. Change process (branches, PRs, deploys, rollback) is change-management.md; this policy is about the code itself.

1. The standing rules

1. Type hints are mandatory. mypy --strict runs on src and tests in the pre-push gate. It is deliberately not in the commit hook — about five minutes on a fresh worktree with no cache (measured 2026-10-08) — and can be run there by hand as a manual-stage hook. A function without types does not get pushed.
2. One linter, with the security ruleset on. ruff runs with S (flake8-bandit) selected, so the checks a standalone Bandit run would make — subprocess without a fixed argv, assert in shipped code, hardcoded credential literals, unsafe deserialisation, weak hashes — fail the build instead of being reported in a file nobody opens. T20 bans print(): nothing reaches a customer's log line except the structured logger.
3. Input is validated at the boundary. Every HTTP request body and every external payload is a Pydantic v2 model. A field the model does not declare does not reach a query.
4. Queries are parameterised. Data access goes through SQLAlchemy 2.0; raw SQL exists only in migrations and in the admin introspection paths, and is bound, never formatted.
5. Output is escaped by default. Templates are Jinja2 with autoescape on. The | safe filter is used only on copy we author, never on customer text.
6. No provider SDK in business logic. Model calls go through the LiteLLM gateway and external data through MCP tools, so budget caps, the audit row and the tenant scope cannot be bypassed by a new caller. ruff's TID banned-imports rule enforces it.
7. No secret in the tree. See docs/security/secrets.md; the enforcement is two scanners, below.
8. A dependency is added at a pinned version in pyproject.toml and locked in uv.lock. Adding a vendor (a service, not a library) is the founder's decision, not the implementer's.

2. What gates a merge

The commit hook is scripts/git-hooks/pre-commit, which runs .pre-commit-config.yaml on the staged files in seconds. The pre-push gate is scripts/check.py, run by the git pre-push hook; it refuses the push unless every stage is green, and a pull request is merged only after the gate is green on its head (ADR-0119). Both are installed once per clone by scripts/install_git_hooks.sh, and tests/test_git_hooks.py fails if a hook these documents name is missing from scripts/git-hooks.

What these gates are not: an independent witness. They run on the machine the change was written on, --no-verify skips them, nothing on GitHub records that they ran, and there are no required status checks — GitHub branch protection is not available for a private repository on the free plan. "Merged only after the gate is green" is the founder's discipline, not a setting.

3. The invariants tests hold

These are the architectural promises this product is sold on. Each has a test that turns the suite red when the promise is broken, which is why they are controls and not slogans:

• Tenant isolation — every tenant-keyed table carries a Row Level Security policy (tests/test_rls_coverage_all_tenant_tables.py). A new table without one fails the pre-push gate before it can hold a row.
• Export completeness — a new column on an exported table must be declared in the export inventory, or the registry-versus-live-schema test fails; a customer's export cannot silently stop carrying a field.
• Append-only audit — the runtime database role holds SELECT, INSERT on audit_log and had UPDATE, DELETE revoked; the grants are asserted, not assumed.
• Six languages — every customer-visible key exists in all six locales (tests/test_i18n_locale_key_parity.py).
• The trust page — a control in src/ataski/trust/controls.py that the public page does not render, and a written policy in this directory with no control behind it, both fail tests/test_trust_controls.py. This document is covered by that test.

4. Third-party code

Dependencies are pinned and locked; trivy fs reads the lock file before every push. Upgrades inside a semver-compatible range are made autonomously; a major-version upgrade is a founder decision. There is no automated dependency- update bot configured today — see §6.

5. Vulnerability handling

A CRITICAL advisory in a dependency gates the push, so it is fixed or explicitly waived in .trivyignore with a reason and a date (tests/test_trivy_ignore_policy.py refuses an entry without either). A HIGH advisory is reported on the run and swept in batches. A vulnerability found in our code is handled as an incident when it is exploitable in production, and as an ordinary fix when it is not — the deciding question is whether customer data could have been reached, and it is answered in writing either way.

6. Known gaps

• No dependency-update bot. Dependabot is named in the engineering constitution but no .github/dependabot.yml exists; upgrades are manual and prompted by the trivy report.
• Coverage is a standard, not a gate. The 80 % minimum is written in CLAUDE.md and measured on demand; the pre-push gate does not fail on a drop.
• No SAST beyond ruff's security ruleset. Semgrep is not run. ruff S covers the Bandit checks; the interprocedural rules Semgrep would add are not in place.
• One reviewer, and it is a machine — the author's own. There is no second human to review a pull request, and since ADR-0119 the automated reviewer runs on the author's machine rather than on a CI server. The compensating control is the gate list in §2 and the ADR requirement for anything architectural; the absence is disclosed in docs/security/soc2-readiness.md rather than papered over.
• No scheduled scan and no image scan. The dependency scan runs when someone pushes and never in a quiet period; the built container image is not scanned (trivy image needs Docker, which the gate machine does not have). The quarterly review runs trivy fs by hand to cover the first half.