菜单
Security engineering principles: threat modeling, cryptography, access control, privacy, secure development, physical/operational security, and economics of trust. Covers adversarial thinking, protocol design, tamper resistance, and assurance.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ayush488-glitch/agentic-swe-kit --skill security-engineering命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when designing, building, evaluating, or operating AI agent systems in production — agent architecture, orchestration patterns, RAG pipelines, evaluation, observability, guardrails, and domain-specific deployment.
Use when starting, reviewing, or building any production-grade software or AI-native system. Orchestrates the full 20-phase production lifecycle, routes to the right domain skills at each phase, and guides the agent through every engineering layer from cognitive design to continuous learning.
Use when designing, evaluating, or debugging data-intensive systems — storage engines, replication, partitioning, transactions, distributed consistency, batch/stream processing, or encoding.
基于 SOC 职业分类
正在显示 SKILL.md
| name | security-engineering |
| title | Security Engineering |
| category | swe-foundations |
| description | Security engineering principles: threat modeling, cryptography, access control, privacy, secure development, physical/operational security, and economics of trust. Covers adversarial thinking, protocol design, tamper resistance, and assurance. |
| trigger_conditions | ["Use this when designing authentication, authorization, or access control for a system","Use this when threat modeling a new feature, service, or infrastructure change","Use this when choosing or reviewing a cryptographic primitive, protocol, or key management scheme","Use this when handling sensitive data — PII, financial records, credentials, health data","Use this when building systems with physical security requirements (hardware, payments, IoT)","Use this when evaluating security controls for effectiveness vs. security theater","Use this when privacy requirements or inference risks are involved","Use this when writing security requirements, performing a security review, or preparing for audit","Use this when a system involves economic incentives that could misalign with security goals","Use this when assessing assurance claims, compliance requirements, or SDL processes"] |
| tags | ["security","cryptography","access-control","privacy","threat-modeling","phase-2","swe-foundations"] |
| phase | 2 |
| wiki_path | output/wiki/security-engineering/concepts/ |
Security has four interdependent pillars: Policy (what to protect), Mechanism (how), Assurance (evidence it works), Incentives (who bears cost/gain). Weakness in any one breaks the whole.
Always do threat modeling before designing controls. Identify specific adversary categories (nation-state, criminal, insider, opportunist) and scope threats to realistic opponents — generic "attacker" threat models miss key mitigations and over-engineer for irrelevant threats.
Never confuse security theater with real protection. Visible controls that look strong but provide no actual resistance waste budget and create false confidence. Test controls against actual attack paths.
Access control belongs in the mechanism layer, not just policy. Choose DAC vs MAC vs RBAC based on trust model: DAC for user-controlled data, MAC for multi-level confidentiality, RBAC for organizational roles. TOCTTOU is a common implementation failure — check and use must be atomic.
Cryptography is a component, not a solution. Cryptographic strength is useless if key management fails, protocols have logic flaws, or side-channel leakage exposes secrets. Always evaluate the full stack: algorithm + mode + protocol + implementation + key lifecycle.
Human factors are not optional. Security mechanisms fail when cognitive load exceeds user capacity (Whitten-Tygar). Apply affordances, nudges, and choice architecture to make the secure path the path of least resistance.
Economics drives security outcomes. Misaligned incentives — where the party responsible for security doesn't bear the cost of failure — produce persistent vulnerabilities. Externalities, market lemons, and network lock-in all degrade security. Fix incentives before adding mechanisms.
Privacy is contextual integrity, not secrecy. Information flows are appropriate when they match the norms of the context in which data was shared. Re-identification risks exist even in aggregate statistical releases — apply differential privacy for query-based access.
Physical security follows Deter-Detect-Alarm-Delay-Respond. Each layer buys time for the next. Tamper-evident beats tamper-proof as a realistic goal — make attacks visible and expensive, not impossible.
For high-assurance systems: minimize the Trusted Computing Base (TCB). The smaller the component that must be trusted absolutely, the easier verification becomes. Hardware roots of trust (TPM, enclaves) anchor the chain.
Secure development is a lifecycle discipline, not a gate. SDL, DevSecOps, and continuous assurance require integrating threat modeling, static analysis, fuzz testing, and pen-testing at every phase — not just pre-release.
Side channels are real attack surfaces. Timing, power, EM emissions, and cache behavior leak cryptographic secrets even when algorithms are mathematically sound. For security-critical implementations, validate countermeasures (DPA resistance, constant-time code, TEMPEST shielding).
| Concept Page | What It Covers |
|---|---|
| Security-Foundations | PMAI framework, security theater detection, hack-as-loophole, vulnerability taxonomy |
| Threat-Modeling | Adversary taxonomy, threat scoping, abusability analysis, ABCD threat categories |
| Human-Factors-and-Usability | Skill-Rule-Knowledge errors, affordances, dual-process cognition, nudge design |
| Protocol-Security | Protocol robustness principles, formal verification, key derivation, forward secrecy |
| Cryptography | Perfect secrecy, symmetric vs asymmetric, modes of operation, concrete security |
| Advanced-Cryptographic-Engineering | HSMs, enclaves, TANSTAAFL tradeoffs, crypto-policy entanglement |
| Access-Control | ACL vs capabilities, DAC/MAC/RBAC, protection domains, TOCTTOU |
| Multilevel-Security | Bell-LaPadula, MLS/IFC, compartmentation, Chinese Wall, multilateral security |
| Privacy-and-Inference-Control | Differential privacy, cell suppression, tracker attacks, re-identification waves |
| Economics-of-Security | Misaligned incentives, externalities, market lemons, network lock-in |
| Physical-Security | CPTED, defensible space, deter-detect-alarm-delay-respond, ROC tradeoffs |
| Financial-Security-Controls | Double-entry bookkeeping, dual control, separation of duty, audit trails |
| Metering-and-Token-Security | Key diversification, token binding, grey-listing, offline fraud tolerance |
| Critical-Systems-Security | Shared control, permissive action links, defense in depth, subliminal channels |
| Security-Printing-and-Seals | Three-level inspection, whole life-cycle assurance, predator-prey coevolution |
| Biometrics | EER, ROC tradeoffs, attended vs unattended operation, goats exclusion |
| Tamper-Resistance | FIPS 140 levels, attack-defense arms race, hardware roots of trust |
| Side-Channel-Security | Side-channel taxonomy, DPA attacks, TEMPEST/EMSEC, covert vs side channels |
| Network-Security | Zero Trust/BeyondCorp, deperimeterization, certificate transparency, power-law vulnerability |
| Mobile-and-Phone-Security | Network vs device compromise duality, ecosystem-level security lifting, exploitation cycle |
| Electronic-Warfare | EW priority inversion, electronic warfare triad, hybrid warfare coordination |
| DRM-and-IP-Protection | DRM encryption+license, traitor tracing, watermarking, trusted rendering pipeline |
| Emerging-Technology-Threats | Adversarial ML, hype cycle, complexity boundary, AI/autonomous vehicle threats |
| Surveillance-and-Privacy-Policy | Surveillance capitalism, crypto wars, GDPR localisation, security industrial complex |
| Secure-Development-and-Assurance | SDL, DevSecOps, risk registers, ALE, safety-security convergence |
| Distributed-Architecture-Security | Byzantine failure model, naming scope, publish-register-notify, tiered stand-in processing |
Deploying crypto without key management: Adding AES/RSA without planning key rotation, revocation, and storage is not security — it creates a false sense of protection. Fix: define the full key lifecycle (generation, distribution, storage, rotation, revocation) before choosing an algorithm.
Treating compliance as security: Passing a checklist audit does not mean the system is secure. Compliance measures lag real threats. Fix: run threat models against current adversaries, not against the compliance framework's threat model.
Building security as a perimeter: Treating the network boundary as the trust boundary fails the moment one internal host is compromised. Fix: implement Zero Trust — authenticate and authorize every request, assume breach, segment microscopically.
Ignoring human factors: Security mechanisms that add friction get bypassed. Password rotation policies produce weak passwords; complex UIs get disabled. Fix: apply usability testing to security controls; measure actual user behavior against assumed behavior.
Specifying but not enforcing separation of duty: Requiring SoD in policy but implementing it in a single database account negates the control. Fix: enforce SoD at the mechanism layer — different credentials, different processes, different audit trails.
Over-engineering against low-probability threats: Spending heavily on nation-state-grade protections for systems facing only opportunist attackers misallocates budget. Fix: match control strength to realistic adversary category; use threat model to prioritize.
Assuming encryption hides timing: Even with strong encryption, variable response times leak information about data content or processing path. Fix: add constant-time operations and noise for timing-sensitive paths; consider statistical side-channel testing.
Treating assurance as one-time: A security assessment done at release provides no evidence about the system's security six months later after code changes and new threats. Fix: implement continuous assurance — automated SAST/DAST in CI, periodic pen-tests, red-team exercises.