security-and-hardening

security-and-hardening 技能概览

security-and-hardening skill 用于在应用代码上线前，针对常见漏洞进行加固。它最适合开发者、代码评审者，以及处理以下场景的 AI agent：接收不可信输入、管理会话、存储敏感数据，或调用外部服务。若你想把 security-and-hardening skill 用于 Security Audit，这个技能特别适合需要实现层面检查、而不只是泛泛安全清单的时候。

这个技能适合解决什么问题

当任务目标是在真实代码路径中降低被利用风险时，就该用 security-and-hardening：例如请求处理、认证流程、数据库访问、文件上传、webhook，以及支付或 PII 相关逻辑。这个技能的核心是边界控制，因此重点关注的是：数据进入存储层或业务逻辑之前，在系统边界处必须完成哪些安全动作。

它为什么有用

它的主要价值在于提供可落地的安全护栏：尽早校验输入、使用参数化查询、正确转义输出、保护会话、强制 HTTPS，并避免在认证或 secrets 上走不安全的捷径。因此，当你希望参考 security-and-hardening guide，获得更少猜测、更多明确的防御措施时，它会很有帮助。

什么时候特别适合用

如果你的 prompt 涉及加固现有功能、审查高风险代码，或把一句模糊的“把这个做安全一点”落实为具体改动，就应该选择这个技能。尤其是当工作流涉及在后端路由、面向用户的表单，或第三方 API 集成中使用 security-and-hardening usage 时，它的相关性会更高。

如何使用 security-and-hardening 技能

安装后先检查源码内容

进行 security-and-hardening install 时，使用：

npx skills add addyosmani/agent-skills --skill security-and-hardening

先看 SKILL.md，再阅读 frontmatter，以及其中关于“什么时候使用该技能”和“哪些事情必须始终做到”的章节。这个仓库没有额外的 rules/、resources/ 或脚本，因此 SKILL.md 就是最主要、也是最权威的信息来源。

给技能提供正确的输入信息

security-and-hardening skill 在你明确提供攻击面和威胁上下文时效果最好。不要只说“把这个 app 做安全”，而要说明暴露了什么、涉及哪些数据、以及当前技术栈有哪些约束。高质量输入通常会明确功能点、信任边界和风险点，例如：

Harden this password reset endpoint. It uses Express, PostgreSQL, and email links. Focus on input validation, token handling, rate limiting, and secure cookie/session behavior.

这比模糊 prompt 更有效，因为它给了模型清晰的边界、数据类型和目标结果。

按“先审查、后修改”的 workflow 使用

一种可靠的 security-and-hardening usage 方式是：先识别输入，再梳理信任边界，接着检查存储和输出处理，最后验证认证与传输层保护。提出修改要求时，应按照攻击面实际出现的顺序推进，而不是随机按问题列表逐条处理。对于 Security Audit 任务，这样做能让技能输出更贴近具体代码路径，而不是落回泛泛而谈的建议。

重点盯住高影响约束项

这个仓库强调几条不可妥协的原则：在边界处校验、使用参数化查询、对输出做编码、启用安全 cookie、避免明文 secrets。使用该技能时，要明确指出那些可能削弱这些控制的框架行为，例如关闭了 escaping、自定义 auth middleware，或直接拼接 SQL 字符串。

security-and-hardening 技能常见问题

只适合大型审计项目吗？

不是。security-and-hardening 同样适用于处理敏感数据的小功能。哪怕只是一个 webhook handler 或上传表单，只要它接收外部输入或改变了信任边界，就足以使用这个技能。

它和普通 prompt 有什么不同？

普通 prompt 可能只是要求“给出安全最佳实践”，最后得到一堆泛化建议。而 security-and-hardening skill 更偏向决策和落地：它会把回答引导到边界校验、防御性默认配置，以及与当前代码路径相匹配的具体修复方案上。

新手也能用吗？

可以，前提是你能把功能描述清楚。对新手来说，最有价值的做法是明确给出路由、数据类型和框架信息。这样一来，这个技能就能产出比通用安全清单更可执行的加固方案。

什么情况下不该用？

如果只是做纯样式改动、低风险静态内容，或安全根本不在验收标准里，就不建议使用。若代码不处理用户输入、secrets、sessions 或外部调用，那么 security-and-hardening skill 大概率没有必要。

如何改进 security-and-hardening 技能的使用效果

针对攻击面写得越具体越好

输入越好，加固建议就越准确。要明确说明哪里可能被攻击、哪些数据敏感、边界在哪里。比如，“review this file upload flow for path traversal, MIME spoofing, and unsafe storage” 就明显比“make uploads safer”更有用。

要求检查项，不要只要口号

最有价值的 security-and-hardening skill 输出，会直接点名具体控制措施：参数化 SQL、输出编码、cookie flags、CSRF 处理、secrets 管理、传输安全。如果你想得到更好的结果，应该要求给出代码级改动，并解释每项改动为什么能阻断真实攻击。

从风险排序推进到实现细节

先抓最高风险路径，再逐步细化。一个强力的 security-and-hardening guide workflow 是：先请求威胁审查，再要求给出修补版本，最后再做一轮针对 headers、auth 边界情况和依赖风险的复查。这样可以降低第一轮回答过度聚焦低价值问题的概率。

提供会影响修复方案的技术栈细节

请说明框架、auth 库、数据库，以及部署环境。安全加固在 Express、Next.js、Rails、Django 和 serverless 架构之间差异很大，尤其体现在 sessions、headers 和输入校验上。技术栈描述越精确，做 security-and-hardening for Security Audit 时收到不匹配建议的概率就越低。