security-comms

用途

Security Comms 用于补上安全工作中常见的一块缺口：审计、响应、治理等技能产出的发现、事件与路线图，往往无法直接用于董事会、客户、销售工程师或 CFO 的沟通场景。该技能把技术性安全内容转写成目标受众真正能使用的交付物，据称是安全从业者每周会用到两到三次的技能，也适用于没有专职安全团队的创始人。

它与其他技能相互衔接：接收审计输出、事件记录、威胁模型摘要、CSF 评估等输入，产出面向特定受众的交付物，并与 finding-triage（处置说明）和 incident-triage（响应叙述）配合紧密。

主要能力：七类受众与各自所需

安全沟通不是单一语域，用错语域是最常见的失败模式。

董事会 / 非执行董事：需要知道是否实质性暴露、团队是否在处理、是否需要追加投入；不需要 CVE 编号、文件路径、扫描器名称、技术术语和方法论。格式为一页或一页幻灯片，含现状一段、前三项风险各一句、所需投入或决策；数字须是实质性影响（美元或百分比），而非原始计数。常见错误是给董事会评分热力图和 30 行 CVE 表格。
高管层（CEO / CFO / COO / GC）：需要知道被要求做什么决策、权衡是什么、不行动的代价。格式为一到三页备忘录，先给决策，再给背景、带权衡的选项、建议，以及若否决所需的成本/时间/人力/风险；尽可能量化（监管敞口金额、客户信任流失百分比、工程小时）。常见错误是申请预算却不说明被拒后的替代方案。
工程负责人 / 资深工程师：需要知道什么坏了、怎么修、优先级、对路线图的影响。格式为工单或设计文档形态：具体文件/端点/提交、复现步骤、修复提案、验证步骤、工作量估计。常见错误是不展示依据就给安全活定紧急级别。
普通工程师（实际执行者）：需要知道在自己代码里具体改什么，并附可自行运行的验证。格式为带代码细节的工单：文件路径、行号、当前代码、修复后代码、证明修复有效的测试。常见错误是直接粘贴扫描器输出而缺少上下文。
客户成功 / 售前工程：需要知道客户问起时怎么回答、常见安全问卷字段的答案、有哪些变化需要提及。格式为内部 FAQ，问题按客户口吻撰写，答案供 SE 朗读或粘贴；避免安全术语，除非法务明确要求，否则避免“不予置评”。常见错误是起草客户可见文案前未让客户成功团队检查语气。
客户（处于公开披露场景）：需要知道自己的数据是否被访问、你做了什么、自己需要做什么。格式为一封短信，先用客户能理解的方式说明发生了什么，说明可能涉及的数据、已采取的措施、客户应做的事，并提供可用的联系路径。常见错误是把“我们还不确定但必须通知”说成“出于充分的谨慎”。面向客户的披露涉及法律与监管维度，本技能只产出草稿，发布前须经法务及可能的外部律师审阅。
采购 / 法务 / 合规对口方（内部或供应商侧）：需要知道是否合规、有哪些文档、合同立场如何、是否有证据。格式为结构化材料：问卷答复、BAA / DPA 红线输入、审计证据提取；使用对方所用的框架语言（CSF 子类 ID、ISO 控制项、PCI 要求编号、HIPAA 保障措施名称），不要翻译成自己的框架。常见错误是只答“是/否”而不附证据指引。

使用方式

该技能有两种模式。

模式一：从技术输入起草。步骤为：确定受众（七类中之何者）；若多于一类则拆成独立交付物，不要合并。确定所请求的决策（董事会是“批准预算”、工程是“某日期前修复”、客户是“相信我们已处理”）；若无法用一句话说出决策，则说明该受众没有决策，交付物是信息性的而非行动导向。剥离与该受众无关的技术材料：同一发现写三份不同草稿，CVE 给工程师、金额给高管、客户影响给客户。先写结论：若对方只读第一段，应得到什么。尽可能量化，即使粗略；“影响约 8% 的付费客户”优于“影响部分客户”；不知道就明说，不要用含糊措辞搪塞。最后交由与受众视角相同的第二审阅者过目：工程交付物给另一名工程师，客户披露给客户成功，董事会更新给实际参加董事会会议的人。

模式二：审查草稿。检查项包括受众检查（语域是否匹配指定受众）、决策检查（需要做的决策是否明显）、术语检查（标出受众在自己工作中不会使用的词）、含糊检查（“出于充分的谨慎”“尽最大努力”“行业标准”等读起来像回避，尽可能替换为具体陈述）、具体性检查（草稿是否说明发现什么、做了什么、下一步是什么，并有名字）。

模板

技能提供多类模板，包括：董事会安全事件更新（含底线、发生了什么、已做的事、向董事会请求什么、下次会议前会知道什么）、请求决策的高管备忘（决策、为何现在、选项及成本/时间/剩余风险、建议、不行动的代价）、面向客户的泄露披露草稿（注明需法务审阅，含涉及与未涉及的数据字段、已采取措施、建议客户行动、可用联系路径、署名与职务而非公司落款）、内部事后复盘叙述（摘要、时间线、影响、根本原因、做得好与不好的方面、行动项表格、对其他团队的教训）、面向工程的审计发现翻译（摘要、按优先级排列的发现表、逐条详情、以及“非真实发现”的附带说明以建立工程信任）、售前工程 FAQ（内部使用，非客户可见，含常见问题直答、行动建议、书面通知时间、以及未列问题的升级路径）。

关于审查 AI 生成的安全沟通

由于本技能本身会被 AI 代理使用，资料特别提示：AI 生成的安全沟通不得在未经该受众对应的审阅者把关的情况下发出。客户披露必须经法务审阅后方可发送；董事会更新应经 CEO / CISO 过目后再放入演示；高管备忘录应经熟悉该高管决策风格的人审阅；工程工单可较轻审阅，但不应跳过验证步骤。AI 起草的安全沟通最有价值的定位是初稿而非终稿——据称可把初稿耗时从 90 分钟压缩到 10 分钟，但不能替代审阅闭环。

限制与边界

该技能产出沟通材料，但不授权披露。面向客户的泄露披露涉及法律、监管（GDPR 第 33 条、HIPAA 泄露通知规则、各州泄露通知法、上市公司的 SEC 8-K 重大事件披露）与合同层面——草稿不等于已发送的消息。技能拒绝起草意在误导的沟通，包括淡化实质性影响、错误归咎，或把已被接受风险的发现说成已解决。未经授权，不得起草点名个别客户或提供其个人信息的披露。对于涉及执法介入的事件（勒索软件付款、国家级归因），沟通策略与律师共同确定；该技能产出的是面向指定受众一侧的草稿，而非执法一侧。

参考资料

资料列出的参考包括：《Crafting the InfoSec Playbook》（Bollinger / Enright / Valites）的沟通章节；SANS 关于与高管沟通的年度报告；《The Manager's Path》（Camille Fournier）中关于面向非技术受众写作的部分；SEC 2023 年网络安全风险管理、战略、治理与事件披露最终规则（重大事件披露时点）；GDPR 第 33 条（72 小时内通知监管机构）；HIPAA 泄露通知规则（60 天内通知受影响个人）；ENISA 危机沟通指南；《Cybersecurity Incident Response: How to Contain, Eradicate, and Recover from Incidents》（Eric C. Thompson）。

暂未提供的信息

资料未提供该技能的定价、收费模式、所属平台的具体运行方式、安装命令或代码实现细节。