@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/cursor/security-memory-safety/SKILL.md

@@ -0,0 +1,234 @@
+# Memory Safety
+
+> Memory corruption vulnerabilities account for 70% of critical CVEs in C/C++ codebases --
+> choose memory-safe languages by default, and when you cannot, understand the vulnerability
+> classes and mitigations
+
+## When to Use
+
+- Choosing a language for a new system or component, especially systems-level code
+- Reviewing C, C++, or other memory-unsafe code for security vulnerabilities
+- Understanding why Rust, Go, Java, C#, Python, and JavaScript are considered "memory-safe"
+  and what guarantees that label provides
+- Evaluating third-party native dependencies (C/C++ libraries) for memory safety risk
+- Designing a security architecture that interacts with native code via FFI, JNI, or WASM
+- Assessing whether compiler flags and runtime mitigations are properly configured
+
+## Threat Context
+
+Memory safety vulnerabilities are the most dangerous class of software bugs because they
+enable arbitrary code execution -- the attacker does not merely read data or cause a crash,
+they execute code of their choosing on the target system:
+
+- **Microsoft's data (2006-2018)**: 70% of all CVEs assigned to Microsoft products were
+  caused by memory safety issues. This finding was consistent across Windows, Office,
+  Internet Explorer, and Edge.
+- **Google Chrome (2015-2020)**: 70% of high-severity Chrome security bugs were memory
+  safety vulnerabilities, primarily use-after-free and buffer overflow in the C++ codebase.
+- **Heartbleed (2014, CVE-2014-0160)**: A buffer over-read in OpenSSL's heartbeat extension
+  allowed attackers to read up to 64KB of server memory per request. Exposed private keys,
+  session tokens, user passwords, and encrypted content from 17% of the internet's HTTPS
+  servers. The bug existed for 2 years before discovery.
+- **Android (2019-2023)**: Memory safety bugs accounted for 76% of Android vulnerabilities
+  in 2019. After Google began writing new code in Rust and Kotlin, memory safety CVEs
+  dropped to 24% by 2023 -- without fixing existing C/C++ code, simply because fewer new
+  memory bugs were introduced.
+- **US Government recommendation**: In 2023-2024, CISA, NSA, and the White House Office of
+  the National Cyber Director formally recommended that organizations transition to
+  memory-safe languages for new development and critical rewrites.
+
+The 70% statistic means that choosing a memory-safe language eliminates the majority of the
+vulnerabilities that enable remote code execution, privilege escalation, and information
+disclosure. Logic bugs, authentication bugs, and authorization bugs constitute the remaining
+30% -- they remain regardless of language choice.
+
+## Instructions
+
+1. **Choose memory-safe languages for all new projects.** The default choice for any new
+   system, service, or component should be a memory-safe language unless there is a specific,
+   documented technical reason requiring otherwise:
+   - **Rust**: Compile-time ownership and borrowing guarantees eliminate use-after-free,
+     double-free, and data races without a garbage collector. Zero-cost abstractions mean no
+     runtime overhead. Suitable for systems programming, embedded, and performance-critical
+     applications.
+   - **Go**: Garbage-collected, bounds-checked arrays and slices, no pointer arithmetic.
+     Suitable for network services, infrastructure tooling, and concurrent systems.
+   - **Java/Kotlin**: JVM garbage collection eliminates manual memory management. No pointer
+     arithmetic. Suitable for enterprise applications, Android (Kotlin), and large-scale
+     backend services.
+   - **C# / .NET**: Managed memory with garbage collection. Suitable for enterprise
+     applications, game development (Unity), and Windows ecosystem.
+   - **Python, JavaScript/TypeScript, Ruby**: Interpreted/JIT languages with automatic
+     memory management. Suitable for web applications, scripting, data processing, and rapid
+     development.
+   - **Swift**: Reference counting with compile-time safety checks. Suitable for Apple
+     platform development and increasingly for server-side applications.
+
+2. **Understand the memory safety vulnerability taxonomy.** Each vulnerability class has a
+   distinct mechanism, exploitation technique, and set of mitigations:
+   - **Buffer overflow (stack)**: Writing beyond the allocated boundary of a stack-allocated
+     buffer overwrites adjacent stack data, including the return address. The attacker
+     replaces the return address with a chosen value, redirecting execution when the function
+     returns. Stack canaries detect overflow. ASLR randomizes addresses. DEP/NX marks the
+     stack non-executable. Return-Oriented Programming (ROP) chains existing code gadgets to
+     bypass DEP.
+   - **Buffer overflow (heap)**: Writing beyond a heap-allocated buffer corrupts adjacent
+     heap metadata or objects. Exploitation overwrites function pointers, vtable entries, or
+     heap allocator metadata to redirect execution.
+   - **Use-after-free**: Accessing memory after it has been freed. If the freed memory is
+     reallocated to a new object, the dangling pointer reads or writes the new object's
+     data, enabling type confusion. The attacker controls the new object's contents, gaining
+     arbitrary read/write capability.
+   - **Double-free**: Freeing the same memory twice corrupts the heap allocator's free list.
+     An attacker can manipulate the corrupted free list to control subsequent allocations,
+     eventually overlapping an allocation with a target object.
+   - **Integer overflow/underflow**: Arithmetic that wraps around the integer boundary.
+     `size = count * element_size` overflows if both values are large, producing a small
+     allocation. The subsequent write overflows the undersized buffer. Use checked arithmetic
+     (`checked_mul` in Rust, `Math.addExact` in Java) or validate input ranges before
+     arithmetic.
+   - **Format string vulnerability**: Passing user-controlled input as a format string to
+     `printf` or equivalent functions. The attacker uses format specifiers (`%x` to read
+     stack memory, `%n` to write to memory) to achieve arbitrary read/write.
+   - **Null pointer dereference**: Accessing memory through a null pointer. In userspace on
+     modern OSes, this causes a segfault (DoS). In kernel code or when the zero page is
+     mappable (older Linux kernels), it can be exploitable for privilege escalation.
+
+3. **When using C/C++, apply layered defense-in-depth mitigations.** No single mitigation is
+   sufficient; all should be enabled simultaneously:
+   - **Compiler hardening flags**: `-fstack-protector-strong` (stack canaries for functions
+     with buffers), `-D_FORTIFY_SOURCE=2` (bounds-checked versions of libc functions like
+     memcpy, sprintf), `-fPIE -pie` (position-independent executable, required for full
+     ASLR), `-Wformat -Wformat-security` (format string warnings)
+   - **OS-level mitigations**: ASLR (Address Space Layout Randomization -- randomizes base
+     addresses of stack, heap, libraries, and executable), DEP/NX (Data Execution Prevention
+     / No-Execute -- marks data memory as non-executable), Control Flow Integrity (CFI --
+     restricts indirect call/jump targets to valid function entries)
+   - **Static analysis**: Run Coverity, clang-tidy (with security-focused checks), cppcheck,
+     or PVS-Studio in CI. Static analysis finds bugs without executing the code but produces
+     false positives and misses runtime-dependent issues.
+   - **Dynamic analysis in CI**: AddressSanitizer (ASan) detects buffer overflows,
+     use-after-free, and double-free at runtime with 2x slowdown. MemorySanitizer (MSan)
+     detects reads of uninitialized memory. UndefinedBehaviorSanitizer (UBSan) detects
+     integer overflow, null pointer dereference, and other undefined behavior. Run the test
+     suite with all three sanitizers enabled.
+   - **Fuzzing**: AFL++, libFuzzer, or Honggfuzz for automated input generation. Fuzzing
+     discovers memory bugs by executing the program with millions of mutated inputs and
+     detecting crashes via sanitizers. Integrate fuzzing into CI as a continuous process,
+     not a one-time activity.
+
+4. **Isolate native/FFI boundaries as trust boundaries.** When a memory-safe application
+   calls into C/C++ libraries via FFI (Foreign Function Interface), JNI (Java Native
+   Interface), or WASM, treat the native boundary as a security boundary. Validate all
+   inputs passed to native functions -- a buffer overflow in the native library can corrupt
+   the memory-safe application's heap. Limit the native component's access to system
+   resources. Use sandboxing (seccomp-bpf on Linux, WASM linear memory isolation,
+   pledge/unveil on OpenBSD) to contain exploitation of the native component.
+
+5. **Evaluate native dependencies in your supply chain.** For every C/C++ dependency: Is
+   there a memory-safe alternative? (rustls instead of OpenSSL, ring instead of libcrypto,
+   image-rs instead of libpng.) Is the dependency actively maintained? What is its CVE
+   history -- how many memory safety CVEs in the last 3 years, and how quickly were they
+   patched? Does the project use sanitizers and fuzzing in CI? Dependencies with poor memory
+   safety hygiene are ticking time bombs in your supply chain.
+
+## Details
+
+- **How a stack buffer overflow enables code execution -- the full chain**: A function
+  allocates a 64-byte buffer on the stack. The return address is stored at a known offset
+  above the buffer. The attacker provides 80 bytes of input: 64 bytes to fill the buffer,
+  some padding to reach the return address, and a new address value. When the function
+  returns, `ret` pops the attacker-controlled address into the instruction pointer. Classic
+  exploitation jumps to injected shellcode on the stack (blocked by DEP/NX) or to a known
+  library function like `system()` (blocked by ASLR). Modern exploitation uses
+  Return-Oriented Programming (ROP): the attacker chains short instruction sequences
+  ("gadgets") already present in executable memory, each ending in `ret`, to build arbitrary
+  computation. Stack canaries add a random value between the buffer and the return address;
+  overflow that corrupts the return address also corrupts the canary, which is detected
+  before `ret` executes. All mitigations (canary + ASLR + DEP + CFI) should be enabled
+  simultaneously because each has known bypass techniques.
+
+- **Rust's ownership model -- how it prevents memory bugs at compile time**: Every value in
+  Rust has exactly one owner. When ownership is transferred (moved), the original binding is
+  invalidated -- using it is a compile error. References (borrows) follow strict rules: any
+  number of immutable references (`&T`) or exactly one mutable reference (`&mut T`), never
+  both simultaneously. The borrow checker enforces these rules at compile time.
+  Use-after-free is impossible because the compiler tracks lifetimes and rejects code where
+  a reference outlives the data it points to. Double-free is impossible because a value is
+  dropped exactly once when its owner goes out of scope. Data races are impossible because
+  the aliasing rules prevent shared mutable state across threads. The `unsafe` block opts
+  out of borrow checker enforcement for specific operations (raw pointer dereferencing, FFI
+  calls, inline assembly). Every `unsafe` block in a codebase should be audited for
+  correctness because the compiler cannot verify its safety invariants.
+
+- **WebAssembly (WASM) as a sandboxing mechanism for native code**: Compile C/C++ code to
+  WebAssembly and execute it in a sandboxed runtime (Wasmtime, Wasmer, WasmEdge). WASM
+  provides strong isolation: linear memory is a contiguous byte array that the module can
+  access, but the module cannot access host memory outside this array. A buffer overflow in
+  the WASM module is confined to the module's linear memory -- it cannot corrupt the host
+  process. System calls are mediated through an explicit import/export interface (WASI for
+  filesystem, network, environment). The module can only access capabilities explicitly
+  granted by the host. This makes WASM an effective containment strategy for running
+  untrusted or memory-unsafe code within a memory-safe host application.
+
+- **The 70% statistic in full context**: Microsoft and Google's data shows that 70% of
+  critical and high-severity CVEs are memory safety bugs. This does not mean 70% of all bugs
+  are memory-related -- it means 70% of the bugs that achieve the worst security outcomes
+  (remote code execution, privilege escalation, arbitrary information disclosure) are memory
+  corruption. Logic bugs, authentication bypasses, authorization flaws, injection
+  vulnerabilities, and business logic errors constitute the remaining 30%. Switching to a
+  memory-safe language eliminates the 70% but does not address the 30%. A comprehensive
+  security posture requires both memory safety and secure application design.
+
+## Anti-Patterns
+
+1. **"Our C/C++ code is carefully written, so memory safety is not a concern."** Every large
+   C/C++ codebase contains undiscovered memory safety bugs. The question is not whether bugs
+   exist but whether they are found by the developer (via tooling and auditing) or by the
+   attacker (via fuzzing and reverse engineering). Google, Microsoft, and Apple --
+   organizations with world-class C/C++ expertise -- still find hundreds of memory safety
+   bugs per year. Use tooling (sanitizers, fuzzing, static analysis) and prefer memory-safe
+   languages for new code.
+
+2. **Disabling compiler security flags for performance.** Stack canaries
+   (`-fstack-protector-strong`) add a single comparison per function return. ASLR adds no
+   runtime overhead. `_FORTIFY_SOURCE=2` replaces libc calls with bounds-checked versions
+   that have negligible overhead for non-trivial programs. Disabling these mitigations to
+   save microseconds creates exploitable vulnerabilities. Profile the actual performance
+   impact before considering removal -- in virtually all applications, it is unmeasurable.
+
+3. **Trusting data across FFI/native boundaries without validation.** Passing
+   user-controlled strings, buffer lengths, or indices directly into native functions without
+   bounds checking. The memory-safe language provides safety within its own runtime, but
+   `unsafe` FFI calls bypass all guarantees. Treat every FFI call as crossing a trust
+   boundary: validate buffer sizes, check null pointers, clamp indices to valid ranges, and
+   handle native-side errors without crashing the host process.
+
+4. **Ignoring integer overflow in allocation size calculations.**
+   `size_t allocation_size = user_count * sizeof(struct Entry)` overflows silently in C if
+   `user_count` is attacker-controlled and large enough. The resulting small allocation is
+   followed by a write that overflows the buffer. Use checked arithmetic (Rust:
+   `checked_mul`, Java: `Math.multiplyExact`, C: compiler builtins like
+   `__builtin_mul_overflow`) or validate that input values are within expected ranges before
+   performing arithmetic used in allocations.
+
+5. **"We use a memory-safe language, so memory safety is not our problem."** Memory-safe
+   languages frequently call into memory-unsafe native code. Python's most popular libraries
+   (NumPy, Pillow, cryptography) are backed by C extensions. Node.js has native addons and
+   ships with C++ bindings (libuv, V8). Java applications use JNI for performance-critical
+   code and database drivers. Go uses cgo for C library integration. Every native boundary
+   is a potential source of memory corruption. Audit native dependencies, prefer
+   pure-language alternatives where they exist, and sandbox native components where they
+   do not.
+
+6. **Running sanitizers only in development, not in CI.** AddressSanitizer,
+   MemorySanitizer, and UBSan find bugs that no amount of code review catches. Running them
+   locally but not in CI means the test suite executes without sanitizer coverage on every PR
+   merge. Configure CI to run the full test suite with sanitizers enabled on every commit.
+   The 2x runtime overhead of ASan is acceptable for CI pipelines.
+
+7. **Treating fuzzing as a one-time activity.** Running a fuzzer for a few hours, finding
+   some bugs, fixing them, and never fuzzing again. Memory safety bugs are introduced
+   continuously as code changes. Integrate continuous fuzzing (OSS-Fuzz, ClusterFuzz, or a
+   self-hosted fuzzing cluster) into the development lifecycle. Fuzzing corpora grow over
+   time, covering more code paths and finding deeper bugs.

