17 KiB
全面代码审计报告 - 2026-06-21
一、审计目标
对小虾 SaaS 进行一次系统性代码审计,重点不是局部补丁,而是发现并修复:
- 架构分层不一致
- 重复入口和重复实现
- 安全与认证缺陷
- 外部依赖导入副作用
- 配置真源缺失
- 可验证的 P0/P1 Bug
二、本轮已确认并修复的问题
1. P0:简化认证使用 SHA256 存储密码
涉及文件:apps/api/app/api/routes/auth_simple.py
问题:
- 注册使用
hashlib.sha256(password)保存密码。 - 登录用同样 SHA256 比对。
- 这是不可接受的密码存储方案,缺少 salt 和 cost factor。
根因:
auth_simple.py作为临时实现进入真实路由后没有回收。- 项目已有
PasswordHasher(bcrypt),但真实 API 没有复用。
修复:
- 注册改为
password_hasher.hash_password()。 - 登录改为 bcrypt 校验。
- 对历史 SHA256 用户做透明迁移:首次成功登录后自动升级为 bcrypt。
- 增加密码强度校验。
2. P0:登录返回不可验证随机 token
涉及文件:apps/api/app/api/routes/auth_simple.py、apps/api/app/config.py
问题:
- 登录返回
secrets.token_urlsafe(32)。 - Token 没有签名、没有 payload、没有过期时间、无法被标准认证中间件验证。
根因:
- 临时认证实现绕过了项目已有 JWT 设计。
- API settings 缺少
JWT_SECRET_KEY配置项。
修复:
- 登录返回 HS256 JWT。
- JWT payload 包含
sub/email/type/iat/exp。 - 响应新增
expires_in。 Settings增加JWT_SECRET_KEY,由.env可覆盖。
3. P1:API 路由包存在重复入口和导入副作用
涉及文件:apps/api/app/api/routes/__init__.py
问题:
routes/__init__.py维护了一份重复api_router。- 正式入口
app/api/router.py也维护一份api_router。 - 两者内容不一致,旧入口缺少后续生成/成片路由。
- 导入
app.api.routes会连带导入所有路由和外部依赖。
根因:
- 迁移过程中保留了旧入口,没有明确唯一真源。
修复:
routes/__init__.py改为兼容转发,只导出 canonicalapp.api.router中的api_router和health_router。
4. P1:OSS SDK 为硬导入,导致无 OSS 本地环境无法导入 API Router
涉及文件:apps/api/app/core/storage.py
问题:
import oss2在模块顶层执行。- 本地/测试环境未安装
oss2时,导入任何包含generated_videos的 API router 都会失败。
根因:
- 外部存储适配器没有做到依赖可选和配置驱动。
- 无 OSS 配置时,本地 generated 文件已经可以工作,但代码仍强制要求 OSS SDK。
修复:
oss2改为可选导入。- 只有配置了 OSS AK/SK 并实际创建 bucket 时才要求
oss2。 - 未配置 OSS 时,下载 URL 对本地
/generated-files/直接返回,对 OSS URL 回退为公开 URL。 - 上传/下载等 OSS 专属操作在未配置时返回明确错误。
5. P1:API 配置存在双真源
涉及文件:apps/api/app/config.py、apps/api/app/core/config.py
问题:
app/config.py与app/core/config.py同时定义 Settings。- 两套配置字段命名、OSS/MinIO、JWT、CORS 等含义不一致。
- 新代码主要使用
app.config,旧模块可能误导入app.core.config。
根因:
- 早期目录重构后没有清理旧配置入口。
修复:
- 明确
app.config为 API 配置唯一真源。 app/core/config.py改为兼容转发层,只 re-export canonical Settings/get_settings/settings。- 避免未来继续在旧文件增加新字段导致漂移。
6. P1:旧认证/工作空间路由引用已移除的 DI Container
涉及文件:apps/api/app/api/routes/auth.py、apps/api/app/api/routes/workspaces.py、apps/api/app/middleware/auth.py
问题:
- 旧完整认证和 workspace 路由引用
get_container()。 apps/api/app/dependencies.py已无get_container()。- 当前 canonical router 未挂载它们,但任何误导入都会成为运行时炸弹。
根因:
- DI 重构后旧路由未删除也未迁移。
- “完整实现”文件名误导后续开发者可能重新挂载坏代码。
修复:
- 旧模块顶部显式标记为 legacy disabled。
- 误导入时立即抛出清晰错误,而不是深层 ImportError。
- 后续只能在重建 DI composition root 后重新启用。
7. P1:CI 质量门禁只打印版本,不执行检查
涉及文件:.gitea/workflows/ci-cd.yml、.github/workflows/ci-cd.yml
问题:
- CI 安装/验证工具版本后直接成功。
black/isort/flake8/bandit/pytest没有实际检查代码。- develop/main 可能在红线问题未暴露时继续部署。
根因:
- 早期为了验证 CI 环境可用,留下了占位命令。
- 后续没有升级为真实质量门禁。
修复:
- CI 改为执行
compileall、black --check、isort --check-only、flake8、bandit。 - 测试步骤改为
python -m pytest tests -q。 - Gitea 与 GitHub workflow 保持一致,避免 CI 双轨漂移。
8. P1:Domain 层直接依赖 Redis/SMTP
涉及文件:packages/domain/auth/session_store.py、packages/domain/auth/email_service.py、packages/adapters/redis/session_store.py、packages/adapters/smtp/email_service.py
问题:
- Domain 层直接 import Redis、SMTP、email MIME 等基础设施实现。
packages.domain.auth.__init__导入时创建 Redis/SMTP 全局单例。- Application use case 通过模块全局变量调用外部服务,测试只能 patch 全局变量。
根因:
- 基础设施实现被放进了 domain 包,破坏 Clean Architecture 依赖方向。
- 外部服务没有通过构造注入进入 use case。
修复:
- Redis session 实现迁移到
packages/adapters/redis/session_store.py。 - SMTP email 实现迁移到
packages/adapters/smtp/email_service.py。 - Domain 原路径保留兼容 shim,但不再导出全局外部服务单例。
- 注册、登录、登出、密码重置、邀请成员 use case 改为构造注入,默认使用 adapter 懒加载工厂。
- 相关测试从 patch 模块全局变量改为注入 mock 服务。
9. P1:API 路由层直接依赖具体 SQLAlchemy Adapter
涉及文件:apps/api/app/api/routes/*.py、tests/unit/test_architecture_boundaries.py
问题:
- 多个 API route 直接 import
SQLAlchemy*Repository。 - 路由层本应只依赖 FastAPI dependency provider 和 application use case,不应知道具体仓储实现。
- 具体 adapter 只能出现在 composition root,例如
apps/api/app/dependencies.py。
根因:
- 为了类型标注方便,把基础设施类型泄漏进 API route。
- 没有架构守卫测试阻止回归。
修复:
- 移除 route 层对
packages.adapters.sqlalchemy_impl的直接 import。 - route 层仓储参数改为
Any,具体实现保留在dependencies.py注入。 - 新增
tests/unit/test_architecture_boundaries.py,防止 route 层再次直接 import SQLAlchemy adapter。 - 同时守住
domain.auth不再导出 Redis/SMTP 全局单例。
10. P1:Postgres psycopg Adapter 与 SQLAlchemy Adapter 双轨
涉及文件:packages/adapters/postgres/*、tests/unit/test_architecture_boundaries.py
问题:
packages/adapters/postgres/*与packages/adapters/sqlalchemy_impl/*同时存在。- 主运行链路实际使用 SQLAlchemy,但旧 postgres package 仍可被新代码误导入。
- 双仓储会造成连接池、事务、模型字段、schema 迁移多头漂移。
根因:
- 历史 psycopg 实现被 SQLAlchemy 替代后没有明确废弃边界。
- 缺少测试禁止运行时代码继续引用旧 adapter。
修复:
- 删除
packages/adapters/postgres/*旧 psycopg adapter 文件。 - 新增/强化架构守卫:
apps/、packages/、tests/不得 importpackages.adapters.postgres或Postgres*。 - SQLAlchemy 明确为 SaaS 当前唯一主线持久化 adapter。
11. P1:部署入口双轨与根 Docker 文件漂移
涉及文件:Dockerfile、docker-compose.yml、infra/docker/*、docs/DEPLOYMENT.md
问题:
- 根
Dockerfile与infra/docker/api.Dockerfile启动路径不同。 - 根
docker-compose.yml与infra/docker/compose.yml拓扑不同。 - 实际 staging/CI 使用
infra/docker,但根入口仍可能被误用。
根因:
- 早期单 API 部署文件没有在多服务架构形成后废弃。
- 部署文档仍保留旧命令,容易引导错误操作。
修复:
- 根
Dockerfile改为 deprecated sentinel,误 build 会失败并提示使用infra/docker/api.Dockerfile。 - 根
docker-compose.yml改为 deprecated sentinel,误 up 会失败并提示使用infra/docker/compose.yml。 docs/DEPLOYMENT.md改为声明唯一部署入口和 Gitea Actions 部署约定。
12. P1:本地 CI 虚拟环境被误跟踪
涉及文件:.gitignore、.venv-ci-root/
问题:
.venv-ci-root中 3000+ 个第三方依赖文件被 Git 跟踪。- 搜索、审计、CI 和 diff 都会被虚拟环境噪音污染。
根因:
.gitignore没有忽略.venv-ci-root/。- 本地 CI 工具环境被误加入索引。
修复:
.gitignore增加.venv-ci-root/。- 从 Git 索引移除
.venv-ci-root,本地文件保留。
13. P1:数据库 Schema 多真源漂移
涉及文件:init-tables.sql、migrations/*.sql、packages/adapters/sqlalchemy_impl/models.py、docs/SCHEMA-MAINLINE.md
问题:
init-tables.sql、migrations/*.sql、SQLAlchemy models 曾同时定义表结构。- 字段已经漂移,例如历史 SQL 使用
assets.library_id/storage_key/mime_type,当前 SQLAlchemy 使用assets.asset_library_id/file_url/file_type。 - 旧运行时曾由 SQLAlchemy
Base.metadata.create_all()建表,部署缺少正式 migration 主线。
根因:
- Phase 迁移过程中 SQL 快照没有退役。
- Alembic 迁移链曾存在但 revision 已过期,和当前 SQLAlchemy model 不一致。
修复:
init-tables.sql改为 deprecated sentinel,误执行会直接失败。- 新增并更新
docs/SCHEMA-MAINLINE.md,明确 SQLAlchemy models 是 schema 定义真源,Alembic 是迁移执行真源。 - 删除 stale Alembic revisions,新增
alembic/versions/001_current_schema_baseline.py作为当前 schema baseline。 alembic/env.py改为从DATABASE_URL读取连接,并启用compare_type=True。infra/docker/deploy-staging.sh在服务启动前执行alembic upgrade head;已有业务表但无版本表时执行alembic stamp head && alembic upgrade head。- API/Worker 默认关闭
AUTO_CREATE_SCHEMA,不再默认调用Base.metadata.create_all()。 - staging 已验证:
alembic_version = 001,health check healthy,develop部署 job succeeded。 - 架构守卫禁止运行时代码引用
init-tables.sql或历史migrations/001_initial_schema.sql。
三、已补充测试
新增
tests/unit/test_auth_simple.pytests/unit/test_login_use_case.pytests/unit/test_register_user_use_case.pytests/unit/test_password_reset_use_case.pytests/unit/test_architecture_boundaries.py
覆盖:
- 登录 token 是可验证 JWT。
- bcrypt 密码可登录。
- 历史 SHA256 密码登录后自动升级 bcrypt。
- 错误密码拒绝且不会写库。
已运行通过
python -m pytest tests/unit/test_architecture_boundaries.py tests/unit/test_auth_simple.py tests/unit/test_password_hasher.py tests/integration/test_generation_pipeline.py tests/integration/test_projects.py -q
python -m pytest tests/unit/test_login_use_case.py tests/unit/test_register_user_use_case.py tests/unit/test_password_reset_use_case.py tests/unit/test_invite_member_use_case.py tests/unit/test_session_store.py tests/unit/test_email_service.py -q
结果:34 passed,52 passed
四、仍需继续治理的问题
P1:认证体系双轨(已收敛)
当前认证入口已收敛到 canonical route:
apps/api/app/api/routes/auth.pyapps/api/app/auth.pypackages/application/auth/*packages/adapters/sqlalchemy_impl/user_repository.py
已完成:
auth.py不再是 disabled skeleton,也不依赖缺失的get_container()。api/router.py直接挂载app.api.routes.auth。auth_simple.py兼容 shim 已删除,认证入口只保留auth.py。- 登录/注册/当前用户均通过
UserRepository + UseCase + app.auth,route 层不再承载认证业务逻辑。
剩余建议:
- 持续用 grep/架构测试防止
auth_simple.py路径回流。 - 根据产品需要补齐 password reset / verify email 的正式 route。
- 接入真实邮件 adapter 前继续保持 no-op email delivery。
P1:认证扩展路由缺失(已补齐)
已完成:
GET /api/v1/auth/verify-email?token=...POST /api/v1/auth/verify-emailPOST /api/v1/auth/password/forgotPOST /api/v1/auth/forgot-passwordPOST /api/v1/auth/password/resetPOST /api/v1/auth/reset-password
说明:
- 同时保留后端历史路径和前端现有路径,避免前后端命名漂移导致功能不可用。
- 路由仍通过
UserRepository + UseCase,不在 route 层写业务逻辑。 - 邮件发送在当前 compatibility route 中仍使用 no-op email service,接入真实 SMTP adapter 前不会对外发信。
- 已修复 password reset token 过期判断中的 naive/aware datetime 比较风险。
P1:外部服务 adapter 化收尾(已配置驱动)
已完成:
- 认证 route 不再持有私有 no-op email/session 类,改为从
apps/api/app/dependencies.py获取配置驱动 adapter。 ENABLE_EMAIL_DELIVERY=false时使用 no-op email service,true时按 SMTP 配置创建EmailService。ENABLE_REDIS_SESSIONS=false时使用 no-op session store,true时按REDIS_URL创建 Redis session store。- SMTP/Redis no-op 实现放在 adapter 层,use case 仍通过构造注入使用。
剩余建议:
- Production 开启前需要真实 SMTP/Redis 连接验证和密钥审计。
P1:Domain 层存在外部基础设施依赖
涉及:
packages/domain/auth/session_store.py直接依赖 Redis。packages/domain/auth/email_service.py直接依赖 SMTP。
问题:
- 违反 Clean Architecture。
- Domain import 会创建全局外部服务实例。
- 错误处理使用
print和吞异常。
建议:
- 抽象
SessionStore、EmailSenderport。 - Redis/SMTP 实现迁移到 adapters。
- UseCase 通过构造函数注入 port。
P1:Repository 体系双轨(已收敛)
当前持久化主线:
packages/adapters/sqlalchemy_impl/*
已完成:
- 旧
packages/adapters/postgres/*psycopg adapter 已删除。 - 架构守卫禁止运行时代码重新引用
packages.adapters.postgres或Postgres*。 - Workspace/User/Member/Invitation 已走 SQLAlchemy adapter 与 API composition root。
剩余建议:
- 继续检查文档和脚本中的旧术语,避免恢复 psycopg adapter。
P1:存储命名漂移(已收敛)
已完成:
- 运行时代码改用
OSSStorageService/get_storage_service命名。 apps/api/app/core/storage.py仅保留MinIOService/get_minio_service兼容别名作为边界层。- 架构守卫禁止 runtime/test 代码继续引用 MinIO 命名。
- 当前主线为 OSS;未配置 OSS 时,生成文件通过本地
/generated-files/fallback 公开访问。
P2:Bandit 安全告警(已清零)
已完成:
- B104:API bind 地址改为配置驱动,容器内
0.0.0.0明确标注为 bind address,外部暴露由 Docker/Nginx 控制。 - B104:登录默认
ip_address从0.0.0.0改为unknown,避免把未知 IP 伪装成 bind-all 地址。 - B110:worker 失败状态更新不再吞异常;返回
state_error并执行 rollback。 - B404/B603/B607:FFmpeg/FFprobe 通过固定参数列表、
shell=False、shutil.which解析路径,并用nosec标注剩余可接受风险。 - 当前
python -m bandit -r apps packages -q通过。
P2:临时代码仍在主线
发现:
auth_simple.pyshim 已删除。- 部分测试和文档仍引用旧 MinIO/OSS 混合术语。
__pycache__文件出现在工作树扫描中,需确认.gitignore和仓库状态。
P1:生产 Alembic 准备(已形成 checklist)
已完成:
- 新增
docs/PRODUCTION-RELEASE-CHECKLIST.md。 - 明确生产发布前必须执行:staging 验证、CI 验证、生产 env 审计、数据库备份、Alembic 状态判断、发布后 smoke。
- 明确首次生产接入 Alembic 的判断规则:已有
alembic_version则 upgrade;有业务表但无版本表则 stamp head 后 upgrade;空库直接 upgrade。 - 明确回滚策略:应用优先回滚 tag;数据库只在验证过 downgrade 时使用 downgrade,否则以备份恢复作为最终兜底。
剩余建议:
- 真正生产发布前,基于当时生产容器名和 DB 名写一次性恢复 runbook。
五、下一步建议修复顺序
- Production 外部服务上线:验证 SMTP/Redis 连接、密钥和告警。
- 验证真实 SMTP/Redis/OSS 凭证并完成生产外部服务 smoke。
- 全量测试和 CI:后端 unit/integration + 前端 type-check/build + staging smoke。