setvik/startup-security-baseline

# AI 时代初创公司安全基线 面向专注于 AI 的初创公司技术创始人和工程负责人的实用原则。 ## AI 改变了博弈格局 每一份初创公司安全指南——从 [YC 2022 年的 HN 清单](https://news.ycombinator.com/item?id=32662385) 至今仍在发布的 [种子轮到 C 轮路线图](https://www.techcompass.us/blog/saas-startup-security-roadmap-seed-to-series-c)——都围绕工作量和专业知识来分阶段安排建议：“先做简单的事情，后做困难的事情，最终雇一个安全人员。”目前普遍的观念仍然是“在达到 PMF（产品市场契合点）之前，几乎什么都可以做。” 这种博弈格局已经改变。AI 编程 Agent 可以构建你的“基础设施即代码”、配置 OIDC 联邦身份验证、编写最小权限的 IAM 策略、设置漏洞扫描并配置 WAF 规则——而且你可以将它们全部部署上线——只需几天，而不是几周。以“工作量大”为借口的时代已经结束，而且你还能免费获得版本历史、代码审查和可供 AI 审计的配置。 把一切都写成代码，把一切放进 git。Web 控制台中的安全配置对 AI Agent 是不可见的。而 git 中的配置存在于 AI 的上下文窗口中——AI 可以审查你的 IAM 策略，发现配置漂移，并在每次提交时执行你的安全标准。你的安全态势是动态的，而不是一次性的设置。 大多数初创公司被入侵的事件仍然可追溯到凭据窃取、IAM 配置错误和供应链受损。这些原则默认消除了那些常见的故障模式。 但 AI 也正在削弱攻防等式中防守方的优势。前沿模型能够发现新的漏洞，而 Agent 将其武器化的速度比任何人类团队都要快。下面列出的分层防御就是为了在零日漏洞爆发时为你争取时间。 这 16 条原则是按照**你必须保护什么**来分阶段的，而不是按照你有多少时间来设置。 ## 一览 **种子轮前（借助 AI 均可在几天内完成）：** 1. 身份即边界 2. 短期凭据，绝不落盘 3. 一切皆代码，以便 AI 防御 4. 静态和传输中全量加密 5. 默认安全，而非策略安全 6. 从一开始就记录一切日志 7. 锁定一切，不信任任何可变内容 8. 简单即安全策略 9. 爆炸半径为一 10. 坚固壁垒的深度防御 **拥有真实用户和数据时：** 11. 最小权限，持续验证 12. 持续扫描，立即修补 13. 第三方访问即攻击面 14. 为故障做计划，并测试该计划 **团队扩张时：** 15. 对重要事项发出警报 16. AI 用于防御——并保护你的 AI ### 1. 身份即边界 选择一个提供商，在所有地方进行联邦身份验证，并将 IdP（身份提供商）被攻破视为灭绝级事件。 - **单一身份提供商，处处联邦。** Google Workspace（或 Okta、Entra ID）作为唯一的真实来源。通过 SAML/SCIM 连接到 AWS Identity Center 或 GCP Workforce Identity Federation，SaaS 使用 OAuth，CI 使用 OIDC。不使用 IAM 用户，不使用服务账号密钥文件。 - **在 IdP 层面强制使用 MFA。** 全面使用 TOTP 或通行密钥，绝不使用短信。对于管理员账户（云管理员、IdP 管理员、GitHub 组织所有者），仅使用通行密钥——防钓鱼、绑定来源、无需硬件物流管理。 - **特权访问使用短会话。** 管理员会话时长≤1小时，敏感操作需重新认证。浏览器会话就是凭据——应像对待 API 密钥一样对待它们。 - **离职流程与入职流程同等重要。** 如果所有内容都已联邦化，禁用 IdP 账户就会撤销所有地方的访问权限。任何*未*联邦化的事物都是僵尸账户风险——需每季度审计。 ### 2. 短期凭据，绝不落盘 不要使用静态 API 密钥，不要使用永久访问令牌，不要在 `~/.ssh` 中存放 SSH 密钥。如果一个凭据不能在几小时内自动过期，它就不应该存在。 - **开发者机器——让凭据远离文件和环境变量。** 在 AWS 上，[Granted](https://github.com/fwdcloudsec/granted) 将短期 STS 令牌存储在系统密钥链中并提供给 SDK 使用——`~/.aws/credentials` 中不会留下任何内容。在 GCP 上，`gcloud auth login` 会将刷新令牌存储在磁盘上；虽然不够干净，但仍远好于静态服务账号 JSON。1Password SSH Agent 将密钥保存在密码库中——磁盘上没有私钥文件。 - **生产环境——使用平台的密钥注入。** 容器运行时（ECS、Kubernetes、Lambda）在运行时从托管存储（SSM Parameter Store、Secrets Manager、GCP Secret Manager）中拉取密钥。真正的敌人是 git 中的 `.env` 文件、硬编码在 `docker-compose.yml` 中的密钥，以及在 shell 配置文件中导出的静态凭据。 - **VM 访问——没有 SSH 密钥，没有开放端口。** AWS SSM Session Manager 和 GCP OS Login + IAP 允许你通过 IAM 获取 shell 访问权限，每个会话都有日志记录，无需开放 22 端口，无需堡垒机。 - **CI/CD——通过 OIDC 直接代入云角色。** GitHub Actions OIDC 适用于 AWS (`aws-actions/configure-aws-credentials`) 和 GCP (`google-github-actions/auth`)。CI 中无需配置静态密钥。 ### 3. 一切皆代码，以便 AI 防御 不要通过点击式配置来创建任何东西。所有的基础设施、配置和安全控制都必须写成代码。如果它不在 git 中，AI 就无法审查它。 - **从第一天起就建立专门的安全代码库。** IAM 权限集、网络策略、访问控制——全部放在 Terraform/OpenTofu/CDK 中并经过代码审查。点击配置仅用于引导程序（账户创建、状态后端），之后必须将一切代码化。 - **为 AI Agent 设定编码约定。** `AGENTS.md` 和规则文件指示 AI Agent 自动运行漏洞扫描、检查凭据泄漏并强制执行安全标准。 - **在 AI 生成的 IaC（基础设施即代码）落地前进行验证。** Agent 编写的 IAM 策略和网络配置往往看起来很自信，但有时是错误的。请使用 `terraform plan`、`aws accessanalyzer validate-policy` 和 OPA 作为 CI 门槛。 - **将无法代码化的内容文档化。** 有些工具没有 Terraform 提供商。无论如何，都要在代码库中记录当前状态——AI 可以根据实际情况审计文档并标记出漂移。 ### 4. 从创建之时起，对静态和传输中的所有内容进行加密 加密是一项在创建时做出的决定。事后补充不仅痛苦，甚至可能无法实现。 - **AWS：启用那些仍需手动开启的选项。** 默认开启 EBS 加密是按区域划分的——在创建第一个卷之前，在每个区域都切换开启。RDS 静态加密只能在创建时设置；改造需要快照和恢复。S3 加密和阻止公共访问现在已成为新存储桶的默认设置。 - **GCP：验证默认设置，启用未覆盖的选项。** 静态加密在 Cloud Storage、Cloud SQL 和 Persistent Disk 中是自动的。统一存储桶级访问是新组织的默认设置——需在较早的组织上验证它是否已开启。 - **全面使用 TLS。** 数据库使用 `rds.force_ssl` / `require_ssl`，负载均衡器最低使用 TLS 1.3，仅限 HTTPS 并开启 HSTS。在初始设置时做这些微不足道，但在服务开始期待明文传输之后再做就会非常痛苦。 ### 5. 默认安全，而非策略安全 如果安全性取决于工程师是否记得做正确的事，那它肯定会失败。让不安全的路径比安全的路径更难走。 - **结构性护栏。** 主干分支的保护（强制要求审查、状态检查、禁止强制推送）。精确固定依赖项版本（在 `.npmrc` 中设置 `save-exact=true`，在 `pyproject.toml` 中使用 `==`）。使用 IaC 确保每次更改都需要审查。 - **CI 强制执行，而不是 PR 模板提醒。** 当扫描出现退步、锁文件发生漂移或 IaC lint 报错中断时，让构建失败。提醒和检查清单属于“策略安全”；强制执行属于“默认安全”。 - **AI Agent 护栏。** 配置 Agent（通过 `AGENTS.md`、Cursor rules 或等效方式）在其自检循环中运行安全扫描。一个拥有广泛代码库写入权限和云凭据的自动运行 Agent，在本质上就是一个内部人员——应该像界定工程师的权限一样界定它的权限，对于破坏性操作，默认应保持人在回路中。 ### 6. 从一开始就记录所有日志——你无法追溯捕捉已发生的事情 没有日志的每一天，都是你永远无法调查的一天。 - **云审计日志。** AWS：将 CloudTrail 设置为组织跟踪并覆盖所有区域——只需 10 分钟，成本几乎为零。GCP：管理员活动日志默认开启；为敏感服务启用数据访问日志。威胁检测（GuardDuty、Security Command Center）值得进行基线启用，但需有所选择——对高流量存储桶开启 GuardDuty S3 数据事件监控会迅速变得非常昂贵。 - **从第一行代码开始就使用结构化应用日志。** 从第一天起就使用 JSON 结构化日志。对一年来一直使用 `console.log("something happened")` 的应用进行结构化改造需要数周时间。 ### 7. 锁定一切，不信任任何可变内容 你依赖的每一项都是使用你的权限运行、却由他人编写的代码。攻击者可以悄悄覆盖的任何产物，都是你的流水线明天就会信任的产物。 - **在清单中精确固定版本，而不仅仅是锁文件。** 在 `.npmrc` 中设置 `save-exact=true`，在 `pyproject.toml` 中使用 `==` 固定。提交锁文件，并在 PR 中审查锁文件的差异。 - **不可变或通过 SHA 固定的 GitHub Actions。** 优先使用带有[不可变发布](https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases)的 Actions（通过加密方式锁定到某个 commit 的标签）。对于没有此功能的 Actions，请固定到 commit SHA——可变标签可能会被悄悄重定向到恶意代码。 - **不可变容器标签，通过摘要部署。** 在 ECR / Artifact Registry 上启用标签不可变性。通过摘要或不可变版本标签进行部署，绝不使用 `latest`。 - **为你自己的产物提供不可变发布。** 在你的代码库中启用 GitHub 不可变发布，并生成构建来源证明 (`actions/attest-build-provenance`)。现在在 GitHub 上生成 SBOMs 和 SLSA 风格的证明几乎是免费的——尽管用。 ### 8. 简单即安全策略 你创建的每一个资源都需要去保护、审计、修补和监控。最安全的基础设施就是根本不存在的基础设施。 - **积极地合并整合。** 更少的代码库意味着更少的分支保护、CI 流水链和安全配置需要保持一致。平台级单体代码库（app + 基础设施 + CI）为 AI Agent 提供了一个单一的上下文窗口以进行全面审计。如果确实需要拆分，请在每个代码库中强制执行相同的分支保护、`CODEOWNERS` 和 CI 安全检查。反面模式就是蔓延——15 个代码库，15 套配置，却无人维护一致性。 - **在必要时之前保持单体架构。** 对于小团队来说，单体架构只有一个认证边界、一次部署、一个需要扫描和修补的对象。*过早采用微服务会增加网络跃点、服务间认证和横向移动路径——这种复杂性是披着架构外衣的攻击面。* - **使用托管服务，而不是自己动手。** 使用 RDS/Cloud SQL，而不是在 VM 上跑 Postgres。使用 Fargate/Cloud Run，而不是在实例上跑 Docker。提供商会负责修补和强化安全。 - **容器优于 VM，并使用经过强化的基础镜像。** 无需修补 OS，无 SSH 守护进程，设计上即是不可变的。使用 Chainguard/Wolfi、Distroless 或 Docker Hardened Images，而不是现成的 `node:22` 或 `python:3.13`——标准基础镜像附带了你根本不需要的数百个包。请每夜或每周重新构建，以免它们变得陈旧。 - **默认保持内部。** 后端 API 位于内部负载均衡器之后，只能通过零信任网络（Tailscale、Cloudflare Access、GCP IAP）访问。计算和数据库置于私有子网中。公共子网仅用于负载均衡器。 ### 9. 爆炸半径为一 假设每个凭据都已被泄露。单个被盗令牌不应促成横向移动、权限提升或对无关系统的访问。 - **按环境隔离部署角色。** PR、预发布和生产使用独立的角色，并配置不同的 OIDC 主题过滤器。受损的 PR 工作无法部署到生产环境。 - **数据库层的租户隔离。** 在数据库层强制实行行级安全策略，而不仅仅是在中间件中。如果 API 错误绕过了身份验证检查，数据库仍会阻止跨租户访问。 - **网络分段。** 安全组和防火墙规则应精确限定于特定的服务到服务通信流。 ### 10. 坚固壁垒的深度防御 每一层都应独立阻止入侵。AI 辅助的攻击者可以毫不费力地攻克繁琐的障碍——每一层都必须是坚硬的屏障，而不仅仅是摩擦力。 - **从第一次 schema 迁移开始就使用 RLS（行级安全）。** 从一开始就将租户隔离设计到你的数据模型中。事后将 RLS 附加到 50 张表上，是初创公司所能面临的最昂贵的安全改造之一。 - **强制执行 CSP，而不仅仅是输入过滤。** 结合基于随机数的脚本白名单的 Content Security Policy 可以阻断 XSS，即使过滤代码本身存在缺陷。 - **每个公共端点都配备 WAF。** AWS WAF、GCP Cloud Armor 或 Cloudflare——独立于应用程序级验证。当零日漏洞爆发且无补丁可用时，一条 WAF 规则就能为你争取时间。 ### 11. 最小权限，持续验证 不要仅仅设置权限——还要自动化定期访问审查，以便在不依赖人工记忆的情况下发现配置漂移。 - **基础设施即代码。** 权限集和角色策略保存在 Terraform/OpenTofu 中。更改需经过代码审查；代码库即为审计追踪记录。 - **按环境、按服务划定权限范围。** CI 角色通过 OIDC 主题过滤器界定范围。任务/服务账号角色严格限定于特定的存储桶和密钥路径，绝不使用通配符。 - **紧急打破玻璃机制，而非长期常设权限。** 管理员访问需通过带有 MFA 的文档化升级流程获取，而不是永久分配管理员权限。 ### 12. 持续扫描，立即修补，对无法修补的进行缓解 从漏洞披露到武器化利用之间的时间，正在从几周缩短到几小时。 - **自动化修补 PR。** Dependabot 或 Renovate 设置为对补丁级别更新自动合并。这是缩短修补窗口你能做的最高效的单项举措。 - **锁文件和容器镜像扫描。** 对每个锁文件和构建镜像使用 Trivy（或 Grype、Snyk）。在本地、CI 中以及按计划定时运行。请通过校验和固定你的扫描器二进制文件。 - **密钥扫描。** 启用 GitHub 密钥扫描（或运行 TruffleHog），以捕获混入 commits、PR 描述或 CI 日志中的凭据。密钥的传播速度比代码更快——Slack 粘贴、截图、`.env` 文件、调试日志。扫描是最后的防护网。 - **针对未修补漏洞的缓解手册。** WAF 规则、功能开关、网络隔离。记录权衡过程并附上理由注释。SLA（服务等级协议）：关键 CVE 在 24 小时内修补，48 小时内部署。 ### 13. 第三方访问即攻击面 每一个 SaaS 集成、OAuth 连接和 Webhook 端点都是攻击面。 - **Webhook 签名验证。** 对每一个传入的 Webhook 进行加密验证。一个没有签名验证的公共 POST 端点就是一扇敞开的大门。 - **供应商访问权限清单。** 了解哪些第三方可以访问哪些数据。当供应商遭到入侵时，你需要在几小时内知道他们可能触及到了什么。 - **受批准、有日志且划定范围的 AI 工具。** 提供具有企业级数据控制权的受批准 AI 工具。应预想到个人账户的使用会将客户数据粘贴到未受批准的聊天 UI 中——这是人类层面的非人类身份问题。尽可能限制网络出站流量。 - **优先使用短期令牌。** 选择支持 OIDC/OAuth 的供应商，而不是那些需要永久 API 密钥的供应商。 ### 14. 为故障做计划，并测试该计划 弄清楚该联系谁、该轮换什么，或者备份是否有效的最糟糕时机，就是在真实事件发生的期间。把它写下来，然后进行演练。未经测试的计划不是计划；未经测试的备份不是备份。 - **上报联系方式和凭据轮换操作手册。** 一份简短的名单，列出凌晨 3 点该给谁打电话，以及预先写好的凭据轮换步骤。将其保存在安全代码库中，而不是可能在实际事件发生时无法访问的 Google Doc 中。 - **账户隔离程序。** 如何禁用受损角色、撤销会话以及快照取证——在清除和重建之前执行。 - **漏洞披露策略。** 发布包含联系方式和分类 SLA 的 `security.txt`（[RFC 9116](https://datatracker.ietf.org/doc/html/rfc9116))。为研究人员提供明确的提交路径。 - **定义 RTO 和 RPO。** 恢复时间目标和恢复点目标驱动着其他所有决策——存储层、备份频率、多区域态势。 - **按计划测试恢复和重建。** 定期从备份还原到测试环境。如果你的基础设施在 CDK/Terraform/Pulumi 中，请测试你是否真的能从头开始重新创建它。你的预发布环境就是你的 IaC 正常工作的证明——应当这样对待它。 ### 15. 对重要事项发出警报，构建分类工作流，并保留数据以供调查 只记录日志而不设警报，那就是一个只写的数据库。 - **自动警报。** 将威胁检测发现（GuardDuty、Security Command Center）路由到 Slack/PagerDuty。不要让发现结果停留在无人查看的控制台中。 - **哨兵事件警报。** Root/超级管理员账户的使用、来自异常区域的 API 调用、存储桶策略更改。 - **数据保留。** 应用程序日志至少保留 90 天，云审计日志保留 1 年。配合生命周期策略转入冷存储层，这比你想象的要便宜。 ### 16. 利用 AI 进行防御——并保护你的 AI 前沿模型已经能够发现身份验证绕过、授权逻辑缺陷和注入漏洞。如果你正在构建 AI 产品，你的模型和 Agent 同样也是攻击面。 - **使用前沿模型进行主动的身份认证/授权扫描。** 将当前模型指向你的身份验证中间件和授权逻辑，要求它找出绕过方法。当下行之有效的具体工作流：粘贴你的 RLS 策略并要求其寻找租户隔离绕过漏洞，输入你的 IAM 策略 JSON 并要求其寻找权限提升路径，向其提供你的 API 路由处理器并要求其查找破坏的访问控制。AI 的最强之处，恰恰是传统静态分析最弱的地方。建立一个可重复运行的扫描配置，以便在模型改进时可以反复运行——今天的模型发现简单的 bug，下个季度的模型将发现隐蔽的 bug。 - **将 MCP 服务器和 Agent 工具视为依赖项。** 模型上下文协议和 Agent 工具集成是一条新的供应链。锁定你运行的服务器，审查它们暴露了什么，并限制网络出站。对于破坏性操作（写入、删除、shell 命令、出站网络调用），默认保持在回路中的人工审批。一个带有受损 MCP 服务器的自动批准 Agent，就是一个拥有你权限的凭据窃取蠕虫。 - **Agent 读取的每一份文档都是不受信任的输入。** 间接提示注入——隐藏在 PR 正文、issue 评论、抓取的网页、客户上传的文件、电子邮件中的指令——就是 2026 年版的 XSS。对待 Agent 消费的内容跨越到 Agent 操作的边界，应像对待任何其他信任边界一样严格。进行过滤，限制工具访问权限，绝不让不受信任的内容在没有人工审查的情况下驱动特权操作。 - **防御你自己的 LLM 后端系统。**如果你将模型暴露给用户，你的系统提示、工具定义和模型输出就是攻击面。在 LLM 输出到达数据库或下游系统之前对其进行验证和净化，扫描输出中是否存在 PII 泄露，并将进入系统提示的用户输入视作如同进入 SQL 查询的用户输入一般对待。 - **模型和训练数据供应链。** 验证预训练模型和开放权重下载的来源。微调数据集和向量存储应置于与生产数据相同的租户隔离和访问控制之后。除非有明确的同意和处理规定，否则不要将客户数据放入评估测试集中。 ## 初创公司实际是如何被入侵的 如果上述原则让你觉得抽象，以下是它们所防范的具体失败案例。每一项都是来自真实初创公司的真实模式。 - **拥有广泛权限的共享账户** —— root 账户、管理员 IAM 用户，或没有 MFA、未进行联邦认证、凭据“全团队皆知”的 "shared-dev" 角色。本质上就是一把设计的万能钥匙。 - **没有离职管理流程** —— 六个月前离职的承包商仍然拥有访问权限，因为这些权限分散在 12 个 SaaS 工具中，且没有一个与 IdP 联邦化。 - **用安全意识培训代替结构性控制** —— 教导人们不要点击钓鱼链接，而不是部署防钓鱼认证。如果安全性依赖于人类的警惕性，那么它早就已经失败了。 - **到处都是长期有效的凭据** —— 提交到 git 的 `.env` 文件中的 API 密钥、“暂时”下载的服务账号 JSON、粘贴在 Slack 中的令牌。非人类身份很少有 MFA，极少轮换，并且通常拥有广泛的权限。 - **在控制台中点击配置的基础设施** —— 没有代码，没有审查，没有历史记录。当最初进行设置的唯一人员离开时，没有人知道正在运行的是什么以及为什么运行。 - **未开启审计日志** —— 入侵发生在三个月前，但没有 CloudTrail，没有访问日志，无法知道触及了什么或由谁触及。 - **GitHub Actions 固定在 `@v3`** —— 这是一个可变标签，维护者（或攻击者）可以将其悄悄重定向为在你的流水线中带着你的密钥运行任意代码。 - **生产环境中使用可变容器标签** —— `latest` 或 `v1` 被悄悄覆盖。一次被入侵的推送就会在每次部署中替换掉你已知良好的镜像。 - **“临时”公共 S3 存储桶** —— 为演示而创建，被遗忘了一年，被 GrayhatWarfare 编入索引。 - **拥有生产凭据的 CI 流水线** —— PR 构建可以部署到生产环境、读取生产密钥或修改基础设施。没有任何环境隔离。 - **在第一天创建了未加密的数据库** —— RDS 加密只能在创建时开启。你在第一周启动的实例两年后仍在未加密状态下运行。 - **SSH 和管理端口对互联网开放** —— `0.0.0.0/0` 上的端口 22 或 3389 仅仅是为了“调试”。这是最常见的云配置错误之一，也是最容易被利用的漏洞之一。 - **通配符 IAM 权限** —— `Action: "*", Resource: "*"`，因为“我们以后会缩小范围的”。实际上你不会的。

标签：AI Native, AI代理, AI初创公司, AI安全, Chat Copilot, CISA项目, DevSecOps, StruQ, WAF配置, 上游代理, 代码审查, 创业安全指南, 初创企业安全, 大模型安全, 安全基线, 安全态势管理, 教学环境, 文档安全, 极客安全, 漏洞利用检测, 短时效凭证, 网络安全, 请求拦截, 身份与访问管理, 防御纵深, 隐私保护, 零信任架构