package/dist/agents/skills/cursor/security-memory-safety/skill.yaml

@@ -0,0 +1,39 @@
+name: security-memory-safety
+version: "1.0.0"
+description: Memory safety vulnerabilities -- buffer overflows, use-after-free, double-free -- and mitigation through safe languages, bounds checking, and memory-safe abstractions
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-injection-families
+  - security-race-conditions
+  - security-deserialization-attacks
+  - owasp-injection-prevention
+stack_signals: []
+keywords:
+  - memory safety
+  - buffer overflow
+  - use-after-free
+  - double-free
+  - stack overflow
+  - heap overflow
+  - bounds checking
+  - Rust
+  - safe languages
+  - memory corruption
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/security-mfa-design/SKILL.md

@@ -0,0 +1,150 @@
+# Multi-Factor Authentication Design
+
+> Something you know, something you have, something you are -- combining authentication factors so that compromising one factor alone is insufficient to gain access
+
+## When to Use
+
+- Adding MFA to an existing authentication system
+- Choosing between TOTP, WebAuthn/passkeys, SMS, and email as second factors
+- Designing recovery flows for users who lose their second factor
+- Implementing step-up authentication for sensitive operations (payment, account changes)
+- Evaluating the security properties of different MFA factor types
+- Migrating from SMS-based 2FA to phishing-resistant alternatives
+
+## Threat Context
+
+Credential stuffing attacks use billions of leaked username/password combinations from breaches (Collection #1 had 773 million email addresses). Without MFA, every breached password is a working credential. Google reported that SMS-based 2FA blocks 100% of automated bot attacks, 96% of bulk phishing, but only 76% of targeted attacks (because SIM-swap and SS7 interception defeat SMS). WebAuthn/FIDO2 blocks 100% of phishing because the credential is bound to the origin -- a phishing site at `evil.com` cannot trigger a credential scoped to `bank.com`.
+
+The 2022 Uber breach started with MFA fatigue: the attacker spammed push notifications until the employee approved one at 1AM. The 2023 MGM Resorts breach began with a social engineering call to the help desk that bypassed MFA entirely by convincing the support agent to reset the employee's credentials. These attacks show that MFA design must consider the human element, not just the cryptographic protocol.
+
+## Instructions
+
+1. **Understand the three factor categories.** Knowledge (passwords, PINs, security questions), Possession (phone, hardware key, authenticator app), Inherence (fingerprint, face, iris). True MFA requires factors from at least two different categories. Two passwords are not MFA. A password plus a TOTP code (possession of the phone/app) is MFA. A password plus a security question is single-factor (both are knowledge). A passkey with biometric unlock combines possession (device) and inherence (fingerprint) in a single interaction.
+
+2. **Prefer phishing-resistant factors.** WebAuthn/FIDO2 (hardware keys like YubiKey, platform authenticators like Touch ID/Windows Hello, synced passkeys) is phishing-resistant because the browser binds the credential to the relying party origin. An attacker's phishing site at `evil-bank.com` cannot trigger a WebAuthn credential registered for `bank.com`. TOTP is phishable -- an attacker shows a fake login page, the user types the TOTP code, the attacker replays it to the real site in real time before the 30-second window expires. SMS is phishable and additionally vulnerable to SIM swap and SS7 attacks. Security ranking: WebAuthn > TOTP > Email > SMS.
+
+3. **Implement TOTP correctly.** Use RFC 6238 with the following parameters:
+   - Hash algorithm: SHA-1 (the standard -- SHA-256/512 are allowed but not universally supported by authenticator apps like Google Authenticator)
+   - Digits: 6
+   - Time step: 30 seconds
+   - Validation window: +/- 1 time step (90 seconds total) to accommodate clock drift
+
+   Store the shared secret encrypted at rest using a KMS-managed key. Display the QR code using the `otpauth://totp/Issuer:account?secret=BASE32SECRET&issuer=Issuer` URI format. Generate and offer backup codes: 8-10 single-use codes, 8 alphanumeric characters each, stored hashed with a unique salt per code.
+
+4. **Design the enrollment flow.** Present the QR code for TOTP enrollment alongside the raw Base32 secret for manual entry. Require the user to enter a valid TOTP code to confirm successful enrollment before activating MFA on the account -- this prevents users from scanning the QR code incorrectly and locking themselves out. For WebAuthn, use the `navigator.credentials.create()` API with `attestation: "none"` (sufficient for most applications). Allow and encourage users to register multiple credentials (backup hardware key, phone authenticator, etc.).
+
+5. **Design the recovery flow.** Recovery codes are the safety net -- display them exactly once at enrollment, store only their hashes in the database. Require the user to acknowledge they have saved them (checkbox or re-entry of one code) before completing enrollment.
+
+   For account recovery without any second factor: require identity verification through one of these approaches:
+   - Support ticket with government ID verification (high assurance, high friction)
+   - Time-delayed recovery: send notification to all registered emails, impose a 48-72 hour waiting period, allow the existing account holder to cancel the recovery during the waiting period
+   - Admin-assisted recovery with manager approval
+
+   Never allow a recovery flow that is weaker than the MFA it replaces -- that makes the recovery path the real authentication mechanism and the MFA merely theater.
+
+6. **Implement step-up authentication.** For sensitive operations (changing email, changing password, authorizing large payments, viewing sensitive data, downloading bulk exports), require a fresh MFA challenge even if the session is already authenticated. Use a short-lived "elevated" session state (15 minutes) that expires and requires re-authentication for subsequent sensitive operations. This limits the blast radius of session hijacking: a stolen session cookie cannot change the account email without the second factor.
+
+7. **Defend against MFA fatigue.** Rate-limit push notifications (max 3 unanswered prompts per hour). Use number matching instead of simple approve/deny: display a two-digit number on the login screen and require the user to enter it in the authenticator app, proving they are looking at the actual login attempt rather than blindly approving. Log and alert on repeated denied MFA prompts as a potential attack indicator. Microsoft, Google, and Duo all added number matching after the Uber breach demonstrated the real-world impact of MFA fatigue.
+
+## Details
+
+### WebAuthn, FIDO2, and Passkeys
+
+WebAuthn is the W3C browser API for public-key credential creation and authentication. FIDO2 is the umbrella term covering WebAuthn (browser API) and CTAP2 (client-to-authenticator protocol for hardware keys). Passkeys are a specific implementation of WebAuthn where the credential private key is synced across the user's devices via a platform credential manager (iCloud Keychain, Google Password Manager, 1Password).
+
+**Registration ceremony:** The relying party (your server) generates a challenge (random bytes). The browser calls `navigator.credentials.create()` with the challenge, relying party ID (your domain), and user information. The authenticator generates a new key pair, stores the private key, and returns the public key, credential ID, and signed attestation. The server stores the public key and credential ID associated with the user account.
+
+**Authentication ceremony:** The server generates a challenge and sends it with a list of allowed credential IDs. The browser calls `navigator.credentials.get()`. The authenticator finds the matching credential, signs the challenge with the private key, and returns the assertion. The server verifies the signature against the stored public key.
+
+Passkeys eliminate passwords entirely -- they are not just a second factor but a complete replacement for password-based authentication. The user experience: click "Sign in," select the passkey from the platform prompt, authenticate with biometrics or device PIN. No password to remember, no TOTP code to type, no SMS to wait for.
+
+### TOTP vs HOTP
+
+TOTP (Time-based One-Time Password, RFC 6238) derives the OTP from the current Unix timestamp divided by the time step (default 30 seconds). HOTP (HMAC-based One-Time Password, RFC 4226) derives the OTP from a monotonically increasing counter maintained by both server and authenticator.
+
+TOTP is preferred because: (1) codes expire automatically after 30 seconds, limiting the replay window; (2) no counter synchronization is needed; (3) HOTP can desynchronize if the user generates codes without submitting them (the authenticator counter advances but the server counter does not), requiring a look-ahead window that weakens security.
+
+Both compute `HMAC-SHA-1(secret, counter_or_time)` and truncate the result to a 6-digit decimal code using dynamic truncation: extract 4 bytes from an offset determined by the last nibble of the HMAC output, interpret as a 31-bit unsigned integer, and take modulo 10^6.
+
+### Hardware Security Keys
+
+Hardware security keys (YubiKey, Google Titan, SoloKeys) provide the strongest MFA guarantees because:
+
+- The private key is generated on the device and never leaves it -- there is no secret to steal from a server breach
+- The key is bound to the relying party origin, providing phishing resistance identical to passkeys
+- The key requires physical presence (touch or biometric) to sign, preventing remote exploitation
+- Hardware keys are resistant to malware -- even if the user's device is fully compromised, the attacker cannot extract the key or use it without physical access
+
+Deployment considerations:
+
+- **Cost:** $25-50 per key, plus users should have two keys (primary + backup). Budget $50-100 per user for hardware-based MFA.
+- **Logistics:** Keys must be physically distributed to employees. Remote employees need keys shipped securely. Lost keys require a recovery flow.
+- **Compatibility:** USB-A, USB-C, NFC, and Lightning form factors exist. Ensure compatibility with the user's devices. NFC keys work with mobile devices.
+- **Protocol support:** Modern keys support FIDO2/WebAuthn, which is the preferred protocol. Older keys may only support U2F (the predecessor) or Yubico OTP.
+- **User training:** Hardware keys require user education on registration, daily use, and what to do if the key is lost. Provide clear documentation and a self-service portal for registering backup keys.
+
+For organizations with high-security requirements (financial services, government, infrastructure providers), hardware security keys for all employees with access to production systems or sensitive data is the strongest available MFA deployment. Google reported zero successful phishing attacks against its 85,000+ employees after mandating hardware keys in 2017.
+
+The investment in hardware keys pays for itself after preventing a single credential-based breach, which averages $4.45 million according to IBM's 2023 Cost of a Data Breach Report.
+
+### SMS as MFA -- Risk Analysis
+
+SMS-based verification is the weakest commonly deployed second factor:
+
+- **SIM swap attacks:** The attacker contacts the carrier, impersonates the victim, and convinces the carrier to transfer the phone number to a new SIM. The 2019 Twitter CEO Jack Dorsey account compromise used SIM swap. Success rates remain disturbingly high despite carrier awareness.
+- **SS7 protocol vulnerabilities:** The Signaling System 7 network that routes SMS messages has no authentication between carriers. Any entity with SS7 access can intercept SMS messages. SS7 access can be purchased from telecom resellers for a few hundred dollars.
+- **Real-time phishing:** An attacker's phishing site prompts the victim for their SMS code and relays it to the real site in real time, completing authentication before the code expires. Automated phishing kits (EvilGinx, Modlishka) handle this transparently.
+
+NIST SP 800-63B (Digital Identity Guidelines) classifies SMS as a "restricted" authenticator: agencies must offer an alternative and must assess SMS-specific risks. If your application must offer SMS, treat it as the lowest-tier option and actively encourage migration to TOTP or WebAuthn through in-app prompts.
+
+### MFA Enrollment UX Considerations
+
+MFA adoption rates depend heavily on the enrollment experience. Poor UX leads to low opt-in rates (when MFA is optional) or high support ticket volume (when MFA is mandatory):
+
+- **Progressive enrollment:** Do not force MFA setup during initial registration. Allow the user to complete registration first, then prompt for MFA setup on the second or third login with clear messaging about why MFA matters.
+- **QR code + manual entry:** Always provide both the QR code and the raw Base32 secret text for TOTP enrollment. Some users cannot scan QR codes (accessibility, screen reader users, users on the same device as the authenticator app).
+- **Confirmation step:** After scanning the QR code, require the user to enter a valid TOTP code before activating MFA. This catches misconfigured authenticator apps before the user locks themselves out.
+- **Backup code emphasis:** Display backup codes prominently and require explicit acknowledgment. Consider asking the user to re-enter one backup code to prove they saved them. Many users skip this step and later need account recovery.
+- **Multiple factor registration:** Encourage (or require) registration of at least two independent factors at enrollment time. "Add a backup method" should be a prominent call-to-action, not a hidden settings option.
+
+### Adaptive MFA
+
+Risk-based adaptive MFA adjusts the authentication challenge based on contextual signals:
+
+- **Low risk** (known device, usual IP, usual time): Skip the MFA challenge or accept a remembered device token
+- **Medium risk** (new IP, unusual time): Require TOTP or push notification
+- **High risk** (new device, impossible travel, high-value operation): Require WebAuthn or hardware key
+
+Signals to evaluate: device fingerprint, IP address and geolocation, login time patterns, velocity (multiple failed attempts), impossible travel (login from two geographically distant locations within minutes), and the sensitivity of the requested operation. Adaptive MFA reduces friction for legitimate users while maintaining strong security for anomalous patterns.
+
+However, the risk scoring model itself becomes an attack surface. If an attacker can manipulate the signals (using a VPN to match the victim's usual location, spoofing device fingerprints, timing the attack during the victim's usual login hours), they may downgrade the MFA requirement. Adaptive MFA should lower friction but never eliminate the MFA requirement entirely for high-value operations.
+
+### MFA Deployment Strategy
+
+Rolling out MFA to an existing user base requires careful planning:
+
+1. **Soft launch (optional enrollment):** Make MFA available but not required. Track enrollment rates. Identify UX friction points from support tickets and drop-off analytics.
+
+2. **Incentivized enrollment:** Offer benefits for MFA adoption: priority support, extended session lifetimes, access to beta features. Show users their account security score.
+
+3. **Mandatory for high-privilege users:** Require MFA for administrators, users with access to sensitive data, and users with billing privileges. This is often the minimum for SOC2 and ISO 27001 compliance.
+
+4. **Progressive mandatory rollout:** Expand MFA requirements to all users in waves: new users first (they set up MFA during registration with no disruption), then active users (30-day grace period with increasing urgency of prompts), then remaining users.
+
+5. **Ongoing monitoring:** Track MFA bypass rates (support tickets for account recovery), factor distribution (are users choosing weak factors like SMS?), and step-up authentication success rates. Alert on sudden spikes in MFA reset requests (may indicate a phishing campaign).
+
+## Anti-Patterns
+
+1. **SMS as the only MFA option.** SMS is vulnerable to SIM swap, SS7 interception, and real-time phishing relay. Always offer TOTP as an alternative at minimum. Prefer WebAuthn/passkeys as the primary recommendation and incentivize adoption through reduced friction (passkeys are faster than typing TOTP codes).
+
+2. **Recovery flow that bypasses MFA.** If "forgot my authenticator" sends an email with a magic link that grants full account access, then email is the real authentication mechanism and the MFA provides zero additional security. The recovery path must be at least as strong as the factor it replaces -- otherwise the weakest recovery path defines the system's actual security level.
+
+3. **MFA fatigue through push notification spam.** Simple approve/deny push notifications can be overcome by sending repeated prompts until the user approves one out of frustration, confusion, or at an inattentive moment. Use number matching (requiring the user to enter a displayed code), rate limit unanswered prompts, and alert the security team on patterns of repeated denials.
+
+4. **Storing TOTP secrets in plaintext.** The TOTP shared secret is functionally equivalent to a password -- if the database is breached, the attacker can generate valid TOTP codes for every user. Encrypt TOTP secrets at rest using a KMS-managed envelope encryption key stored separately from the database. Apply the same protection rigor as you would to password hashes.
+
+5. **No backup authentication method.** If a user's only second factor is a single phone and they lose it, they are permanently locked out of their account. Require enrollment of at least two independent factors (e.g., TOTP app + backup codes, or hardware key + phone). Present clear recovery documentation at enrollment time -- not after the user is already locked out and panicking.
+
+6. **TOTP with excessively long validity windows.** Accepting TOTP codes with a +/- 5 time step window (5 minutes total) increases the replay window significantly. An attacker who phishes a TOTP code has 5 minutes to use it instead of 90 seconds. Use +/- 1 time step (90 seconds total) as the standard. If clock drift is a concern, track the observed drift per user and adjust server-side rather than widening the window globally.
+
+7. **MFA for login but not for account recovery.** If the "forgot password" flow sends a reset link via email with no MFA challenge, and the "change email" flow allows changing the recovery email without MFA, then an attacker who compromises the email account can take over the application account by: resetting the password via email, changing the recovery email to their own, and removing the MFA factor. Every account-altering flow must require MFA verification, not just the login flow.

package/dist/agents/skills/cursor/security-mfa-design/skill.yaml

@@ -0,0 +1,41 @@
+name: security-mfa-design
+version: '1.0.0'
+description: Multi-factor authentication design -- TOTP, WebAuthn/passkeys, SMS risks, recovery flows, and step-up authentication for sensitive operations
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-credential-storage
+  - security-session-management
+  - security-authentication-flows
+  - security-cryptographic-randomness
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - MFA
+  - multi-factor authentication
+  - TOTP
+  - WebAuthn
+  - passkeys
+  - FIDO2
+  - two-factor
+  - 2FA
+  - recovery codes
+  - step-up authentication
+  - SMS verification
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/security-microsegmentation/SKILL.md

@@ -0,0 +1,154 @@
+# Microsegmentation
+
+> Isolate every workload behind its own perimeter -- so compromising the web server does
+> not hand the attacker the database, the secrets store, and the internal APIs
+
+## When to Use
+
+- Designing network architecture for a microservices system
+- Implementing zero trust networking within a data center or cloud VPC
+- Reducing blast radius after a service compromise
+- Configuring Kubernetes NetworkPolicies or cloud security groups
+- Auditing east-west traffic (service-to-service) for unauthorized communication
+- Preparing for compliance frameworks that require network segmentation (PCI-DSS, HIPAA)
+
+## Threat Context
+
+Traditional perimeter security (firewall at the edge, flat network inside) fails
+catastrophically when the perimeter is breached. The 2013 Target breach started with
+compromised HVAC vendor credentials and used the flat internal network to reach the POS
+systems -- lateral movement across 40 million credit cards. The 2017 Equifax breach
+exploited a single web application vulnerability and pivoted through unsegmented internal
+systems to access 147 million records. The 2020 SolarWinds attack demonstrated lateral
+movement at national scale: once inside the perimeter, the attacker moved freely between
+systems for months. Microsegmentation limits blast radius: if the web server is
+compromised, it can only reach the services it was explicitly allowed to communicate with.
+Everything else is unreachable.
+
+## Instructions
+
+1. **Map all service-to-service communication flows.** Before writing a single firewall
+   rule, document which services talk to which services, on which ports, using which
+   protocols. This is your baseline. Any communication not in this map should be denied by
+   default. Use network flow logs, service mesh telemetry, or traffic analysis tools to
+   discover actual traffic patterns. In AWS, VPC Flow Logs capture every packet accepted or
+   rejected by security groups. In Kubernetes, Cilium's Hubble provides real-time
+   visibility into all network flows with identity context.
+
+2. **Apply default-deny network policies.** Start with "deny all ingress and egress" for
+   every workload. Then add explicit allow rules for each documented communication flow.
+   In Kubernetes: create a NetworkPolicy with `policyTypes: [Ingress, Egress]` and empty
+   rules (deny-all), then add specific allow rules per service. In cloud: use security
+   groups with deny-all and explicit allow rules. The default in most Kubernetes clusters
+   and cloud VPCs is allow-all -- this must be explicitly corrected as the first step.
+
+3. **Segment by trust level, not just by service.** Group services into trust zones:
+   public-facing (web servers, API gateways), application logic (business services), data
+   stores (databases, caches), management (monitoring, logging, CI/CD). Apply stricter
+   rules at zone boundaries. Data stores should only accept connections from application
+   logic, never from public-facing services directly. Management systems should be in an
+   isolated zone accessible only from specific bastion hosts or jump servers.
+
+4. **Use service identity, not IP addresses.** IP-based rules are fragile in dynamic
+   environments (containers, autoscaling, spot instances). Use service identity (mTLS
+   certificates, SPIFFE IDs, Kubernetes service accounts) to define policies. Service
+   mesh (Istio, Linkerd, Cilium) provides identity-based policy enforcement. When a pod
+   restarts with a new IP, identity-based policies continue to work because they reference
+   the service account, not the ephemeral IP.
+
+5. **Enforce application-layer segmentation.** Network segmentation (L3/L4) blocks
+   unauthorized IP/port combinations but does not prevent an authorized connection from
+   sending malicious requests. Add L7 policies: only allow specific HTTP methods and paths
+   between services. For example, the order service can call `GET /api/inventory` and
+   `POST /api/inventory/reserve` on the inventory service, but cannot call
+   `DELETE /api/inventory/*`. Service mesh authorization policies (Istio
+   AuthorizationPolicy, Cilium L7 policies) enable this granularity.
+
+6. **Monitor and alert on policy violations.** Log denied connections. Alert on unexpected
+   communication patterns. A sudden spike in denied traffic between two services may
+   indicate a compromised service attempting lateral movement. Review flow logs
+   periodically to discover new communication patterns that need policy updates. In
+   production, treat any unexpected denied connection as a potential indicator of
+   compromise until proven otherwise.
+
+## Details
+
+### Microsegmentation vs Traditional VLANs
+
+VLANs segment at the network layer but every host within a VLAN can communicate freely.
+Microsegmentation applies per-workload policies, so two containers on the same host can
+be in different segments. VLANs are insufficient for containerized and cloud-native
+environments where workload density is high and IP addresses are ephemeral. A single
+Kubernetes node may run 50 pods from 20 different services -- VLAN-level segmentation
+treats them all as one trust zone.
+
+### Implementation Technologies
+
+| Technology                | Layer | Identity-Aware | Notes                                                |
+| ------------------------- | ----- | -------------- | ---------------------------------------------------- |
+| Kubernetes NetworkPolicy  | L3/L4 | Label-based    | Requires CNI support (Calico, Cilium, Antrea)        |
+| Cilium Network Policies   | L3-L7 | Yes (eBPF)     | Richest model: L7 HTTP/gRPC, DNS-based egress        |
+| Istio AuthorizationPolicy | L7    | mTLS identity  | Full HTTP method/path control, JWT validation        |
+| AWS Security Groups       | L3/L4 | No             | Instance-level, can reference other security groups  |
+| Azure NSGs                | L3/L4 | No             | Subnet or NIC level, service tags for Azure services |
+| GCP Firewall Rules        | L3/L4 | No             | Network tags or service accounts for targeting       |
+
+For Kubernetes, Cilium provides the richest policy model. For cloud-native without
+Kubernetes, use the cloud provider's security groups with cross-referencing (security
+group A allows traffic from security group B, not from IP ranges).
+
+### PCI-DSS Segmentation Requirements
+
+PCI-DSS requires that the Cardholder Data Environment (CDE) is segmented from all other
+systems. Microsegmentation implements this by: placing CDE components in a dedicated
+segment, allowing only authorized services to communicate with the CDE, logging all CDE
+traffic, and testing segmentation controls annually. Penetration testers must verify that
+non-CDE systems cannot reach CDE systems, and this verification must be documented.
+
+### Blast Radius Analysis
+
+For each service, enumerate what an attacker with full control of that service can reach.
+If compromising the web server gives access to the database, the secrets store, and the
+CI/CD system, the blast radius is the entire system. After segmentation, the web server
+should only reach the API gateway and the application services -- the database and secrets
+store are unreachable. Perform blast radius analysis quarterly and after any significant
+architecture change. Document the analysis: "If service X is compromised, the attacker
+can reach services Y and Z, which contain data classifications A and B."
+
+### Migration Strategy for Existing Systems
+
+Retrofitting segmentation onto a flat network is high-risk if done incorrectly. The
+recommended approach: (1) deploy monitoring first -- enable flow logs and observe all
+traffic for 2-4 weeks without enforcing any policy, (2) generate a baseline communication
+map from observed traffic, (3) create policies that match the observed baseline (this
+should change nothing), (4) enable enforcement in audit/log-only mode, (5) verify no
+legitimate traffic is being flagged, (6) switch to enforcing mode, (7) incrementally
+tighten policies by removing overly broad rules. Never go from flat network to strict
+segmentation in one step -- the result is always a production outage.
+
+## Anti-Patterns
+
+1. **Flat network with no internal segmentation.** All services can reach all other
+   services. Compromising any single service grants access to the entire system. This is
+   the default in most cloud VPCs and Kubernetes clusters and must be explicitly corrected.
+
+2. **Overly permissive allow rules.** Rules like "allow all traffic from the application
+   subnet to the data subnet" defeat the purpose of segmentation. Be specific: allow
+   service-A to reach database-B on port 5432 using TCP. Every rule should name specific
+   source and destination identities, not broad CIDR ranges.
+
+3. **Segmentation without monitoring.** Policies without monitoring are unverifiable. If
+   you cannot see what traffic is flowing and what is being denied, you cannot know if the
+   segmentation is effective or if rules have drifted. Enable flow logs, review them, and
+   alert on anomalies.
+
+4. **IP-based policies in dynamic environments.** Kubernetes pods get new IPs on every
+   restart. Security group rules referencing specific IPs become stale immediately. Use
+   service identity and label selectors instead. If you find yourself updating firewall
+   rules every time a pod restarts, your segmentation model is fundamentally wrong.
+
+5. **Segmentation only at the network layer.** L3/L4 policies prevent unauthorized
+   connections but do not prevent authorized connections from being misused. A compromised
+   order service with L4 access to the payment service can send arbitrary requests. Add
+   L7 policies for sensitive services: only allow specific HTTP methods and paths, reject
+   everything else.