@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/cursor/security-symmetric-encryption/SKILL.md

@@ -0,0 +1,176 @@
+# Symmetric Encryption
+
+> AES-256-GCM for most use cases, ChaCha20-Poly1305 when hardware AES is unavailable --
+> always use authenticated encryption, never roll your own
+
+## When to Use
+
+- Encrypting data at rest (database fields, file storage, backups)
+- Encrypting data in application-layer protocols (beyond TLS)
+- Choosing between AES and ChaCha20 for a specific deployment target
+- Selecting a mode of operation (GCM, CBC, CTR) for a symmetric cipher
+- Reviewing code that performs encryption for correctness
+- Designing a key management scheme for encrypted data
+
+## Threat Context
+
+Symmetric encryption defends against confidentiality breaches when an attacker gains
+access to stored data (stolen database dumps, compromised backups, unauthorized file
+system access) or intercepts data in transit. Without authenticated encryption (AEAD),
+an attacker can also tamper with ciphertext without detection -- the padding oracle
+attack against AES-CBC (CVE-2014-3566, POODLE) demonstrated this at scale, enabling
+plaintext recovery through ciphertext manipulation. Key theft and nonce misuse represent
+the two remaining catastrophic failure modes even when a correct algorithm is chosen.
+
+## Instructions
+
+1. **Default to AES-256-GCM.** AES (Advanced Encryption Standard, Rijndael) with
+   256-bit keys in GCM (Galois/Counter Mode) provides both confidentiality and integrity
+   through authenticated encryption with associated data (AEAD). GCM produces a 128-bit
+   authentication tag that detects any ciphertext modification. AES-256-GCM is
+   NIST-approved, FIPS 140-2 compliant, and hardware-accelerated on all modern x86
+   (AES-NI) and ARM (ARMv8 Crypto Extensions) processors. On hardware with AES-NI,
+   AES-256-GCM achieves throughput exceeding 1 GB/s per core.
+
+2. **Use ChaCha20-Poly1305 when AES hardware acceleration is unavailable.** ChaCha20
+   is a stream cipher designed by Daniel Bernstein as a refinement of Salsa20, using a
+   256-bit key and a 96-bit nonce. Combined with Poly1305 MAC, it provides AEAD
+   equivalent in security to AES-GCM. ChaCha20-Poly1305 is faster in software on
+   devices without AES-NI (IoT devices, older mobile chipsets, embedded systems). TLS 1.3
+   includes both AES-256-GCM and ChaCha20-Poly1305 as mandatory cipher suites. Google
+   adopted ChaCha20-Poly1305 in Chrome for Android specifically because most ARM
+   processors at the time lacked AES hardware acceleration.
+
+3. **Never use unauthenticated modes in new systems.** AES-CBC (Cipher Block Chaining)
+   without a separate HMAC is vulnerable to padding oracle attacks -- an attacker who can
+   submit ciphertexts and observe whether decryption produces a padding error can recover
+   the full plaintext byte-by-byte. AES-ECB (Electronic Codebook) is structurally broken:
+   identical plaintext blocks produce identical ciphertext blocks, leaking patterns in the
+   data. AES-CTR (Counter Mode) without a MAC provides confidentiality but allows
+   undetected ciphertext bit-flipping -- an attacker who knows the plaintext at a given
+   position can flip the corresponding ciphertext bit to produce any desired plaintext
+   byte.
+
+4. **Generate IVs/nonces correctly.** GCM requires a unique 96-bit nonce per encryption
+   operation under the same key. Nonce reuse under GCM is catastrophic: it reveals the
+   XOR of two plaintexts and exposes the GHASH authentication key, allowing forgery of
+   authentication tags for arbitrary messages. Use a cryptographically secure pseudorandom
+   number generator (CSPRNG) for random nonces. For systems encrypting more than 2^32
+   messages under a single key (where random nonce collision probability becomes
+   non-negligible by the birthday bound), use a deterministic construction such as
+   AES-GCM-SIV, which provides nonce-misuse resistance at a modest performance cost.
+
+5. **Key sizes: 256-bit for future-proofing.** AES-128 is not broken and provides
+   128-bit security against classical computers, which is sufficient for current threats.
+   AES-256 provides margin against theoretical quantum attacks -- Grover's algorithm
+   reduces the effective key strength by half (256-bit becomes 128-bit effective), keeping
+   AES-256 secure even in a post-quantum scenario. For all new systems, default to
+   256-bit keys. The performance difference between AES-128 and AES-256 is approximately
+   40% more rounds (14 vs 10) but negligible in practice with hardware acceleration.
+
+6. **Key derivation from passwords.** Never use a password directly as an encryption key.
+   Human-chosen passwords have far less entropy than required for cryptographic keys.
+   Derive keys using Argon2id (preferred), scrypt, or PBKDF2-HMAC-SHA256 with a unique
+   random salt (at least 128 bits) and sufficient cost parameters. The derived key must be
+   exactly the length required by the cipher: 32 bytes for AES-256. Store the salt
+   alongside the ciphertext (the salt is not secret). If deriving multiple keys from one
+   password (e.g., one for encryption, one for MAC), use distinct info/context parameters
+   in an HKDF-Expand step, never truncate or split a single derived key.
+
+7. **Encrypt-then-MAC if forced to use CBC.** If a legacy system requires AES-CBC, apply
+   HMAC-SHA256 to the ciphertext (not the plaintext) after encryption. Verify the MAC
+   before decrypting -- reject any message with an invalid MAC without attempting
+   decryption. This is the encrypt-then-MAC construction and is provably secure under
+   standard assumptions. The two alternative compositions -- MAC-then-encrypt (used in
+   TLS < 1.3, enabling BEAST and Lucky Thirteen) and encrypt-and-MAC (used in SSH,
+   theoretically weaker) -- are both vulnerable to specific attack classes. Always use
+   encrypt-then-MAC.
+
+## Details
+
+### Modes of Operation Comparison
+
+| Mode    | Type                   | Parallelizable          | Nonce-Sensitive          | Notes                                                                       |
+| ------- | ---------------------- | ----------------------- | ------------------------ | --------------------------------------------------------------------------- |
+| GCM     | AEAD                   | Yes (encrypt + decrypt) | Catastrophic on reuse    | Default choice for new systems                                              |
+| CBC     | Confidentiality only   | Decrypt only            | IV must be unpredictable | Padding oracle risk; needs separate MAC                                     |
+| CTR     | Confidentiality only   | Yes (encrypt + decrypt) | Catastrophic on reuse    | Needs separate MAC; basis for GCM                                           |
+| GCM-SIV | AEAD                   | Yes                     | Nonce-misuse resistant   | Slight performance penalty; safe when nonce uniqueness cannot be guaranteed |
+| XTS     | Tweakable block cipher | Yes                     | N/A (uses tweak)         | Designed for disk/sector encryption (LUKS, BitLocker); not for general use  |
+
+### The Nonce Reuse Catastrophe
+
+When nonce N is reused with key K for two different plaintexts P1 and P2 under AES-GCM:
+
+- The keystream is identical for both encryptions (since CTR mode generates the keystream
+  from the nonce).
+- C1 XOR C2 = P1 XOR P2, revealing the XOR of the two plaintexts. With known or
+  guessable plaintext fragments, this recovers both messages.
+- The GHASH authentication key H is exposed through algebraic analysis of the two
+  authentication tags. With H, the attacker can forge valid authentication tags for
+  arbitrary ciphertexts under the same key -- a complete authenticity break.
+- This is not theoretical: nonce reuse vulnerabilities have been discovered in production
+  TLS implementations, and the GHASH key recovery attack has been demonstrated
+  practically.
+
+### Associated Data (the "AD" in AEAD)
+
+GCM and ChaCha20-Poly1305 support additional authenticated data (AAD) -- data that is
+integrity-protected but not encrypted. The authentication tag covers both the ciphertext
+and the AAD, so any modification to either is detected.
+
+Use AAD for metadata that must not be modified but does not need confidentiality:
+
+- The database row ID or primary key (prevents ciphertext from being moved between rows)
+- The encryption algorithm identifier (prevents downgrade attacks)
+- The key version identifier (prevents ciphertext from being decrypted with the wrong
+  key version)
+- Any routing or addressing information that must remain in plaintext for the system to
+  function
+
+### Key Rotation
+
+Encrypted data must remain decryptable after key rotation. The standard pattern:
+
+- Encrypt with the current active key. Store the key version/ID alongside the ciphertext
+  (in the AAD or as a plaintext prefix).
+- On decryption, look up the key by version ID and decrypt with the correct key.
+- Re-encrypt data under the new key during a migration window (background job, lazy
+  re-encryption on read, or bulk migration).
+- Never delete old keys until all data encrypted under them has been verified as
+  re-encrypted. Maintain a key inventory that tracks which ciphertexts reference which
+  key versions.
+
+## Anti-Patterns
+
+1. **ECB mode for anything.** ECB encrypts each block independently -- identical
+   plaintext blocks produce identical ciphertext blocks. The famous "ECB penguin"
+   demonstrates this visually: encrypting a bitmap image in ECB mode preserves the
+   image's visual pattern in the ciphertext. ECB leaks structural information about the
+   plaintext and must never be used for any purpose.
+
+2. **Nonce reuse with GCM or CTR.** Reusing a nonce under the same key with GCM or CTR
+   modes completely breaks confidentiality and (for GCM) authenticity. Use random nonces
+   from a CSPRNG for each encryption operation, enforce nonce uniqueness through counters
+   or database constraints for high-volume systems, or switch to AES-GCM-SIV for
+   nonce-misuse resistance if uniqueness cannot be guaranteed architecturally.
+
+3. **Using encryption without authentication.** AES-CBC or AES-CTR without a MAC allows
+   an attacker to flip bits in the ciphertext, producing modified plaintext that decrypts
+   without any error. The Efail attack (2018) exploited this in PGP and S/MIME email
+   encryption to exfiltrate plaintext through ciphertext manipulation. Always use AEAD
+   (GCM, ChaCha20-Poly1305) or the encrypt-then-MAC construction.
+
+4. **Hardcoded encryption keys.** Embedding keys in source code, configuration files
+   committed to version control, environment variables baked into container images, or
+   client-side code. Keys must be stored in a dedicated secrets manager (HashiCorp Vault,
+   AWS KMS, GCP Cloud KMS, Azure Key Vault) and injected at runtime through secure
+   channels. Rotate keys on any suspicion of exposure.
+
+5. **Custom encryption schemes.** Inventing novel cipher combinations, custom padding
+   schemes, "double encryption" with two algorithms, or "encryption" via XOR with a
+   static or repeated key. Use well-vetted, peer-reviewed library implementations of
+   standard algorithms (libsodium, OpenSSL, Web Crypto API, Go crypto/aes).
+   Cryptography is the one engineering discipline where cleverness consistently makes
+   things worse -- the attack surface of a custom scheme is unknown and unknowable
+   without years of public cryptanalysis.

