@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/gemini-cli/security-tls-fundamentals/SKILL.md

@@ -0,0 +1,186 @@
+# TLS Fundamentals
+
+> TLS 1.3 with ECDHE key exchange, AES-256-GCM or ChaCha20-Poly1305 ciphers, and valid
+> certificates -- the minimum bar for all network communication
+
+## When to Use
+
+- Setting up HTTPS for a web application or API
+- Configuring TLS cipher suites on a server or load balancer
+- Diagnosing TLS handshake failures or certificate errors
+- Evaluating whether to support TLS 1.2 alongside TLS 1.3
+- Implementing certificate pinning or transparency monitoring
+- Reviewing a system's transport security posture
+
+## Threat Context
+
+Without TLS, all network traffic is plaintext -- readable and modifiable by anyone on the
+network path (ISP, WiFi operator, compromised router, government surveillance).
+Man-in-the-middle (MITM) attacks can intercept credentials, session tokens, and sensitive
+data. Historical TLS vulnerabilities demonstrate that protocol version and configuration
+matter enormously:
+
+- **POODLE** (2014, CVE-2014-3566): Exploited CBC padding in SSL 3.0 and TLS 1.0 to
+  decrypt HTTPS traffic byte-by-byte. Forced the deprecation of SSL 3.0.
+- **BEAST** (2011, CVE-2011-3389): Exploited a predictable IV in TLS 1.0 CBC mode to
+  decrypt data via chosen-plaintext attack.
+- **CRIME/BREACH** (2012-2013): Exploited TLS-level and HTTP-level compression to extract
+  secrets (session cookies) from encrypted traffic by observing response size changes.
+- **Heartbleed** (2014, CVE-2014-0160): A buffer over-read in OpenSSL's heartbeat extension
+  leaked up to 64KB of server memory per request -- including private keys, session tokens,
+  and user credentials. Affected 17% of the internet's HTTPS servers.
+- **FREAK** (2015, CVE-2015-0204): Forced downgrade to export-grade 512-bit RSA, breakable
+  in hours.
+- **Logjam** (2015, CVE-2015-4000): Forced downgrade to 512-bit Diffie-Hellman, breakable
+  by nation-state attackers.
+
+TLS 1.3 eliminates all known protocol-level attacks present in TLS 1.0-1.2 by removing
+every insecure cryptographic option from the protocol specification itself.
+
+## Instructions
+
+1. **Deploy TLS 1.3 as the primary protocol.** TLS 1.3 (RFC 8446, 2018) removes all
+   insecure cryptographic options from the protocol: no RSA key exchange (no forward
+   secrecy), no CBC mode (padding oracle risk), no static DH, no custom DH groups, no RC4,
+   no 3DES, no MD5, no SHA-1 in signatures. The only key exchange is ephemeral
+   Diffie-Hellman (ECDHE or DHE). The only ciphers are AEAD: AES-128-GCM, AES-256-GCM,
+   ChaCha20-Poly1305. The handshake completes in 1 round trip (1-RTT) instead of 2
+   (TLS 1.2), reducing latency by one full network round trip.
+
+2. **Support TLS 1.2 as fallback only when required.** Some clients (older Android,
+   enterprise proxies, legacy IoT devices) do not support TLS 1.3. If TLS 1.2 must be
+   supported, restrict cipher suites to those providing both forward secrecy and AEAD:
+   - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+   - `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+   - `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
+   - `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`
+
+   All require ECDHE (forward secrecy) and AEAD ciphers. Reject all non-ECDHE and
+   non-AEAD cipher suites.
+
+3. **Disable TLS 1.0 and TLS 1.1 completely.** Both are deprecated by IETF (RFC 8996,
+   2021). TLS 1.0 is vulnerable to BEAST and POODLE. TLS 1.1 uses obsolete cipher
+   constructions and has no security advantage over TLS 1.2. PCI DSS 3.2+ requires TLS 1.2
+   as the minimum for cardholder data environments. All major browsers dropped TLS 1.0/1.1
+   support in 2020.
+
+4. **Use valid certificates from a trusted Certificate Authority.** Obtain certificates from
+   Let's Encrypt (free, automated via ACME protocol), or a commercial CA for extended
+   validation. Every certificate must: match the domain name via Subject Alternative Name
+   (SAN), be within its validity period, chain to a trusted root CA in the client's trust
+   store, and use RSA-2048+ or ECDSA P-256+ keys. Prefer ECDSA certificates -- they produce
+   smaller signatures and faster handshakes than equivalent-security RSA certificates.
+
+5. **Enable HSTS (HTTP Strict Transport Security).** The `Strict-Transport-Security` header
+   instructs browsers to only connect via HTTPS, preventing SSL stripping attacks where a
+   MITM downgrades HTTPS to HTTP. Set `max-age=31536000; includeSubDomains; preload` for
+   maximum protection. Submit to the HSTS preload list (hstspreload.org) so browsers enforce
+   HTTPS before the first connection. See `security-hsts-preloading` for preload list
+   submission details.
+
+6. **Understand the TLS 1.3 handshake sequence.** Client sends ClientHello containing
+   supported cipher suites and key shares for ECDHE. Server responds with ServerHello
+   (selected cipher suite and key share), then immediately sends encrypted
+   EncryptedExtensions, Certificate, CertificateVerify (proving possession of the private
+   key), and Finished. Client verifies the certificate chain, computes the shared secret
+   from the key exchange, sends its own Finished message.
+
+   Total: 1 round trip to first application data. With 0-RTT resumption, returning clients
+   can send application data on the very first packet, at the cost of replay vulnerability
+   for that 0-RTT data.
+
+7. **Monitor Certificate Transparency logs.** Certificate Transparency (CT) is a public,
+   append-only log of all certificates issued by participating CAs. Monitor CT logs for your
+   domains using crt.sh, Google's CT monitoring, or commercial services (Censys, SSLMate).
+   CT monitoring detects misissued certificates (a CA issues a cert for your domain to
+   someone else) and unauthorized certificates (an internal CA issues a cert that should not
+   exist). React to unexpected certificates immediately -- they indicate either a compromised
+   CA or an attacker with CA access.
+
+## Details
+
+- **Cipher suite anatomy (TLS 1.3 vs 1.2)**: TLS 1.3 cipher suite names are simplified:
+  `TLS_AES_256_GCM_SHA384` specifies only the AEAD cipher and hash function. Key exchange
+  is always ECDHE, negotiated separately via the `supported_groups` extension, so it does
+  not appear in the cipher suite name. TLS 1.2 cipher suite names encode everything:
+  `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` means ECDHE key exchange, RSA authentication,
+  AES-256-GCM encryption, SHA-384 PRF. This difference reflects TLS 1.3's design
+  philosophy: fewer choices, all of them secure.
+
+- **Forward secrecy and why it matters**: Ephemeral key exchange (ECDHE) generates a fresh
+  key pair for every session. The session key is derived from the ephemeral exchange, and
+  after the session ends, the ephemeral private key is discarded. If the server's long-term
+  private key (the certificate key) is later compromised -- through theft, legal compulsion,
+  or cryptanalytic breakthrough -- past session keys cannot be recovered because they were
+  never derived from the long-term key. Without forward secrecy (static RSA key exchange in
+  TLS 1.2), a compromised certificate key decrypts all previously recorded traffic.
+  Nation-state adversaries are known to record encrypted traffic for later decryption;
+  forward secrecy renders this strategy ineffective.
+
+- **0-RTT resumption: performance vs security tradeoff**: TLS 1.3 supports 0-RTT data on
+  resumed connections, where the client sends encrypted application data alongside the
+  ClientHello using a pre-shared key from a previous session. This eliminates the handshake
+  round trip entirely for returning clients. However, 0-RTT data is fundamentally
+  replayable -- an attacker can capture the first flight and replay it to the server. Only
+  use 0-RTT for idempotent requests (GET, HEAD). Never permit 0-RTT for state-changing
+  operations (POST, PUT, DELETE, financial transactions). Most server implementations reject
+  0-RTT by default or limit it to explicitly marked endpoints. If latency is not critical,
+  disable 0-RTT entirely.
+
+- **Certificate chain validation in detail**: The client performs five verification steps:
+  (1) the leaf certificate's Subject Alternative Name matches the requested domain,
+  (2) the certificate is within its validity period (notBefore to notAfter),
+  (3) each certificate in the chain is signed by the issuer certificate above it,
+  (4) the chain terminates at a root CA in the client's trust store,
+  (5) no certificate in the chain appears on a Certificate Revocation List (CRL) or has
+  been revoked via OCSP (Online Certificate Status Protocol). OCSP stapling allows the
+  server to include a signed, timestamped OCSP response in the TLS handshake, so the client
+  does not need to contact the CA separately.
+
+- **ChaCha20-Poly1305 vs AES-GCM**: AES-GCM is faster on hardware with AES-NI instructions
+  (most modern x86 and ARM processors). ChaCha20-Poly1305 is faster on devices without AES
+  hardware acceleration (older mobile devices, IoT). Both provide equivalent security.
+  Supporting both cipher suites ensures optimal performance across all client hardware.
+  Server-side cipher preference should select AES-GCM when the client supports AES-NI and
+  ChaCha20-Poly1305 otherwise.
+
+## Anti-Patterns
+
+1. **Supporting SSL 3.0, TLS 1.0, or TLS 1.1.** These protocol versions are vulnerable to
+   known attacks (POODLE, BEAST, FREAK, Logjam) and have been formally deprecated by the
+   IETF. Disable them completely. There is no legitimate reason to support them in 2024+.
+
+2. **Allowing non-AEAD cipher suites in TLS 1.2.** CBC-mode ciphers are vulnerable to
+   padding oracle attacks (Lucky Thirteen, POODLE). RC4 is cryptographically broken. Only
+   permit GCM or ChaCha20-Poly1305 AEAD cipher suites. If a client cannot negotiate an AEAD
+   cipher, the client is too old to trust.
+
+3. **Self-signed certificates in production.** Self-signed certificates provide encryption
+   but no identity verification. Every client must disable certificate validation to connect,
+   which makes MITM attacks trivial -- the attacker presents their own self-signed
+   certificate and the client accepts it. Use Let's Encrypt for free, automated, trusted
+   certificates.
+
+4. **Ignoring certificate expiry and failing to automate renewal.** Let's Encrypt
+   certificates expire after 90 days. Commercial certificates typically last 1 year.
+   Certificate expiry outages are entirely preventable through automation (certbot, Caddy's
+   automatic HTTPS, cloud provider managed certificates). A certificate expiry outage in
+   production indicates an operational maturity failure, not a technical limitation.
+
+5. **TLS termination at the load balancer with plaintext backend traffic.** Terminating TLS
+   at the edge and forwarding plaintext HTTP to backend servers means any compromise of the
+   internal network exposes all traffic in cleartext. East-west traffic within a data center
+   is a common attack vector after initial compromise. Re-encrypt traffic between the load
+   balancer and backends (TLS to backends), or implement end-to-end TLS where the
+   application server terminates TLS directly. At minimum, ensure the internal network is
+   segmented and monitored.
+
+6. **Disabling certificate verification in client code.** Setting `verify=False`,
+   `rejectUnauthorized: false`, or equivalent in HTTP clients to "make it work" during
+   development, then shipping that code to production. This disables all protection against
+   MITM attacks. Fix the certificate issue instead of disabling verification.
+
+7. **Hardcoding cipher suites without a maintenance plan.** Cipher suite recommendations
+   evolve as attacks are discovered. A hardcoded cipher suite list from 2018 may include
+   ciphers that are now deprecated. Use a maintained configuration generator (Mozilla SSL
+   Configuration Generator) and review cipher suite configuration annually.

package/dist/agents/skills/gemini-cli/security-tls-fundamentals/skill.yaml

@@ -0,0 +1,40 @@
+name: security-tls-fundamentals
+version: "1.0.0"
+description: TLS 1.3 handshake, cipher suite selection, certificate chain validation, and why TLS 1.0/1.1 must be disabled
+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-certificate-management
+  - security-hsts-preloading
+  - security-mtls-design
+  - owasp-security-headers
+stack_signals: []
+keywords:
+  - TLS
+  - TLS 1.3
+  - TLS handshake
+  - cipher suite
+  - certificate chain
+  - HTTPS
+  - SSL
+  - forward secrecy
+  - certificate authority
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/security-trust-boundaries/SKILL.md

@@ -0,0 +1,152 @@
+# Trust Boundaries
+
+> Every security control exists because data crosses from a trusted zone to a less-trusted one -- identify the boundaries first, then concentrate defenses there
+
+## When to Use
+
+- Drawing or reviewing a system architecture diagram and need to identify where security controls belong
+- Designing a microservices architecture and need to determine which service-to-service calls require authentication
+- Evaluating whether an internal API needs the same input validation as a public API
+- Planning network segmentation or firewall rules
+- Assessing the blast radius of a compromised component
+
+## Threat Context
+
+The majority of exploitable vulnerabilities exist at trust boundary crossings -- the points where data moves between zones of different privilege levels. SQL injection occurs at the boundary between application code and the database query engine. XSS occurs at the boundary between server-generated content and the browser's rendering engine. SSRF occurs at the boundary between user-controlled input and server-side HTTP clients. API authorization failures occur at the boundary between an authenticated session and resource-level access control.
+
+If you cannot draw your trust boundaries on an architecture diagram, you cannot reason about where your controls should be, and you will place them in the wrong locations -- or omit them entirely.
+
+## Instructions
+
+1. **Enumerate trust zones.** A trust zone is a region where all components operate at the same privilege level and share the same trust assumptions. Identify each zone by asking: "If component A is compromised within this zone, what else can the attacker reach without crossing another control?"
+
+   Common zones in modern architectures:
+   - **Public internet** (untrusted): User browsers, mobile apps, unknown third-party callers
+   - **DMZ / edge** (minimally trusted): Load balancers, CDN edge nodes, API gateways, WAFs
+   - **Application tier** (trusted): Application servers, microservices, background workers
+   - **Data tier** (highly trusted): Databases, caches, persistent message queues
+   - **Secrets / control plane** (maximally trusted): Secrets managers (Vault, KMS), PKI infrastructure, CI/CD pipeline credentials
+   - **Cloud infrastructure zones**: VPC, subnet, security group, Kubernetes namespace, pod network, service mesh sidecar
+
+   Each zone should have a clearly stated trust assumption documented alongside the architecture: "Components in this zone have been authenticated at the gateway but have not been authorized for specific resources."
+
+2. **Draw boundaries between zones.** Every point where data crosses from one zone to another is a trust boundary. Mark these with dashed lines on architecture diagrams -- this is standard DFD notation for trust boundaries.
+
+   Label each boundary with:
+   - The direction of data flow (unidirectional or bidirectional)
+   - The data classification of what crosses it (public, internal, confidential, restricted)
+   - The transport mechanism (HTTPS, gRPC, message queue, shared filesystem)
+
+3. **Apply the boundary security principle.** At every trust boundary crossing, apply all five control categories:
+   - **Validate all input**: Never trust data arriving from a less-trusted zone. Validate schema, types, ranges, and business rules. Reject malformed input before processing.
+   - **Authenticate the caller**: Verify identity before processing any request. This applies at every boundary, not just the perimeter.
+   - **Authorize the action**: Verify that the authenticated caller has permission for the specific operation on the specific resource. Authentication without authorization is an open door with a guest book.
+   - **Encrypt data in transit**: TLS 1.3 minimum for all boundary crossings. Mutual TLS (mTLS) for service-to-service calls in zero-trust architectures where both parties must prove identity.
+   - **Log the crossing**: Record who crossed, what data was accessed, when, and from where. Boundary crossing logs are the primary data source for intrusion detection and incident forensics.
+
+4. **Classify boundary types.** Different boundary types require different control implementations:
+   - **Network boundaries**: Firewall rules, load balancer configurations, API gateway policies, VPN tunnels. Controls are infrastructure-level. Managed by operations/platform teams.
+   - **Process boundaries**: Inter-process communication (IPC), shared memory, Unix domain sockets, pipes between processes on the same host. Often overlooked because they are "local," but a compromised process can attack its neighbors through these channels.
+   - **Application boundaries**: Module imports, function calls that cross security domains within the same process. Example: the admin module calling the user module -- the admin module trusts its own input, but the user module should not trust data arriving from any caller without validation.
+   - **Data boundaries**: Encryption and decryption points, serialization and deserialization, encoding and decoding. Every point where data changes representation is a boundary where injection, corruption, or information leakage can occur.
+
+5. **Assess blast radius per zone.** For each zone, answer: "If an attacker gains code execution in this zone, what is the maximum damage they can inflict before hitting another boundary?" The answer defines the blast radius.
+
+   Minimize blast radius through:
+   - Limiting cross-zone access to explicit allow-lists (deny by default)
+   - Using separate credentials and service accounts per zone (compromising one zone does not yield credentials for another)
+   - Applying network-level segmentation (security groups, firewall rules) as a defense-in-depth layer behind application-level controls
+   - Implementing circuit breakers that detect anomalous cross-boundary traffic patterns and shed load
+
+6. **Validate boundary effectiveness.** For each identified trust boundary, verify these invariants:
+   - Can an unauthenticated request cross it? If yes, the authentication control is missing or misconfigured.
+   - Can a request from a lower-trust zone bypass input validation? If yes, there is a validation gap.
+   - Can data exfiltrate across it without generating a log entry? If yes, the logging control is incomplete.
+   - Can a caller in the lower-trust zone escalate to the privilege level of the higher-trust zone? If yes, the authorization boundary is permeable.
+
+   Any "yes" answer represents a boundary gap that must be mitigated before the system can be considered secure at that crossing point.
+
+## Details
+
+### The Implicit Trust Boundary Problem
+
+Most exploitable vulnerabilities arise not from boundaries that were analyzed and found weak, but from boundaries that developers did not recognize as boundaries at all. The most dangerous implicit boundary is the service-to-service call within a "trusted" network.
+
+Example: Microservice A receives user input, performs some validation, and sends a transformed payload to Microservice B via an internal message queue. Developers assume "B only receives messages from A, so B does not need input validation." This assumption is wrong for three reasons:
+
+1. If A is compromised, the attacker controls what B receives.
+2. If the message queue is accessible to other services (most are), any compromised service can send messages to B.
+3. If B is later exposed to another caller (a common architectural evolution), the assumption silently breaks with no warning.
+
+The rule: **treat every deserialization point as a trust boundary.** If a component parses JSON, Protocol Buffers, XML, YAML, or any structured data from any external source -- including "trusted internal" sources -- it must validate the schema and reject malformed input. The cost of redundant validation is negligible. The cost of a missing boundary is a breach.
+
+### Cloud-Native Trust Boundaries
+
+In Kubernetes environments, trust boundaries are layered and each layer has distinct control mechanisms:
+
+- **Ingress controller** (internet to cluster): The primary perimeter boundary. TLS termination, rate limiting, WAF rules, and initial authentication (API key validation, OAuth token verification) happen here.
+- **Service mesh sidecar** (pod to pod): mTLS between services, fine-grained authorization policies (e.g., Istio AuthorizationPolicy), request-level telemetry. The mesh enforces that Service A can only call Service B on specific endpoints with specific methods.
+- **Namespace boundaries** (logical isolation): Kubernetes NetworkPolicy restricts which pods can communicate across namespaces. Namespace-level RBAC controls who can deploy to or read secrets from each namespace.
+- **Node boundaries** (VM-level isolation): Pod scheduling constraints (node affinity, taints/tolerations) ensure sensitive workloads run on dedicated nodes with hardened OS configurations.
+- **Cloud IAM boundaries** (service account permissions): Workload identity binds Kubernetes service accounts to cloud IAM roles with least-privilege policies. A compromised pod can only access the cloud resources its service account is authorized for.
+
+Each layer is a trust boundary with its own authentication, authorization, and audit mechanism. Defense in depth means that compromising one layer does not automatically grant access to the next.
+
+### Zero Trust and the Dissolution of the Perimeter
+
+Traditional network architecture establishes a single hard boundary -- the firewall -- and treats everything inside as trusted. This model fails because:
+
+1. Attackers who breach the perimeter (via phishing, compromised VPN credentials, supply chain attack) have unrestricted lateral movement inside the network.
+2. Cloud and hybrid environments have no single perimeter -- workloads span multiple providers, regions, and network topologies.
+3. Remote work means corporate devices connect from untrusted networks, making the "inside the office firewall" assumption obsolete.
+
+Zero trust eliminates the concept of a trusted interior. Every component boundary is a trust boundary. Every request is authenticated and authorized regardless of network position. This is not about adding more firewalls -- it is about making every service enforce its own boundary controls independently.
+
+The practical implication: service-to-service authentication (mTLS, JWT validation, signed requests) is mandatory, not optional. Network location is no longer a proxy for trust. See `security-zero-trust-principles` for the complete zero trust architecture model.
+
+### Boundary Inventory Checklist
+
+When documenting trust boundaries for a system, verify that each of these common boundary types has been identified and classified:
+
+- **External user to application**: Browser/mobile app to API gateway or web server. The most obvious boundary, but often the only one teams analyze.
+- **Application to database**: Every database connection is a trust boundary. The application authenticates to the database, and the database authorizes queries. SQL injection exploits this boundary.
+- **Service to service**: Every inter-service call in a microservices architecture. Often unprotected because developers assume the internal network is safe.
+- **Application to third-party API**: Outbound calls to payment processors, identity providers, analytics services, email providers. Data leaving your trust zone enters someone else's.
+- **CI/CD pipeline to production**: Deployment credentials, artifact signing, and deployment authorization. A compromised pipeline is a direct path to production.
+- **Admin interface to application**: Administrative endpoints, SSH access, database consoles, monitoring dashboards. These are high-privilege boundaries that attackers specifically target.
+- **Background job to data store**: Batch processors, cron jobs, and queue workers that read from and write to data stores. These often run with elevated privileges and bypass the API-level controls.
+- **Log aggregator boundary**: Application logs flowing to centralized logging (ELK, Splunk, Datadog). Logs may contain sensitive data; the logging pipeline is a data exfiltration path if compromised.
+
+Missing any of these boundaries means missing the threats that exploit them.
+
+### Data Classification Drives Boundary Strength
+
+Not all trust boundaries need identical controls. The strength of controls at a boundary should be proportional to the sensitivity of the data crossing it:
+
+- **Public data** (marketing pages, public API docs): Basic input validation, rate limiting. No encryption requirement beyond standard TLS.
+- **Internal data** (operational metrics, non-sensitive configuration): Input validation, service authentication, TLS. Standard audit logging.
+- **Confidential data** (user PII, business financials): Full boundary controls -- input validation, strong authentication, fine-grained authorization, TLS with certificate pinning, comprehensive audit logging, data masking in logs.
+- **Restricted data** (cryptographic keys, credentials, payment card numbers): Maximum controls -- all confidential controls plus hardware security module (HSM) integration, dual-control access, break-glass procedures for emergency access, real-time alerting on boundary crossings.
+
+Applying maximum controls uniformly across all boundaries is wasteful and creates operational friction that leads teams to bypass controls entirely. Match control strength to data sensitivity.
+
+### Testing Boundary Controls
+
+Boundary controls must be tested, not assumed. For each trust boundary, write tests that verify:
+
+- **Negative authentication tests**: Send requests without credentials, with expired credentials, and with credentials for a different service. All must be rejected.
+- **Input validation at the boundary**: Send malformed payloads, oversized payloads, payloads with unexpected fields, and payloads with type mismatches. The boundary must reject them before they reach business logic.
+- **Authorization enforcement**: Send authenticated requests that attempt to access resources belonging to other principals. The boundary must enforce ownership and permission checks.
+- **Logging verification**: Perform a boundary crossing and verify that the audit log contains the expected entry with caller identity, timestamp, action, and outcome.
+
+These tests serve double duty: they verify the controls work today, and they prevent future regressions when the boundary code is refactored.
+
+## Anti-Patterns
+
+1. **The "trusted internal network" assumption.** Assuming that anything inside the VPC, firewall, or corporate network is inherently safe. Internal networks are compromised routinely -- lateral movement is the single most common post-exploitation technique in breach reports (Mandiant M-Trends, Verizon DBIR). Every service-to-service call crosses a trust boundary even within the same network segment. The internal network is a transport layer, not a security control.
+
+2. **Validating input at the perimeter only.** Placing all input validation at the API gateway or edge proxy and trusting all data downstream. This creates a single point of failure: if any downstream service is reachable by another path (internal message queue, batch job, admin endpoint, debugging interface, or a future integration not yet built), the validation is completely bypassed. Every component must validate input at its own boundary, regardless of what upstream components may have done.
+
+3. **Symmetric trust across an asymmetric boundary.** Two services that mutually trust each other equally when the data flow is asymmetric in risk. If Service A sends user-controlled data to Service B, then B must validate that data even if A is a "trusted" internal service -- because A might be relaying attacker input without modification or with insufficient sanitization. Trust must be proportional to the risk of the data, not the reputation of the sender.
+
+4. **Missing deserialization boundaries.** Deserializing data from any external source (JSON.parse, pickle.loads, Java ObjectInputStream, YAML.load, XML parsing) without treating the deserialization point as a trust boundary. Deserialization of untrusted data is effectively code execution in many languages and frameworks. Every deserialization of data from a less-trusted source must: validate against a strict schema, reject unexpected types and fields, enforce maximum payload size, and use safe deserialization methods (e.g., JSON.parse is generally safe; Java ObjectInputStream is not without explicit class allowlisting; Python pickle is never safe for untrusted input).

