Accreditation Platform — Security Hardening

• Что это: SaaS для аккредитации медучреждений от US healthtech platform. Состоит из бэкенда (API), frontend и facility-portal (портал учреждения). Задеплоен на GCP (Cloud Build).
• Тип / статус / роль: web-app (healthcare SaaS) · active · contributor (безопасность) — пользователь сделал 8 из 134 коммитов; основные авторы — Anton Kim <anton@US healthtech platform> (65, основатель/CTO US healthtech platform) и uzaxirr (61). Но вклад пользователя — сфокусированный блок безопасности, вмерженный через PR (ветка US healthtech platform/davr).
• Активный период: репозиторий 2026-03-20 → 2026-04-18; вклад пользователя — компактный security-спринт 2026-03-28.

• Языки: TypeScript (frontend), Python (бэкенд — судя по профилю SEC-тикетов: JWT middleware, 22 API-эндпоинта, FastAPI-подобный).
• Фреймворки/библиотеки: frontend — Next.js 15 + React 19 + Tailwind CSS 4 + TanStack Query 5; facility-portal (отдельный frontend); бэкенд — Python API с JWT/RBAC.
• Инфра/деплой: GCP Cloud Build (cloudbuild.yaml, .gcloudignore), docker-compose, Playwright (.playwright-cli), GitHub Actions.
• Заметные инструменты: большой CLAUDE.md (29KB) + README (28KB); тикеты Linear (SEC-*).

Все 8 авторских коммитов — security hardening (по сообщениям/тикетам SEC-*):

• Аутентификация (7b3a97b SEC-001/002): модель User + JWT middleware + RBAC-зависимости.
• Auth-эндпоинты (c152764 SEC-004/006): login/logout/refresh + admin seed.
• RBAC enforcement (46d4a22 SEC-003): RBAC применён ко ВСЕМ 22 API-эндпоинтам.
• Веб-уязвимости (14a2098 SEC-010/011/012): защита от SSRF, фикс path traversal, валидация URL.
• План/доки (dcc5e29, bb1986d): план работ по безопасности v2 + 40 тикетов Linear + обновление спеки с находками аудита.
• Вмержено через PR #1, #2 (US healthtech platform/davr).
• Объём: 8 коммитов, но это цельный пакет безопасности (auth + authz + защита от инъекций), а не разрозненные фиксы.

По диффам/тикетам (авторство пользователя — блок безопасности):

• JWT + RBAC с нуля (SEC-001..004): модель User, JWT middleware, RBAC-зависимости, login/logout/refresh, admin seed — и RBAC enforcement на всех 22 эндпоинтах (не выборочно). → Системный подход к авторизации (а не «прикрутили токен на один роут»).
• Закрытие классов OWASP (SEC-010..012): защита от SSRF (валидация исходящих URL), фикс path traversal, валидация входных URL. → Знание веб-уязвимостей и их точечное закрытие на медицинской (чувствительной) платформе.
• Безопасность как процесс: план работ v2 + 40 тикетов + обновление спеки с находками аудита → не разовый патч, а структурированная security-программа. → Совпадает с известной security-экспертизой пользователя (STRIDE-аудит, AES-GCM TOTP, lockout в admin_v2).

• Найдено сессий: 0 в соответствующей директории (проверено нормализацией). Есть .claude/ + большой CLAUDE.md → AI-ассист вероятен (команда US healthtech platform в целом AI-native), но пользовательских сессий здесь нет.
• Что делалось с AI: данных по вкладу пользователя нет; кодовая база в целом — командная работа.
• Паттерны AI-воркфлоу: CLAUDE.md как контекст; тесты Playwright.

• Вклад пользователя: цельный слой auth/authz (JWT+RBAC на 22 эндпоинтах) + закрытие SSRF/path-traversal/URL-инъекций на healthcare-платформе. Небольшой по объёму коммитов, но высокий по ценности (security-critical для медицинских данных).