package/dist/agents/skills/cursor/security-symmetric-encryption/skill.yaml

@@ -0,0 +1,41 @@
+name: security-symmetric-encryption
+version: "1.0.0"
+description: AES and ChaCha20 symmetric ciphers, modes of operation (GCM vs CBC vs CTR), key sizes, IV/nonce management, and authenticated encryption
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-asymmetric-encryption
+  - security-hashing-fundamentals
+  - security-hmac-signatures
+  - security-cryptographic-randomness
+  - security-tls-fundamentals
+  - owasp-cryptography
+stack_signals: []
+keywords:
+  - AES
+  - ChaCha20
+  - symmetric encryption
+  - GCM
+  - CBC
+  - CTR
+  - authenticated encryption
+  - AEAD
+  - cipher
+  - encryption key
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/security-threat-modeling-process/SKILL.md

@@ -0,0 +1,150 @@
+# Threat Modeling Process
+
+> End-to-end threat modeling from system decomposition through threat enumeration, risk rating, and mitigation tracking -- the operational backbone of proactive security design
+
+## When to Use
+
+- Starting a new project or major feature and need to establish a threat model from scratch
+- Integrating threat modeling into an existing SDLC for the first time
+- Running a threat modeling workshop with a development team
+- Reviewing whether an existing threat model is complete and current
+- Preparing documentation for a SOC2, ISO 27001, or FedRAMP audit that requires evidence of threat analysis
+- Onboarding a new team member who needs to understand the system's security posture quickly
+
+## Threat Context
+
+Systems that skip formal threat modeling consistently exhibit predictable vulnerability patterns: authentication bypasses on internal APIs assumed to be unreachable, unprotected administrative endpoints, missing encryption on sensitive data flows between services, and insufficient logging that makes incident response impossible. These are not exotic zero-day attacks -- they are foreseeable consequences of never asking "what could go wrong?" systematically.
+
+The threat modeling process exists to make the implicit explicit before attackers do.
+
+NIST estimates that vulnerabilities found in production are 6-10x more expensive to remediate than those identified during design. Threat modeling shifts security left to where it is cheapest and most effective.
+
+## Instructions
+
+1. **Scope the model.** Define system boundaries explicitly -- what is in-scope and what is out-of-scope for this threat modeling exercise. Name the assets worth protecting: user PII, financial transaction data, session tokens, API keys, cryptographic secrets, audit logs. Identify regulatory requirements (GDPR, HIPAA, PCI-DSS, SOC2) that impose specific security controls on in-scope data.
+
+   A model without a defined scope either balloons to unworkable size or silently excludes critical components. Write the scope statement in the threat model document before drawing anything.
+
+2. **Build the Data Flow Diagram.** Use standard DFD notation:
+   - Rectangles for external entities (users, browsers, third-party APIs, partner systems)
+   - Circles or rounded rectangles for processes (microservices, API endpoints, background workers, batch jobs)
+   - Parallel lines for data stores (databases, caches, object storage, message queues treated as persistent stores)
+   - Arrows for data flows
+
+   Label every flow with the data it carries -- not "request/response" but "JWT token in Authorization header," "credit card number in POST body," "password hash read from users table." Ambiguous labels produce ambiguous threat analysis.
+
+3. **Identify trust boundaries.** Every point where data crosses from one trust level to another is an attack surface. Draw dashed lines on the DFD at each boundary. Common trust boundaries include:
+   - Browser to server (the internet boundary)
+   - API gateway to backend service (the perimeter-to-application boundary)
+   - Application to database (the application-to-data boundary)
+   - Service to third-party API (the internal-to-external boundary)
+   - CI/CD pipeline to production (the deployment boundary)
+
+   See `security-trust-boundaries` for deep treatment of boundary analysis.
+
+4. **Enumerate threats.** Apply a structured methodology to each DFD element and each trust boundary crossing. STRIDE is the most accessible for development teams (see `security-threat-modeling-stride`). PASTA (Process for Attack Simulation and Threat Analysis) is a 7-stage risk-centric process suited for mature security organizations. Attack trees provide depth analysis for individual high-value targets.
+
+   Document each threat with: a unique ID, a natural-language description following the form "An attacker could [action] by [method], resulting in [impact]," the affected DFD component, the threat category, and the specific data or asset at risk.
+
+5. **Rate risk.** Assign each threat a risk score using one of two common frameworks:
+   - **DREAD**: Damage potential (0-10), Reproducibility (0-10), Exploitability (0-10), Affected users (0-10), Discoverability (0-10). Average the five scores. Simple but subjective.
+   - **Likelihood x Impact matrix**: Rate likelihood (Low/Medium/High) and impact (Low/Medium/High) independently. Multiply for a 9-cell risk matrix. Less granular but faster and more consistent across raters.
+
+   Whichever framework you choose, apply it consistently across all threats. Mixed rating systems produce incomparable priorities. Rank threats by composite score in descending order.
+
+6. **Define mitigations.** For each threat above the risk acceptance threshold, specify:
+   - The mitigation control (the specific technical measure)
+   - The implementation owner (the person or team responsible)
+   - The target completion date
+   - The verification criterion (a test case, configuration check, or observable behavior that confirms the mitigation is in place)
+
+   Mitigations without owners do not get implemented. Mitigations without verification criteria cannot be audited.
+
+7. **Track and iterate.** Store the threat model alongside the codebase -- a `docs/security/threat-model.md` file or a dedicated section in the project wiki that is versioned with the code.
+
+   Review the model quarterly at minimum and on every significant architecture change (new service, new data store, new external integration, new deployment target). Add new threats as features are added. Close mitigated threats with evidence (link to the PR that implemented the control, the test that verifies it, or the configuration that enforces it). A threat model that is not maintained decays into a false sense of security.
+
+## Details
+
+### Choosing a Methodology
+
+**STRIDE** is the best starting point for development teams new to threat modeling. Its mnemonic structure provides a checklist that prevents category omission, and its element-based approach maps naturally to system architecture diagrams that developers already understand. Limitation: STRIDE is classification-oriented -- it tells you what categories of threats exist but does not inherently prioritize them or model attacker behavior chains.
+
+**PASTA** (Process for Attack Simulation and Threat Analysis) is a 7-stage risk-centric framework: define objectives, define technical scope, application decomposition, threat analysis, vulnerability analysis, attack modeling, and risk/impact analysis. PASTA produces more rigorous output than STRIDE because it incorporates business impact analysis and attacker simulation, but it requires more security expertise and more time. Best suited for organizations with dedicated application security teams.
+
+**Attack trees** model how an attacker achieves a specific goal by decomposing it into sub-goals connected by AND/OR logic. An attack tree for "steal user credentials" might decompose into "exploit SQL injection OR phish an admin OR compromise a backup," with each branch decomposing further. Attack trees provide depth that STRIDE and PASTA do not, but they analyze one goal at a time rather than surveying the whole system.
+
+For most teams, the recommended approach is: STRIDE for breadth (survey the whole system), then attack trees for depth (analyze the top 5 threats in detail).
+
+### Running a Threat Modeling Workshop
+
+A 90-minute workshop with 4-6 participants is the most effective format for producing a threat model that the team understands and owns.
+
+**Participants**: 2 developers who built the system, 1 architect who designed it, 1 security engineer (or the most security-aware team member), 1 QA engineer, and 1 product owner who understands business impact. If no dedicated security engineer is available, the architect assumes that role.
+
+**Structure**:
+
+- **First 20 minutes**: Draw the DFD on a whiteboard or shared diagram tool. The developers drive this -- they know the actual data flows, not just the designed ones. Mark trust boundaries.
+- **Next 40 minutes**: Walk each trust boundary. For each boundary crossing, apply STRIDE. The security engineer leads questioning; developers answer with system knowledge. Record every identified threat on sticky notes or in a shared document.
+- **Final 30 minutes**: Prioritize threats using the risk matrix. Assign the top threats to owners with target dates. Decide on accept/mitigate/transfer for each.
+
+**Output**: A threat register document committed to the repository within 24 hours of the workshop. The document becomes a living artifact updated in subsequent sprints.
+
+### Lightweight Threat Modeling for Agile Teams
+
+For teams that cannot dedicate 90 minutes, integrate threat modeling into existing ceremonies:
+
+**Per-story threat check (5 minutes during backlog refinement)**: For each user story, ask three questions:
+
+1. Does this story introduce a new data flow, external entity, or data store to the DFD?
+2. Does this story cross an existing trust boundary in a new way?
+3. Does this story handle sensitive data (PII, credentials, financial data) that was not previously in scope?
+
+If any answer is "yes," add a STRIDE analysis task to the story's acceptance criteria.
+
+**Architecture Decision Record (ADR) threat appendix**: When writing an ADR for a significant architecture change, append a threat analysis section that applies STRIDE to the new or modified components. This catches threats at the decision point rather than after implementation.
+
+### Tooling
+
+- **Microsoft Threat Modeling Tool** (free): Generates STRIDE threats automatically from a DFD drawn in the tool. Windows-only. Produces HTML reports suitable for audit evidence.
+- **OWASP Threat Dragon** (open source, web-based): DFD editor with manual threat enumeration. Cross-platform. Stores models as JSON files that can be committed to version control.
+- **IriusRisk** (commercial): Automated threat generation from architecture patterns. Integrates with Jira for mitigation tracking. Suited for enterprises with multiple product teams.
+- **Markdown tables in the repo**: For teams without tooling budget, a structured Markdown file with columns for threat ID, description, STRIDE category, risk score, mitigation, owner, and status is sufficient and has the advantage of being versioned, diffable, and reviewable in pull requests.
+
+### Threat Model Document Structure
+
+A complete threat model document stored in the repository should contain these sections:
+
+1. **Header**: Model name, version, date, authors, review status
+2. **Scope**: What is in-scope, what is explicitly out-of-scope, which assets are being protected, applicable regulations
+3. **Data Flow Diagram**: Visual diagram with trust boundaries marked, plus a text legend explaining each element
+4. **Trust Boundary Inventory**: Table of all identified trust boundaries with the data classification and transport mechanism for each
+5. **Threat Register**: Table of all identified threats with ID, description, STRIDE category, risk score, mitigation, owner, status, and verification criterion
+6. **Assumptions**: Security assumptions the model depends on (e.g., "the cloud provider's IAM is not compromised," "TLS 1.3 is correctly configured on the load balancer")
+7. **Open Questions**: Unresolved items that need further investigation before the model is complete
+8. **Revision History**: Dated entries showing when the model was updated and what changed
+
+Store this as `docs/security/threat-model.md` or in a `security/` directory within the project. The document must be reviewable in pull requests so that architecture changes trigger threat model updates in the same review cycle.
+
+### Metrics for Threat Modeling Effectiveness
+
+Track these metrics to assess whether threat modeling is producing value:
+
+- **Threats identified per model**: A model with fewer than 10 threats for a non-trivial system suggests insufficient analysis. A model with more than 100 suggests scope creep or insufficient abstraction.
+- **Percentage mitigated before release**: Target 100% of high-risk and medium-risk threats mitigated before production deployment. Low-risk threats may be deferred with documented acceptance.
+- **Mean time from identification to mitigation**: Measures how quickly the team acts on identified threats. Increasing time suggests the threat model is disconnected from the development workflow.
+- **Post-release vulnerability correlation**: The most important metric. If post-release findings were already in the threat model but unmitigated, the process identified the threat but the team failed to act. If post-release findings were not in the threat model, the enumeration was incomplete. Both failure modes are diagnostic.
+
+## Anti-Patterns
+
+1. **Threat modeling after implementation.** If the system is already built and deployed, the threat model becomes a retrospective documentation exercise rather than a design influence. Threats found post-implementation are dramatically more expensive to remediate because they require rework of existing code, re-testing of deployed functionality, and often coordination of a security patch release. Model before you build. The cheapest vulnerability to fix is the one you designed out.
+
+2. **Security team owns the threat model alone.** When the security team produces the threat model in isolation and hands it to developers as a list of mandates, two things go wrong: developers do not understand the reasoning behind the controls (and therefore implement them incorrectly or resentfully), and the threat model does not reflect the actual system (because the security team does not know all the data flows). The development team must participate in and co-own the threat model.
+
+3. **DFD too detailed or too abstract.** A DFD with 50 processes is unworkable -- applying STRIDE to each element produces hundreds of threats, most of which are low-value duplicates. A DFD with 2 boxes ("frontend" and "backend") misses all internal threats, all service-to-service attack vectors, and all data store risks. Target 5-15 DFD elements per model. If a subsystem is high-risk (e.g., the authentication service), decompose it into its own DFD at a finer granularity and run a separate threat model.
+
+4. **No risk rating.** Listing 200 threats without prioritization leads to analysis paralysis. The development team stares at a wall of threats and does not know where to start. Not all threats are equal -- a low-likelihood, low-impact information disclosure on a public status page is not comparable to a high-likelihood, high-impact elevation of privilege on the admin API. Rate them, rank them, and address the top 10 first.
+
+5. **Confusing threat modeling with penetration testing.** Threat modeling is a design-time analytical activity that identifies what could go wrong based on the system's architecture. Penetration testing is a validation-time empirical activity that confirms whether specific vulnerabilities exist in the running system. Threat modeling without penetration testing is unverified theory. Penetration testing without threat modeling is undirected probing. They are complementary -- threat modeling tells you where to look; penetration testing tells you what you actually find.
+
+6. **Treating threat modeling as a document, not a process.** Teams that produce a polished PDF threat model and file it away have completed a documentation exercise, not a security activity. The value of threat modeling is in the ongoing conversation it creates -- the team's shared understanding of where the system is vulnerable and what trade-offs were made. Update the model when the architecture changes, review it during sprint planning, and reference it when making design decisions.

package/dist/agents/skills/cursor/security-threat-modeling-process/skill.yaml

@@ -0,0 +1,38 @@
+name: security-threat-modeling-process
+version: "1.0.0"
+description: End-to-end threat modeling process -- from scoping and DFD construction through threat enumeration, risk rating, and mitigation tracking
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-threat-modeling-stride
+  - security-trust-boundaries
+  - security-attack-trees
+  - owasp-auth-patterns
+  - owasp-logging-monitoring
+stack_signals: []
+keywords:
+  - threat modeling
+  - threat model
+  - data flow diagram
+  - DFD
+  - risk assessment
+  - security design review
+  - threat register
+  - mitigation tracking
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/security-threat-modeling-stride/SKILL.md

@@ -0,0 +1,150 @@
+# STRIDE Threat Modeling
+
+> Systematic threat identification using the six STRIDE categories -- Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
+
+## When to Use
+
+- Designing a new system or service and need to enumerate threats before writing code
+- Reviewing an existing architecture for security gaps
+- Preparing for a security review or compliance audit
+- Adding a new data flow, API, or integration point to an existing system
+- Training team members to think adversarially about system design
+- Building a threat register for risk prioritization
+- Evaluating whether a third-party component introduces new trust boundaries or attack surface
+
+## Threat Context
+
+STRIDE was developed at Microsoft by Loren Kohnfelder and Praerit Garg in 1999 and remains the most widely adopted threat classification framework. It provides a mnemonic decomposition that maps directly to security properties: Spoofing violates authentication, Tampering violates integrity, Repudiation violates non-repudiation, Information Disclosure violates confidentiality, Denial of Service violates availability, and Elevation of Privilege violates authorization. Attackers exploit systems along these six axes -- STRIDE ensures no axis is overlooked during design.
+
+## Instructions
+
+1. **Decompose the system into a Data Flow Diagram (DFD).** Identify external entities (users, third-party services), processes (application logic, microservices), data stores (databases, caches, file systems), and data flows (API calls, message queues, file transfers). Each element becomes a threat target.
+
+   Use standard DFD notation: rectangles for external entities, circles or rounded rectangles for processes, parallel lines for data stores, and arrows for data flows. Label every arrow with the data it carries. A DFD that says "request" and "response" is too vague -- label it "JWT token in Authorization header" or "credit card number in POST body."
+
+2. **Apply STRIDE to each DFD element systematically.** Not every STRIDE category applies to every element type. Use the element-to-threat mapping:
+   - **External entities**: Spoofing, Repudiation
+   - **Processes**: All six -- Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
+   - **Data stores**: Tampering, Information Disclosure, Denial of Service
+   - **Data flows**: Tampering, Information Disclosure, Denial of Service
+
+   Walk through each DFD element in turn. For each applicable STRIDE category, ask: "How could an attacker achieve this goal against this specific component?" If you cannot articulate a concrete attack, the category may not apply to that element -- but document the reasoning, not just the conclusion.
+
+3. **Document each threat with precision.** Use the canonical form: "An attacker could [action] by [method], resulting in [impact]." Include:
+   - Threat ID (e.g., T-001)
+   - Affected component (the specific DFD element)
+   - STRIDE category
+   - Likelihood (Low / Medium / High)
+   - Impact (Low / Medium / High)
+   - Proposed mitigation
+
+   Vague threats like "an attacker could hack the database" are useless. Specific threats like "an attacker could extract user credentials from the PostgreSQL database by exploiting a SQL injection in the /api/search endpoint, resulting in bulk credential theft" are actionable.
+
+4. **Prioritize using risk = likelihood x impact.** High-likelihood, high-impact threats get mitigated first. Low-likelihood, low-impact threats are accepted with documentation.
+
+   Use a 3x3 risk matrix to visualize the distribution. If more than 60% of threats cluster in the high-risk quadrant, the architecture has systemic security weaknesses that require design changes, not just point mitigations.
+
+5. **Map mitigations to the STRIDE-to-security-property table.** Each STRIDE category has a corresponding security property and a family of standard controls:
+   - **Spoofing** -> Authentication: MFA, X.509 certificates, API keys with rotation, mutual TLS
+   - **Tampering** -> Integrity: HMAC, digital signatures, checksums, immutable append-only logs, content hashing
+   - **Repudiation** -> Non-repudiation: Structured audit logs with tamper-evident storage, digital signatures on transactions, synchronized timestamps
+   - **Information Disclosure** -> Confidentiality: Encryption at rest (AES-256-GCM) and in transit (TLS 1.3), access controls, data classification and masking, secure error handling that suppresses internals
+   - **Denial of Service** -> Availability: Rate limiting, autoscaling, circuit breakers, request size limits, connection pooling, geographic redundancy
+   - **Elevation of Privilege** -> Authorization: RBAC or ABAC, principle of least privilege, input validation, secure defaults, sandboxing
+
+6. **Iterate per sprint or per feature, not just once at project inception.** Every new feature introduces new DFD elements -- a new API endpoint is a new process, a new third-party integration is a new external entity, a new cache layer is a new data store. Run STRIDE on the delta. The threat model is a living artifact that evolves with the system.
+
+## Details
+
+### STRIDE-per-Element vs STRIDE-per-Interaction
+
+The original STRIDE formulation (per-element) applies the six categories to each DFD component independently. STRIDE-per-interaction, introduced later by Microsoft SDL practitioners, applies STRIDE to each data flow that crosses a trust boundary.
+
+Per-interaction is more thorough for distributed systems because it focuses analysis on the attack surface -- the boundary crossings -- rather than exhaustively enumerating all components. For monolithic applications, per-element is sufficient. For microservices architectures with dozens of inter-service calls, per-interaction scales better and produces more actionable results because every analyzed tuple (source, destination, data flow, trust boundary) maps directly to a specific network call that can be hardened.
+
+The choice between the two approaches also affects team workflow. Per-element analysis can be parallelized across team members (each person takes a subset of DFD elements). Per-interaction analysis requires understanding the full data flow path and is better suited to group workshops where developers can trace a request end-to-end.
+
+### Worked Example
+
+Consider a web application with four components: a browser client, an API gateway, an authentication service, and a PostgreSQL database.
+
+- **Spoofing**: An attacker forges a JWT token by exploiting a weak signing algorithm (HS256 with a guessable secret) to impersonate another user. Mitigation: use RS256 with a 2048-bit key pair, validate `iss` and `aud` claims, enforce short expiration.
+
+- **Tampering**: An attacker modifies the JSON request body between the browser client and API gateway (via a proxy or browser devtools) to change the `role` field from "user" to "admin." Mitigation: never accept role or privilege fields from the client; derive authorization from the server-side session.
+
+- **Repudiation**: A user performs a destructive action (deleting records) and denies it. No audit trail exists because the application only logs errors, not business actions. Mitigation: log all state-changing operations with actor identity, timestamp, resource affected, and action type to a tamper-evident log store.
+
+- **Information Disclosure**: The API gateway returns verbose SQL error messages to the client when a query fails, exposing table names, column names, and query structure. Mitigation: return generic error responses to clients; log detailed errors server-side only.
+
+- **Denial of Service**: The search endpoint accepts unbounded queries with no pagination limit. An attacker sends `GET /api/search?q=*&limit=1000000`, causing the database to perform a full table scan and exhausting connection pool resources. Mitigation: enforce maximum page size (e.g., 100), require pagination, add query timeout at the database level.
+
+- **Elevation of Privilege**: The API uses sequential integer IDs for resources (`/api/orders/1234`). An attacker increments the ID to access another user's order (IDOR -- Insecure Direct Object Reference). Mitigation: use UUIDs for external-facing resource identifiers, enforce ownership checks on every resource access.
+
+### STRIDE and Compliance Mapping
+
+STRIDE categories map directly to established compliance frameworks, making threat models reusable as audit evidence:
+
+- **Spoofing** -> NIST 800-53 IA (Identification and Authentication) -> OWASP Top 10 A07 (Identification and Authentication Failures)
+- **Tampering** -> NIST 800-53 SI (System and Information Integrity) -> OWASP Top 10 A03 (Injection)
+- **Repudiation** -> NIST 800-53 AU (Audit and Accountability) -> OWASP Top 10 A09 (Security Logging and Monitoring Failures)
+- **Information Disclosure** -> NIST 800-53 SC (System and Communications Protection) -> OWASP Top 10 A01 (Broken Access Control) and A02 (Cryptographic Failures)
+- **Denial of Service** -> NIST 800-53 SC and CP (Contingency Planning) -> not directly in OWASP Top 10 (availability is out of scope for OWASP)
+- **Elevation of Privilege** -> NIST 800-53 AC (Access Control) -> OWASP Top 10 A01 (Broken Access Control)
+
+This mapping allows a single threat modeling exercise to serve both the development team (prioritizing mitigations) and the compliance team (demonstrating control coverage). When preparing for SOC2 Type II or ISO 27001 audits, a STRIDE-based threat model with NIST control family references provides direct evidence of risk assessment activities.
+
+### Threat Documentation Template
+
+A well-structured threat register entry contains:
+
+| Field                  | Example                                                                                                                                                                   |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **ID**                 | T-007                                                                                                                                                                     |
+| **Title**              | JWT Token Forgery via Weak Signing Algorithm                                                                                                                              |
+| **STRIDE Category**    | Spoofing                                                                                                                                                                  |
+| **Description**        | An attacker could impersonate any user by forging a JWT token signed with HS256 using a brute-forced shared secret, resulting in unauthorized access to all user accounts |
+| **Affected Component** | API Gateway (process)                                                                                                                                                     |
+| **Trust Boundary**     | Browser -> API Gateway                                                                                                                                                    |
+| **Likelihood**         | High (HS256 secrets are frequently weak or default)                                                                                                                       |
+| **Impact**             | High (full account takeover)                                                                                                                                              |
+| **Risk Score**         | High (H x H)                                                                                                                                                              |
+| **Mitigation**         | Switch to RS256 with 2048-bit key pair; validate iss, aud, and exp claims; rotate keys quarterly                                                                          |
+| **Owner**              | Auth team                                                                                                                                                                 |
+| **Status**             | Open                                                                                                                                                                      |
+| **Verification**       | Integration test confirms RS256 enforcement; HS256-signed tokens are rejected                                                                                             |
+
+This format ensures every threat is specific enough to act on, assigned to an owner, and verifiable when mitigated. Avoid free-text-only threat registers -- tabular formats enforce completeness and make gaps visible.
+
+### When STRIDE Is Insufficient
+
+STRIDE covers security threats to software systems but has known blind spots:
+
+- **Privacy**: STRIDE does not address privacy threats. Use LINDDUN for privacy-specific threat modeling: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.
+- **Supply chain**: Compromised dependencies, build pipeline poisoning, and artifact tampering require frameworks like SLSA (Supply-chain Levels for Software Artifacts) or the NIST Cybersecurity Supply Chain Risk Management (C-SCRM) practices.
+- **Physical and social**: Physical security, social engineering, and insider threats are outside STRIDE's scope entirely.
+- **Multi-stage attacks**: STRIDE categorizes individual threats but does not model attack chains where multiple low-severity findings combine into a critical exploit path. For modeling adversary behavior across multiple stages, use kill chain analysis (Lockheed Martin Cyber Kill Chain or MITRE ATT&CK).
+
+For high-security systems, the recommended approach is: STRIDE for comprehensive single-threat enumeration, supplemented with attack trees for depth analysis on the highest-value assets.
+
+### Output Quality Indicators
+
+A high-quality STRIDE analysis has these characteristics:
+
+- Every DFD element has at least one threat documented (even if the disposition is "accepted -- risk is negligible"). Elements with zero threats suggest the analysis skipped them.
+- No STRIDE category is entirely absent from the threat register. If an entire category (e.g., Repudiation) has zero entries, the team likely overlooked it or does not understand it.
+- Mitigations reference specific controls, not vague intentions. "Improve security" is not a mitigation. "Add HMAC-SHA256 signature verification on the webhook payload at the ingress handler" is a mitigation.
+- The risk distribution is not uniform. If every threat is rated "Medium/Medium," the team is not differentiating. Push for honest assessment -- some threats are high risk and some are low risk.
+
+## Anti-Patterns
+
+1. **Applying STRIDE without a DFD.** Brainstorming threats against "the application" as a whole produces vague, unactionable results. STRIDE requires concrete DFD elements to attach threats to. Without a DFD, teams fixate on perimeter threats and miss internal attack vectors -- service-to-service privilege escalation, data store tampering via batch jobs, and repudiation through unlogged internal APIs.
+
+2. **One-and-done threat modeling.** Running STRIDE once during initial design and never revisiting the model. Every new feature, API endpoint, data store, or integration changes the DFD and introduces new threat targets. A threat model from six months ago does not cover the three microservices added last sprint. Treat the threat model as a living document -- update it in the same PR that changes the architecture.
+
+3. **Listing threats without mitigations.** A threat register that identifies 47 risks but proposes no mitigations is a liability inventory, not a security activity. Every identified threat must have one of three dispositions: mitigate (specify the control and the owner), accept (document the risk acceptance decision and the approver), or transfer (specify the party assuming the risk, e.g., cyber insurance, third-party service SLA).
+
+4. **Confusing STRIDE categories with vulnerabilities.** "SQL injection" is not a STRIDE category -- it is a specific vulnerability class that maps to Tampering (the attacker modifies the intended query) and Information Disclosure (the attacker extracts data the query was not designed to return). STRIDE categories describe the attacker's strategic goals; vulnerabilities are the tactical mechanisms used to achieve those goals. Mixing the levels of abstraction produces threat models that duplicate vulnerability scan output rather than informing architecture.
+
+5. **Skipping the prioritization step.** Treating all identified threats as equally urgent produces analysis paralysis and diffuses engineering effort. A threat model with 80 equally-weighted items leads to either complete inaction or arbitrary cherry-picking. Use risk scoring (likelihood x impact) to create a ranked backlog. Address the top 10 threats in the current release; schedule the next 20 for the following release; accept or monitor the remainder.
+
+6. **Using STRIDE as a one-person exercise.** Threat modeling done by a single security engineer in isolation misses the domain knowledge that developers and architects bring. The team that builds the system understands its nuances -- the undocumented caching layer, the legacy endpoint that bypasses the API gateway, the batch job that runs with elevated privileges. Run STRIDE as a collaborative workshop, not a solo audit.

package/dist/agents/skills/cursor/security-threat-modeling-stride/skill.yaml

@@ -0,0 +1,40 @@
+name: security-threat-modeling-stride
+version: "1.0.0"
+description: STRIDE methodology for systematic threat identification across spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-threat-modeling-process
+  - security-trust-boundaries
+  - security-attack-trees
+  - owasp-injection-prevention
+  - owasp-auth-patterns
+  - owasp-csrf-protection
+stack_signals: []
+keywords:
+  - stride
+  - threat modeling
+  - spoofing
+  - tampering
+  - repudiation
+  - information disclosure
+  - denial of service
+  - elevation of privilege
+  - threat identification
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []