@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/claude-code/security-credential-storage/skill.yaml

@@ -0,0 +1,41 @@
+name: security-credential-storage
+version: "1.0.0"
+description: Password hashing with Argon2id, bcrypt, and scrypt -- salting, peppering, adaptive cost, and upgrade strategies for legacy hashes
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-hashing-fundamentals
+  - security-authentication-flows
+  - security-session-management
+  - security-mfa-design
+  - owasp-auth-patterns
+  - owasp-secrets-management
+stack_signals: []
+keywords:
+  - password hashing
+  - argon2
+  - bcrypt
+  - scrypt
+  - salting
+  - peppering
+  - credential storage
+  - password storage
+  - adaptive cost
+  - key stretching
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/security-cryptographic-randomness/SKILL.md

@@ -0,0 +1,154 @@
+# Cryptographic Randomness
+
+> Every session token, encryption key, nonce, and CSRF token depends on unpredictable randomness -- use a CSPRNG or accept that attackers will predict your secrets
+
+## When to Use
+
+- Generating session tokens, API keys, CSRF tokens, or password reset tokens
+- Creating initialization vectors (IVs) or nonces for encryption
+- Generating cryptographic key material
+- Selecting random values for any security-sensitive operation (salts, verification codes, OTPs)
+- Auditing existing code for insecure randomness sources
+
+## Threat Context
+
+Predictable random number generators have caused catastrophic breaches. The 2012 Android Bitcoin wallet vulnerability used a broken PRNG that reused ECDSA nonces, allowing private key extraction and theft of 55 BTC. The 2008 Debian OpenSSL bug reduced the entropy pool to 15 bits (32,768 possible keys), making all SSL certificates, SSH keys, and VPN keys generated on affected Debian and Ubuntu systems trivially crackable for nearly two years before discovery.
+
+PHP's `mt_rand()` and JavaScript's `Math.random()` use algorithms (Mersenne Twister and xorshift128+ respectively) that are fully predictable after observing a small number of outputs. Any security token generated from a non-cryptographic PRNG can be predicted and forged by an attacker who observes enough prior outputs.
+
+## Instructions
+
+1. **Always use the platform's CSPRNG.** Every major platform provides a cryptographically secure random number generator. Use it without exception for security-sensitive values:
+   - **Node.js:** `crypto.randomBytes()` or `crypto.randomUUID()`
+   - **Python:** `secrets` module (`secrets.token_hex()`, `secrets.token_urlsafe()`)
+   - **Go:** `crypto/rand.Read()`
+   - **Java:** `java.security.SecureRandom`
+   - **Ruby:** `SecureRandom.hex()`
+   - **Browser JavaScript:** `crypto.getRandomValues()`
+   - **Rust:** `rand::rngs::OsRng` or the `getrandom` crate
+   - **C/C++:** `getrandom(2)` on Linux, `BCryptGenRandom` on Windows
+
+   Never use `Math.random()`, `random.random()`, `rand()`, or `mt_rand()` for any value that affects security. The convenience of these functions does not justify the risk.
+
+2. **Understand entropy sources.** On Linux, `/dev/urandom` reads from the kernel entropy pool seeded by hardware interrupts, disk timing, network events, and CPU jitter (RDRAND/RDSEED on modern Intel/AMD processors). On modern kernels (5.6+), `/dev/urandom` blocks until sufficient initial entropy is available at boot, resolving the historical `/dev/random` vs `/dev/urandom` debate. On modern Linux, `/dev/urandom` is correct for all cryptographic purposes.
+
+   On Windows, `BCryptGenRandom` (via CNG) draws from a kernel-mode CSPRNG seeded by hardware and environmental noise. On macOS, `SecRandomCopyBytes` uses the kernel's Fortuna-based CSPRNG. All major cloud providers (AWS Nitro, GCP, Azure) provide hardware-backed entropy to guest VMs.
+
+3. **Size tokens correctly.** Insufficient randomness makes brute-force feasible. Minimum sizes for security-sensitive values:
+   - **Session tokens:** 128 bits (16 bytes), encoded as 32 hex characters or 22 base64url characters
+   - **API keys:** 256 bits (32 bytes) for long-lived credentials
+   - **Encryption keys:** Match the algorithm (AES-128 needs 128 bits, AES-256 needs 256 bits)
+   - **CSRF tokens:** 128 bits minimum
+   - **Password reset tokens:** 128 bits minimum, single-use
+   - **Salts for password hashing:** 128 bits minimum (16 bytes), unique per user
+
+4. **Never reuse nonces.** AES-GCM nonces must be unique per key -- reusing a nonce with the same key completely breaks GCM's authentication guarantee and leaks plaintext via XOR of ciphertexts. This is not a theoretical weakness; it is a complete practical break of the encryption.
+
+   For AES-GCM with 96-bit nonces, use a counter (if you can guarantee no resets across crashes, restarts, and failovers) or random nonces (safe for up to 2^32 encryptions per key before birthday collision risk becomes unacceptable per NIST SP 800-38D). Rotate the encryption key well before reaching this limit.
+
+5. **Seed correctly in containers and VMs.** Containers and VMs may have low entropy at boot because they lack hardware interrupt diversity. Verify entropy health by checking `/proc/sys/kernel/random/entropy_avail` on Linux -- values below 256 indicate a problem. Cloud providers seed guest entropy from hardware RNGs via virtio-rng. For on-premise VMs, ensure virtio-rng is configured or install `haveged`. Kubernetes pods inherit the host's entropy pool -- verify on the host, not inside the container.
+
+6. **Audit for insecure randomness.** Search codebases for these patterns and flag them as security vulnerabilities when used for tokens, keys, nonces, or any value an attacker benefits from predicting:
+   - `Math.random` (JavaScript) -- xorshift128+, predictable after 2 outputs
+   - `random.random`, `random.randint` (Python) -- Mersenne Twister, predictable after 624 outputs
+   - `rand()`, `srand()` (C/C++) -- implementation-defined, typically LCG
+   - `mt_rand()`, `rand()` (PHP) -- Mersenne Twister
+   - `time()` or timestamps used as seeds
+   - UUID libraries that do not document CSPRNG usage internally
+
+## Details
+
+### Why Math.random() Is Predictable
+
+JavaScript's `Math.random()` uses xorshift128+ in V8 (Chrome, Node.js) and SpiderMonkey (Firefox). These are pseudorandom number generators (PRNGs) designed for speed and statistical distribution, not unpredictability.
+
+The older Mersenne Twister (MT19937) maintains 624 32-bit state words with a linear recurrence relation. After observing 624 consecutive outputs, an attacker can reconstruct the complete internal state and predict all future outputs with certainty. The xorshift128+ generator has a smaller state (128 bits) and is even easier to reverse -- in some implementations, two consecutive outputs are sufficient to recover the full state.
+
+The attack is practical: if an application exposes generated values (sequential resource IDs derived from Math.random, leaked tokens in logs, pagination cursors, or even CSS animation timing), an attacker collecting enough outputs can predict every future "random" value the application will generate. This enables forging session tokens, predicting CSRF tokens, and guessing password reset links.
+
+### Birthday Paradox and Nonce Collision
+
+For a random n-bit nonce, the probability of at least one collision among k values exceeds 50% when k approaches 2^(n/2). This is the birthday paradox applied to cryptographic nonces:
+
+- **64-bit nonce:** Collision likely after ~2^32 (4 billion) uses -- insufficient for high-volume systems
+- **96-bit GCM nonce:** Collision likely after ~2^48 (281 trillion) uses -- safe for most applications
+- **128-bit nonce:** Collision likely after ~2^64 uses -- safe for virtually all applications
+
+For AES-GCM with 96-bit random nonces, NIST SP 800-38D recommends limiting invocations to 2^32 per key to keep the collision probability below 2^-32. In practice, this means rotating the encryption key after approximately 4 billion encryptions. For high-volume systems (millions of encryptions per second), this limit is reached in under an hour -- key rotation must be automated.
+
+### CSPRNG Comparison
+
+| Source            | Platform  | Entropy Source                      | Blocks at Boot         | Fork-Safe | VM-Safe          |
+| ----------------- | --------- | ----------------------------------- | ---------------------- | --------- | ---------------- |
+| `/dev/urandom`    | Linux     | Kernel pool (HW interrupts, RDRAND) | Yes (kernel 5.6+)      | Yes       | Needs virtio-rng |
+| `getrandom(2)`    | Linux     | Same as urandom, no FD needed       | Yes                    | Yes       | Needs virtio-rng |
+| `BCryptGenRandom` | Windows   | CNG kernel CSPRNG                   | N/A                    | Yes       | Yes              |
+| `arc4random`      | BSD/macOS | ChaCha20-based CSPRNG               | Yes                    | Yes       | Yes              |
+| `RDRAND/RDSEED`   | Intel/AMD | CPU hardware RNG                    | No (available at boot) | Yes       | Yes (direct HW)  |
+
+`getrandom(2)` is preferred over reading `/dev/urandom` directly because it avoids file descriptor exhaustion and provides clear blocking semantics. Most language-level CSPRNGs (`crypto.randomBytes`, `secrets.token_bytes`, `crypto/rand.Read`) call `getrandom(2)` or the platform equivalent internally.
+
+**Fork safety note:** After `fork()`, the parent and child processes share PRNG state. A non-fork-safe PRNG produces identical "random" values in both processes. OS-level CSPRNGs handle this correctly by re-seeding after fork, but userspace PRNGs (including some older implementations of OpenSSL's `RAND_bytes`) may not. This is especially relevant in pre-forking server architectures.
+
+### Common Vulnerable Patterns by Language
+
+Each language ecosystem has specific insecure randomness patterns that appear frequently in security audits:
+
+- **JavaScript/Node.js:** `Math.random()` for session tokens, `uuid` package versions that used Math.random internally (fixed in modern versions), timestamp-based token generation with `Date.now().toString(36)`
+- **Python:** `random.choice()` for password generation, `random.randint()` for OTP codes, `hashlib.md5(str(time.time()))` for tokens
+- **Java:** `java.util.Random` (not `SecureRandom`) for token generation, `System.currentTimeMillis()` as seeds, `UUID.randomUUID()` is safe (uses SecureRandom) but `new Random().nextLong()` is not
+- **PHP:** `mt_rand()` for CSRF tokens (extremely common in legacy PHP), `uniqid()` which is timestamp-based and predictable, `rand()` for password reset tokens
+- **Go:** `math/rand` instead of `crypto/rand` -- the package names are similar enough to cause confusion, especially for developers new to Go
+
+### Token Generation Best Practices
+
+Generate tokens as raw random bytes, then encode for transport:
+
+- **Hex encoding** (`token_hex`): Doubles the byte length. 16 bytes becomes 32 characters. Universally safe in URLs, headers, databases, and logs.
+- **Base64url encoding** (`token_urlsafe`): ~33% overhead. 16 bytes becomes 22 characters. URL-safe without escaping, no padding characters. Preferred for compact tokens in URLs and headers.
+- **Raw bytes:** Appropriate only for internal binary protocols or when stored directly in a binary column.
+
+Include the generation timestamp either embedded in the token structure or stored server-side for expiration enforcement. Tokens without expiration are permanent credentials that accumulate attack surface over time -- a token generated three years ago may still be valid if no expiration policy exists.
+
+For high-security tokens (password reset, email verification), store only the cryptographic hash of the token in the database. When the user presents the token, hash it and compare against the stored hash. This prevents token theft via database compromise -- even if the attacker has full database access, they cannot extract valid tokens.
+
+### Randomness in Distributed Systems
+
+Distributed systems introduce additional randomness challenges:
+
+- **Clock-based seeds across replicas:** If multiple replicas seed their PRNG with the system clock at startup, they may produce identical sequences. This is especially problematic in auto-scaling groups where multiple instances start simultaneously. CSPRNGs that draw from OS entropy avoid this, but userspace PRNGs initialized from `time()` produce correlated outputs.
+
+- **Kubernetes pod restarts:** When a pod restarts, the application re-initializes. If the application maintains an in-memory counter for AES-GCM nonces, the counter resets to zero, potentially reusing nonces from before the restart. Counter-based nonces must be persisted or replaced with random nonces.
+
+- **Serverless cold starts:** Serverless functions may share the same OS-level entropy pool with other tenants. Major cloud providers (AWS Lambda, Google Cloud Functions, Azure Functions) ensure adequate entropy isolation, but verify this for less common or self-hosted serverless platforms.
+
+- **Test environments with snapshots:** VM snapshots capture the PRNG state. Restoring from a snapshot and running multiple instances produces identical "random" outputs from userspace PRNGs. OS-level CSPRNGs re-seed after snapshot restoration on modern hypervisors, but application-level PRNGs may not.
+
+- **Database-generated UUIDs:** When the database generates UUIDs (PostgreSQL `gen_random_uuid()`, MySQL `UUID()`), verify the database's CSPRNG quality. PostgreSQL uses the OS CSPRNG and is safe. MySQL's `UUID()` generates UUIDv1 (timestamp-based, not random and predictable) -- use `UUID_TO_BIN(UUID(), 1)` with care or generate UUIDv4 in the application layer using a verified CSPRNG.
+
+- **Load balancer session affinity tokens:** Some load balancers generate session tokens using weak PRNGs. If your infrastructure generates tokens at any layer, audit the randomness source at that layer.
+
+### Entropy Monitoring
+
+For production systems that depend on cryptographic randomness, monitor entropy health as a metric:
+
+- On Linux, export `/proc/sys/kernel/random/entropy_avail` as a Prometheus metric or CloudWatch custom metric
+- Set alerts when entropy drops below 256 bits (indicating potential starvation)
+- On application startup, log the entropy available and the CSPRNG source being used
+- In CI/CD pipelines, verify that test environments have adequate entropy (Docker containers running integration tests with cryptographic operations may encounter entropy starvation under heavy parallel test load)
+
+## Anti-Patterns
+
+1. **Using `Math.random()` or `random.random()` for security tokens.** These are pseudorandom, not cryptographically secure. Their internal state is recoverable from observed outputs. Use the platform CSPRNG: `crypto.randomBytes()` (Node.js), `secrets.token_hex()` (Python), `crypto/rand.Read()` (Go). This is the single most common cryptographic error in application code.
+
+2. **Seeding with the current time.** `srand(time(NULL))` produces 1-second resolution seeds. An attacker who knows approximately when the token was generated (within a day) can brute-force all 86,400 possible seeds in milliseconds on commodity hardware. CSPRNGs do not require manual seeding -- they draw entropy from the OS kernel automatically.
+
+3. **Using UUIDv4 as security tokens without verifying the CSPRNG source.** UUIDv4 provides 122 bits of randomness, which is adequate in size, but many UUID libraries use non-cryptographic PRNGs internally (Java's `UUID.randomUUID()` uses `SecureRandom` and is safe, but not all languages guarantee this). Verify that your UUID library documents CSPRNG usage, or generate tokens directly from `crypto.randomBytes()` and format them yourself.
+
+4. **Reusing nonces across encryption operations.** AES-GCM nonce reuse with the same key reveals the XOR of two plaintexts and destroys authentication entirely. This is a complete, practical, immediate break of the encryption -- not a theoretical weakness. Use a counter or random nonces with key rotation well before the birthday bound.
+
+5. **Ignoring entropy starvation in containers.** Containers without access to adequate host entropy may block on random number generation (causing latency spikes and timeouts) or produce low-quality randomness from a poorly seeded pool. Check entropy availability at application startup and fail fast with a clear, specific error message if insufficient entropy is detected. Do not silently fall back to a weaker randomness source -- degraded randomness is worse than a visible failure because it creates a false sense of security.
+
+6. **Rolling your own PRNG.** Implementing a custom random number generator for security purposes is almost always wrong. Even well-known algorithms (Mersenne Twister, xorshift) are not cryptographically secure. The OS-provided CSPRNG has been vetted by cryptographers, formally analyzed, and tested against known attacks. Use it directly through the language's standard library. The only valid reason to implement a custom CSPRNG is if you are a professional cryptographer building a specialized system -- and even then, you would use a vetted design like ChaCha20-based construction with OS entropy seeding.
+
+7. **Insufficient token length for the use case.** Using 64-bit tokens where 128-bit tokens are needed. A 64-bit token has only 2^64 possible values. At 1 billion guesses per second (feasible with modern hardware), brute-forcing a 64-bit token takes approximately 584 years -- but distributed attacks and GPU acceleration reduce this significantly. 128-bit tokens provide a comfortable security margin (2^128 is approximately 3.4 x 10^38 possible values) and should be the minimum for any security-sensitive token.

package/dist/agents/skills/claude-code/security-cryptographic-randomness/skill.yaml

@@ -0,0 +1,41 @@
+name: security-cryptographic-randomness
+version: '1.0.0'
+description: Cryptographically secure random number generation -- CSPRNG, entropy sources, nonce generation, and why Math.random() will get you breached
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-symmetric-encryption
+  - security-asymmetric-encryption
+  - security-hashing-fundamentals
+  - security-hmac-signatures
+  - security-session-management
+  - owasp-cryptography
+stack_signals: []
+keywords:
+  - CSPRNG
+  - entropy
+  - random number generation
+  - nonce
+  - initialization vector
+  - IV
+  - Math.random
+  - crypto.getRandomValues
+  - /dev/urandom
+  - token generation
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/security-dependency-auditing/SKILL.md

@@ -0,0 +1,156 @@
+# Dependency Auditing
+
+> Your application is 90% third-party code -- scan it for known vulnerabilities, lock it
+> to exact versions, and have a strategy for when a critical CVE drops on a Friday
+> afternoon
+
+## When to Use
+
+- Setting up dependency vulnerability scanning for a project
+- Responding to a CVE in a direct or transitive dependency
+- Designing an update strategy that balances security with stability
+- Auditing lockfile integrity to detect supply chain tampering
+- Evaluating SCA (Software Composition Analysis) tools
+- Meeting compliance requirements for dependency management
+
+## Threat Context
+
+The 2021 Log4Shell vulnerability (CVE-2021-44228, CVSS 10.0) affected nearly every Java
+application through the ubiquitous Log4j library -- a single JNDI lookup string in any
+user input could trigger remote code execution. Organizations with dependency scanning and
+automated update pipelines patched within hours; those without took weeks or months, with
+some remaining vulnerable for over a year. The 2018 event-stream npm package compromise
+inserted a cryptocurrency-stealing payload targeting the Copay Bitcoin wallet into a
+transitive dependency used by millions of projects. The 2022 node-ipc sabotage by its own
+maintainer demonstrated that even trusted, widely-used packages can become intentionally
+malicious (the maintainer added code to overwrite files on systems with Russian or
+Belarusian IP addresses). Your application's security is the security of its weakest
+dependency, and most applications have hundreds of transitive dependencies that no
+developer has ever reviewed.
+
+## Instructions
+
+1. **Use lockfiles and verify their integrity.** `package-lock.json` (npm), `yarn.lock`,
+   `pnpm-lock.yaml`, `Pipfile.lock` (Python), `go.sum` (Go), `Gemfile.lock` (Ruby).
+   Lockfiles pin exact versions and record integrity hashes (SHA-512 for npm, SHA-256 for
+   Go). Run `npm ci` (not `npm install`) in CI to install exactly what the lockfile
+   specifies. `npm ci` deletes `node_modules` and installs from scratch using only the
+   lockfile, failing if `package-lock.json` and `package.json` are out of sync. This
+   ensures reproducible builds and prevents silent dependency resolution changes.
+
+2. **Scan dependencies in CI.** Run `npm audit`, `pip-audit`, `bundle audit`, or a
+   commercial SCA tool (Snyk, Sonatype Nexus, Dependabot, Trivy) in every CI pipeline.
+   Fail the build for critical and high severity vulnerabilities -- these represent known
+   exploitable weaknesses with public proof-of-concept code. Triage medium and low
+   severity vulnerabilities on a weekly cadence. Do not let vulnerability counts
+   accumulate into the hundreds, which creates alert fatigue and masks genuine threats.
+
+3. **Understand transitive dependencies.** A direct dependency with zero vulnerabilities
+   can bring in a transitive dependency with critical vulnerabilities. `npm ls --all`
+   shows the full dependency tree. `npm audit` scans the entire tree, not just direct
+   dependencies. Audit the depth of your dependency tree: if your application has 5 direct
+   dependencies but 500 transitive dependencies, your actual attack surface is 500
+   packages, each of which can introduce vulnerabilities, malicious code, or supply chain
+   risk.
+
+4. **Design an update strategy.** Semantic versioning provides a heuristic: patch versions
+   (1.2.x) are safe to auto-merge after CI passes, minor versions (1.x.0) are usually
+   safe but need testing, major versions (x.0.0) require manual review for breaking
+   changes. Use Dependabot or Renovate to automate PR creation for dependency updates.
+   Group minor/patch updates into weekly PRs to reduce PR noise. Review major updates
+   individually. Set auto-merge for patch updates that pass CI to reduce the backlog.
+
+5. **Maintain a vulnerability response playbook.** When a critical CVE drops: (1) identify
+   if the vulnerable package is in your dependency tree (`npm ls <package>`,
+   `pip show <package>`, `go mod graph | grep <package>`), (2) check if a patched version
+   exists, (3) if yes, update and deploy immediately, (4) if no patch exists, evaluate
+   mitigations (WAF rules, input validation, feature flags to disable affected
+   functionality), (5) monitor for exploit attempts in logs. The playbook should be
+   documented, tested, and executable by any on-call engineer, not just the security team.
+
+6. **Pin and minimize dependencies.** Fewer dependencies mean less attack surface. Before
+   adding a dependency, evaluate: can we implement this functionality in 50 lines of
+   code? Is the package actively maintained (commits in the last 6 months)? How many
+   transitive dependencies does it bring? What is the package's security history? Use
+   tools like bundlephobia (npm) to assess the weight. A 2-line utility function does not
+   justify adding a package with 40 transitive dependencies.
+
+## Details
+
+### SCA Tool Comparison
+
+| Tool           | Type            | Auto PRs | CI Integration | Best For                             |
+| -------------- | --------------- | -------- | -------------- | ------------------------------------ |
+| npm audit      | Built-in        | No       | Yes            | Basic JS/TS scanning                 |
+| Snyk           | Commercial/Free | Yes      | Yes            | Developer-friendly, comprehensive    |
+| Dependabot     | GitHub-native   | Yes      | Yes            | GitHub repos, automatic PRs          |
+| Renovate       | Open source     | Yes      | Yes            | Flexible, self-hostable, multi-PM    |
+| Trivy          | Open source     | No       | Yes            | Container and filesystem scanning    |
+| Sonatype Nexus | Enterprise      | Yes      | Yes            | Policy engine, enterprise compliance |
+
+Recommendation: Dependabot or Renovate for automated update PRs, plus Snyk or Trivy for
+vulnerability scanning in CI. The combination of automated PRs and CI scanning covers
+both proactive updating and reactive vulnerability detection.
+
+### Supply Chain Attack Taxonomy
+
+- **Typosquatting**: Publishing `express-js` or `expresss` to catch typos of `express`.
+  The malicious package has a similar name and may even re-export the real package's
+  functionality while executing a payload.
+- **Dependency confusion**: Publishing a public package with the same name as a private
+  internal package. Package managers may prefer the public registry version, pulling in
+  the attacker's code. Mitigate with scoped packages and registry configuration.
+- **Maintainer compromise**: Stolen npm tokens, compromised GitHub accounts, or social
+  engineering to gain publish access. The event-stream attack used this vector.
+- **Malicious update**: A trusted package pushes a version containing malicious code. May
+  be intentional (node-ipc) or result of compromised credentials.
+- **Build-time compromise**: Modifying CI/CD scripts or build tools (Codecov attack).
+
+### Lockfile Manipulation Attacks
+
+An attacker with PR access can modify the lockfile to point to a different package version
+or a malicious registry URL. The lockfile diff is often large, auto-generated, and
+skipped during code review. Lockfile-lint and lockfile-lint-api verify that all packages
+resolve to the expected registry. Include lockfile review in the code review process:
+review the `resolved` URLs in the lockfile for unexpected registries, and reject PRs that
+modify the lockfile without corresponding `package.json` changes.
+
+### Emergency Patching Workflow
+
+1. Security advisory received (via email, GitHub advisory, or CVE database alert)
+2. Check if the vulnerable package is in any service's dependency tree
+3. Identify all affected services and their deployment environments
+4. Check if a patched version is available
+5. If patched: update lockfile, run tests, deploy to staging, verify, deploy to production
+6. If no patch: implement WAF rule or configuration workaround, disable affected feature
+   via feature flag, set daily reminder to check for patch
+7. Post-incident: add the package to enhanced monitoring, review whether the dependency
+   is still necessary
+
+## Anti-Patterns
+
+1. **No lockfile in the repository.** Without a lockfile, `npm install` resolves the
+   latest version of every dependency at install time, meaning builds are non-reproducible
+   and a malicious update is automatically pulled in on the next install. Always commit
+   lockfiles to version control.
+
+2. **Ignoring audit warnings.** "There are 47 moderate vulnerabilities" becomes background
+   noise and is ignored entirely. This is how Log4Shell persists in production for months.
+   Triage vulnerabilities: fix critical and high immediately, schedule medium and low for
+   weekly review, document accepted risks with justification.
+
+3. **Updating dependencies only when something breaks.** Waiting until a production
+   incident forces a dependency update means you are always updating under pressure with
+   no time for proper testing. Proactive weekly updates are less risky than emergency
+   updates under a security incident.
+
+4. **Trusting download counts as a security signal.** Popular packages get compromised
+   too -- event-stream had millions of weekly downloads. Evaluate: maintenance activity
+   (recent commits), security audit history, dependency depth (fewer transitive deps is
+   better), and whether the package has multiple maintainers.
+
+5. **Using `npm install` in CI instead of `npm ci`.** `npm install` can modify the
+   lockfile if `package.json` and `package-lock.json` diverge, producing a build with
+   different dependency versions than what was tested locally. `npm ci` installs exactly
+   what the lockfile specifies and fails on any discrepancy. Use `npm ci` in CI for
+   reproducible, auditable builds.

package/dist/agents/skills/claude-code/security-dependency-auditing/skill.yaml

@@ -0,0 +1,39 @@
+name: security-dependency-auditing
+version: '1.0.0'
+description: Vulnerability scanning, lockfile integrity, update strategies, and managing the security risk of third-party dependencies
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-sbom-provenance
+  - security-code-signing
+  - security-shift-left-design
+  - owasp-dependency-security
+stack_signals: []
+keywords:
+  - dependency audit
+  - vulnerability scanning
+  - SCA
+  - npm audit
+  - Snyk
+  - Dependabot
+  - lockfile
+  - CVE
+  - supply chain
+  - transitive dependency
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/security-deserialization-attacks/SKILL.md

@@ -0,0 +1,180 @@
+# Deserialization Attacks
+
+> Deserialization reconstructs objects from byte streams -- and in most languages, that
+> reconstruction executes code, meaning an attacker who controls the serialized input controls
+> what code runs on your server
+
+## When to Use
+
+- Reviewing code that deserializes data from untrusted sources (user input, network, files)
+- Evaluating the security of data interchange formats in an application architecture
+- Assessing whether Java `ObjectInputStream`, Python `pickle`, PHP `unserialize()`, Ruby
+  `Marshal.load()`, or YAML `load()` are used with external data
+- Designing APIs or message formats and choosing between serialization approaches
+- Investigating suspicious RCE (remote code execution) vectors in a web application
+- Auditing session management that stores serialized objects in cookies or URL parameters
+
+## Threat Context
+
+Insecure deserialization consistently ranks among the most severe vulnerability classes
+because it directly enables remote code execution -- the attacker does not need to find a
+separate code injection point; the deserialization mechanism itself executes arbitrary code:
+
+- **Equifax breach (2017, CVE-2017-5638)**: An Apache Struts vulnerability allowed remote
+  code execution through a crafted `Content-Type` header that triggered OGNL expression
+  evaluation during deserialization. The attacker gained shell access to servers containing
+  145.5 million Americans' personal data. The vulnerability had a patch available two months
+  before the breach; Equifax failed to apply it.
+- **Apache Commons Collections (2015)**: Security researchers published a gadget chain in
+  Apache Commons Collections that achieved arbitrary command execution through Java
+  deserialization. Because Commons Collections was on the classpath of virtually every Java
+  enterprise application (including WebLogic, JBoss, Jenkins, and WebSphere), this single
+  disclosure made thousands of production systems immediately exploitable.
+- **Jenkins (CVE-2016-0792)**: A deserialization vulnerability in Jenkins allowed
+  unauthenticated remote code execution. The exploit used a Groovy-based gadget chain to
+  execute operating system commands. Jenkins instances exposed to the internet were
+  compromised en masse for cryptocurrency mining and as pivot points into internal networks.
+- **PHP object injection**: PHP's `unserialize()` reconstructs objects and invokes magic
+  methods (`__wakeup()`, `__destruct()`, `__toString()`). Attackers chain these magic methods
+  across classes in the application and its dependencies to achieve file writes, SQL
+  injection, or remote code execution. WordPress plugins have been repeatedly vulnerable to
+  this pattern.
+
+## Instructions
+
+1. **Understand why deserialization is inherently dangerous.** Native serialization formats
+   (Java `Serializable`, Python `pickle`, PHP `serialize`, Ruby `Marshal`, .NET
+   `BinaryFormatter`) are not data formats -- they are code formats. Deserializing an object
+   means: allocating memory for the object, setting its fields to attacker-controlled values,
+   and executing lifecycle methods (constructors, finalizers, magic methods). The attacker does
+   not need to inject new code -- they manipulate existing classes in the application's
+   classpath to form a chain of method calls that achieves their objective. This is the gadget
+   chain concept.
+
+2. **Never deserialize untrusted input with native serialization.** This is the primary rule
+   and it has no exceptions:
+   - **Java**: Do not use `ObjectInputStream.readObject()` on data from users, APIs, message
+     queues, cookies, or any source the attacker can influence. Replace with JSON (Jackson,
+     Gson) or Protocol Buffers. If `ObjectInputStream` cannot be removed, use
+     `ObjectInputFilter` (Java 9+) to allowlist specific classes before deserialization begins.
+   - **Python**: Do not use `pickle.loads()` on untrusted data. The pickle protocol executes
+     arbitrary Python bytecode during deserialization -- there is no safe way to use pickle
+     with untrusted input. Use JSON (`json.loads()`), MessagePack, or Protocol Buffers.
+   - **PHP**: Do not use `unserialize()` on user-controlled input. Use `json_decode()`. If
+     `unserialize()` is required, PHP 7+ supports an `allowed_classes` option that restricts
+     which classes can be instantiated -- use it with an explicit allowlist, never `true`.
+   - **Ruby**: Do not use `Marshal.load()` on untrusted data. Use JSON (`JSON.parse()`) or
+     MessagePack.
+   - **YAML**: In Python, use `yaml.safe_load()`, never `yaml.load()`. In Ruby, use
+     `YAML.safe_load()`, never `YAML.load()` (Ruby 3.1+ changed the default, but explicit
+     `safe_load` is still preferred for clarity). The unsafe YAML loaders instantiate
+     arbitrary classes from YAML tags (`!!python/object/apply:os.system`).
+   - **.NET**: Do not use `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer`, or
+     `ObjectStateFormatter`. Microsoft has deprecated `BinaryFormatter` as of .NET 8 due to
+     its inherent insecurity. Use `System.Text.Json` or Protocol Buffers.
+
+3. **Use data-only interchange formats.** JSON, Protocol Buffers, MessagePack, FlatBuffers,
+   and similar formats serialize data (strings, numbers, arrays, maps) without encoding type
+   information or executable behavior. Deserializing JSON cannot instantiate objects or
+   execute methods -- it produces primitive data structures that the application then validates
+   and maps to domain objects explicitly. This separation between data parsing and object
+   construction is the fundamental defense against deserialization attacks.
+
+4. **When native serialization cannot be removed, apply defense in depth:**
+   - **Allowlist classes before deserialization.** Java's `ObjectInputFilter` (JEP 290) lets
+     you specify exactly which classes may be deserialized. Reject everything not on the list.
+     This must happen before `readObject()` is called -- once deserialization begins, gadget
+     chain code has already executed.
+   - **Verify integrity before deserialization.** Sign serialized payloads with HMAC. Before
+     deserializing, verify the signature. If the attacker cannot forge the signature, they
+     cannot inject a malicious payload. This requires the signing key to remain secret.
+   - **Isolate deserialization in a sandbox.** Run deserialization in a restricted process
+     with minimal permissions, seccomp filters, or a container with no network access. If the
+     gadget chain achieves code execution, the sandbox limits the damage.
+   - **Monitor and alert on deserialization failures.** Deserialization exceptions (unexpected
+     class, invalid stream) often indicate an exploitation attempt. Log these failures with
+     full context and alert on anomalous patterns.
+
+5. **Audit the codebase for deserialization points.** Search for all uses of native
+   deserialization APIs and categorize each by trust level of the input:
+   - `ObjectInputStream` (Java), `pickle.loads` / `pickle.load` (Python), `unserialize`
+     (PHP), `Marshal.load` (Ruby), `yaml.load` (Python/Ruby), `BinaryFormatter.Deserialize`
+     (.NET), `readObject` (Java), `XMLDecoder` (Java)
+   - For each occurrence: is the input from a trusted source (internal-only, signed)? If not,
+     replace with a safe alternative or add allowlisting and integrity verification.
+
+## Details
+
+- **How gadget chains work -- the Java example in detail**: The attacker's goal is to execute
+  `Runtime.getRuntime().exec("malicious command")`. But `Runtime` is not `Serializable`, so
+  it cannot appear directly in the stream. Instead, the attacker finds a chain of serializable
+  classes where: Class A's `readObject()` calls a method on a field. That field is set to an
+  instance of Class B, whose method calls another method on another field. This chain
+  continues until a class in the chain invokes `Runtime.exec()` or equivalent through
+  reflection, `ProcessBuilder`, or `ScriptEngine`. The Apache Commons Collections gadget
+  chain uses `InvokerTransformer` (which calls any method via reflection) wired through
+  `ChainedTransformer` and triggered by `LazyMap` during `readObject()`. The attacker crafts
+  a serialized object graph that arranges these classes in the right configuration. Tools like
+  ysoserial automate gadget chain construction for known library combinations.
+
+- **Python pickle as a universal code execution primitive**: The pickle protocol includes an
+  opcode (`REDUCE`) that calls any callable with any arguments. A malicious pickle payload
+  can contain `os.system("rm -rf /")` or equivalent. Unlike Java gadget chains, which require
+  finding suitable classes on the classpath, pickle exploitation is trivial because the
+  protocol itself supports arbitrary function calls. There is no safe subset of pickle.
+  `pickle.loads(untrusted_data)` is equivalent to `eval(untrusted_data)`.
+
+- **Deserialization in session management and view state**: Some web frameworks store session
+  state by serializing objects, encoding them (often Base64), and placing them in cookies or
+  hidden form fields. If the serialized data is not signed or encrypted, the attacker
+  modifies the cookie to inject a malicious serialized object. ASP.NET ViewState, Java JSF
+  ViewState, and PHP session serialization have all been exploited this way. The mitigation
+  is to sign and encrypt serialized session data (ASP.NET's `machineKey` or a modern
+  equivalent) and to verify the signature before deserialization.
+
+- **YAML deserialization as a code execution vector**: YAML supports language-specific type
+  tags that instruct the parser to instantiate objects. In Python,
+  `!!python/object/apply:os.system ["id"]` executes the `id` command. In Ruby,
+  `!!ruby/object:Gem::Installer` has been used to achieve code execution. The `safe_load`
+  variants restrict the parser to basic data types (strings, numbers, lists, maps) and reject
+  type tags. Any YAML parser configured to support arbitrary type tags is a deserialization
+  vulnerability.
+
+## Anti-Patterns
+
+1. **Deserializing user input with native serialization formats.** Accepting serialized Java
+   objects in an HTTP request body, a message queue, or a cookie. The application may validate
+   the deserialized object after construction, but by then the gadget chain has already
+   executed. Deserialization attacks happen during deserialization, not after. Use JSON or
+   Protocol Buffers for all external data interchange.
+
+2. **Allowlisting after deserialization.** Checking the class of the deserialized object after
+   `readObject()` returns. This is too late. The gadget chain executes inside `readObject()`
+   before control returns to the caller. Allowlisting must happen before deserialization, using
+   `ObjectInputFilter` in Java or equivalent mechanisms that reject disallowed classes before
+   their `readObject()` methods execute.
+
+3. **Using `yaml.load()` instead of `yaml.safe_load()`.** In Python's PyYAML library,
+   `yaml.load()` without a `Loader` argument (or with `Loader=yaml.FullLoader` prior to
+   PyYAML 6.0) can instantiate arbitrary Python objects from YAML tags. A YAML configuration
+   file that an attacker can modify becomes a remote code execution vector.
+   `yaml.safe_load()` restricts parsing to basic data types and is safe for untrusted input.
+
+4. **Trusting serialized objects in cookies or URL parameters.** Storing a serialized user
+   object in a cookie without signing it, then deserializing it on each request. The attacker
+   modifies the cookie to contain a gadget chain payload. Even Base64 encoding provides no
+   protection -- it is encoding, not encryption or signing. If serialized data must travel
+   through the client, sign it with HMAC and verify the signature before deserialization.
+
+5. **Filtering known gadget chains instead of fixing the root cause.** Maintaining a blocklist
+   of known dangerous classes (e.g., blocking `InvokerTransformer` in Java deserialization
+   filters). New gadget chains are discovered regularly as new libraries are added to the
+   classpath. A blocklist is always incomplete. Use an allowlist of the specific classes the
+   application legitimately deserializes, or replace native serialization entirely.
+
+6. **Assuming JSON is always safe.** While JSON itself is a data-only format, JSON parsing
+   libraries that support polymorphic type handling can reintroduce deserialization
+   vulnerabilities. Jackson's `@JsonTypeInfo` with `JsonTypeInfo.Id.CLASS` allows the JSON
+   payload to specify which Java class to instantiate, enabling gadget chain attacks through
+   JSON. Use `JsonTypeInfo.Id.NAME` with an explicit type allowlist, or avoid polymorphic
+   deserialization entirely.