package/dist/agents/skills/gemini-cli/security-trust-boundaries/skill.yaml

@@ -0,0 +1,39 @@
+name: security-trust-boundaries
+version: "1.0.0"
+description: Trust boundary identification, data flow diagrams, and the principle that all security controls concentrate at boundary crossings
+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-threat-modeling-process
+  - security-zero-trust-principles
+  - security-microsegmentation
+  - owasp-injection-prevention
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - trust boundary
+  - trust zone
+  - data flow diagram
+  - DFD
+  - attack surface
+  - network segmentation
+  - defense in depth
+  - perimeter
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/security-vault-patterns/SKILL.md

@@ -0,0 +1,155 @@
+# Vault Patterns
+
+> Centralize secrets in a vault, issue dynamic short-lived credentials, encrypt data
+> through a transit engine, and eliminate long-lived secrets from your infrastructure
+
+## When to Use
+
+- Centralizing secrets management across multiple services and environments
+- Replacing long-lived database credentials with dynamic, short-lived ones
+- Implementing envelope encryption for data at rest
+- Managing TLS certificates and PKI infrastructure
+- Designing secrets access patterns for Kubernetes workloads
+- Evaluating HashiCorp Vault vs cloud-native KMS (AWS KMS, GCP KMS, Azure Key Vault)
+
+## Threat Context
+
+Static, long-lived credentials are the most exploited vulnerability in cloud
+environments. The 2019 Capital One breach used stolen IAM credentials that had overly
+broad access and never rotated -- a single misconfigured WAF rule exposed temporary
+credentials that could access S3 buckets containing 106 million customer records. AWS
+reports that exposed access keys are exploited within minutes of being pushed to public
+repositories (automated bots scan GitHub continuously). The 2021 Codecov breach
+exfiltrated credentials from CI/CD environment variables. Dynamic credentials that expire
+in minutes instead of lasting forever reduce the attack window from "indefinitely" to
+"minutes." Vault systems also provide audit trails for every secret access, enabling
+detection of unauthorized access patterns that static credential storage cannot provide.
+
+## Instructions
+
+1. **Choose the right vault architecture.** HashiCorp Vault: self-hosted or HCP Vault
+   (managed), richest feature set, steepest learning curve. AWS Secrets Manager + KMS:
+   cloud-native, simple, integrated with IAM. GCP Secret Manager + Cloud KMS: similar to
+   AWS, integrated with Workload Identity. Azure Key Vault: similar to AWS, integrated
+   with Managed Identity. Sealed Secrets (Bitnami): Kubernetes-specific, encrypts secrets
+   for GitOps workflows. For multi-cloud or on-premise: HashiCorp Vault. For single-cloud
+   with simple requirements: use the native secrets manager.
+
+2. **Use dynamic secrets instead of static credentials.** Vault's database secret engine
+   generates unique database credentials per request with configurable TTL (e.g., 1 hour).
+   When the TTL expires, the credentials are automatically revoked. If a credential is
+   compromised, the blast radius is limited to that credential's TTL and that single
+   consumer. No more shared database passwords in config files. Dynamic secrets exist for
+   databases (PostgreSQL, MySQL, MongoDB), cloud providers (AWS, GCP, Azure IAM), SSH
+   certificates, and PKI certificates.
+
+3. **Implement envelope encryption for data at rest.** Do not store the data encryption
+   key (DEK) alongside the data. Encrypt the DEK with a key encryption key (KEK) managed
+   by the vault's transit engine or KMS. Store the encrypted DEK with the data. To
+   decrypt: send the encrypted DEK to the vault, get back the plaintext DEK, decrypt the
+   data locally. This means the vault never sees your data -- it only manages keys. This
+   pattern is used by AWS S3 server-side encryption, Google Cloud Storage, and Azure
+   Storage encryption.
+
+4. **Authenticate workloads to the vault.** Kubernetes: use the Kubernetes auth method
+   (service account token authentication). AWS: use the IAM auth method (instance profile
+   or IAM role). AppRole: for CI/CD and automated systems (role ID + secret ID). Never
+   hardcode vault tokens. Every workload authenticates with the identity it already has
+   (Kubernetes service account, AWS IAM role, etc.). The authentication method proves the
+   workload's identity without introducing new credentials.
+
+5. **Implement PKI and certificate management.** Vault's PKI secret engine acts as a
+   certificate authority. Issue short-lived TLS certificates (24-72 hours) to services.
+   Short-lived certificates eliminate the need for revocation lists (CRLs) because they
+   expire before an attacker can meaningfully exploit a compromised certificate. Automate
+   certificate issuance and renewal via cert-manager (Kubernetes) or Vault Agent.
+
+6. **Seal and unseal operations.** HashiCorp Vault uses a seal mechanism: the master key
+   is split into shares (Shamir's Secret Sharing). A threshold of shares (e.g., 3 of 5)
+   is required to unseal the vault. In production, use auto-unseal with a cloud KMS (the
+   KMS key unseals the vault master key). This eliminates the need for human operators to
+   provide key shares during restarts while maintaining the security property that the
+   vault's data is encrypted at rest.
+
+## Details
+
+### Dynamic Secrets Lifecycle
+
+The lifecycle of a dynamic database credential: application authenticates to Vault with
+its Kubernetes service account token, requests database credentials from the database
+secret engine, Vault creates a unique database user with the required grants and a 1-hour
+TTL, Vault returns the username and password, application uses them for database
+connections, TTL expires, Vault revokes the database user by executing `DROP USER`.
+Compare this to static credentials: created once by a human, shared across services via
+environment variables or config files, never expire, never rotated, compromise is
+permanent and undetectable.
+
+### Transit Engine for Application-Level Encryption
+
+The transit engine performs encrypt/decrypt operations without exposing the key material.
+The API is simple: `POST /transit/encrypt/my-key` with plaintext data returns ciphertext;
+`POST /transit/decrypt/my-key` with ciphertext returns plaintext. Key rotation is
+transparent: new versions of the key are created, old ciphertexts can still be decrypted,
+re-encryption can be done in batches using `POST /transit/rewrap/my-key`. This allows key
+rotation without downtime and without re-encrypting all data immediately.
+
+### Vault in Kubernetes
+
+Three integration patterns: Vault Agent Injector (sidecar that fetches secrets and writes
+them to a shared volume as files, best for dynamic secrets that need refresh), CSI Secret
+Store Driver (mounts secrets as files via the Container Storage Interface, simpler but
+no automatic refresh), External Secrets Operator (syncs vault secrets to Kubernetes
+Secret objects, best for static secrets that change infrequently). Recommendation: Vault
+Agent for workloads that need dynamic secrets with automatic renewal, External Secrets
+Operator for simpler static secret synchronization.
+
+### Disaster Recovery
+
+Vault contains all your secrets -- losing it is catastrophic. Implement: regular
+automated snapshots (Vault snapshot agent), cross-region replication (Vault Enterprise
+performance replication), a DR cluster (Vault Enterprise DR replication with automated
+failover), and tested restore procedures. Test recovery quarterly by restoring a snapshot
+to a staging environment and verifying all secret engines are functional. Document the
+recovery procedure so it can be executed under pressure during an actual incident.
+
+### Vault vs Cloud-Native KMS Decision Matrix
+
+| Criterion              | HashiCorp Vault      | Cloud-Native KMS/SM      |
+| ---------------------- | -------------------- | ------------------------ |
+| Dynamic secrets        | Full support         | Limited (IAM roles only) |
+| Multi-cloud            | Yes                  | No (vendor-locked)       |
+| Transit encryption     | Built-in             | KMS encrypt/decrypt only |
+| PKI/certificate mgmt   | Full CA engine       | ACM (AWS), limited       |
+| Operational complexity | High (self-managed)  | Low (managed service)    |
+| Cost                   | Infrastructure + ops | Per-API-call pricing     |
+
+For teams with dedicated platform engineering, Vault provides the richest feature set.
+For small teams on a single cloud, the cloud-native option is operationally simpler.
+
+## Anti-Patterns
+
+1. **Vault with a single unseal key.** If one person has the unseal key and they are
+   unavailable, no one can unseal the vault after a restart. Use Shamir's Secret Sharing
+   with a 3-of-5 (or similar) threshold, or auto-unseal with a cloud KMS. Single points
+   of failure in secrets infrastructure are unacceptable.
+
+2. **Long-lived vault tokens.** Vault tokens with no TTL or very long TTLs defeat the
+   purpose of centralized secrets management. If a token is stolen, it provides indefinite
+   access. Use short-lived tokens (1-24 hours) with renewal, and configure max TTLs on
+   token roles so that even renewed tokens eventually expire.
+
+3. **Vault as a dumb key-value store.** Using Vault only to store static secrets misses
+   its most powerful feature: dynamic secrets. If you are storing a database password in
+   Vault and sharing it across 10 services, you have centralized the static credential
+   but have not eliminated it. Use dynamic secrets to generate unique, short-lived
+   credentials per consumer.
+
+4. **No audit logging.** Vault has a built-in audit device that logs every operation
+   including the accessor, timestamp, and path accessed. Failing to enable it means you
+   cannot detect unauthorized secret access, compromised tokens, or policy violations.
+   Enable audit logging to at least one persistent backend (syslog, file, socket).
+
+5. **Skipping seal/unseal understanding.** Deploying Vault without understanding the seal
+   mechanism leads to outages when the vault is sealed (due to restart, crash, or manual
+   seal) and no one knows how to unseal it. Document the unseal procedure, test it during
+   incident drills, and ensure multiple team members can perform it.

package/dist/agents/skills/gemini-cli/security-vault-patterns/skill.yaml

@@ -0,0 +1,39 @@
+name: security-vault-patterns
+version: '1.0.0'
+description: Centralized secrets management using vault systems -- HashiCorp Vault, cloud KMS, sealed secrets, dynamic credentials, and the principle of secrets as cattle not pets
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-secrets-lifecycle
+  - security-environment-variable-risks
+  - security-credential-storage
+  - owasp-secrets-management
+stack_signals: []
+keywords:
+  - vault
+  - HashiCorp Vault
+  - secrets management
+  - KMS
+  - key management
+  - sealed secrets
+  - dynamic credentials
+  - secret engine
+  - transit encryption
+  - envelope encryption
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []