@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/gemini-cli/security-authentication-flows/skill.yaml

@@ -0,0 +1,42 @@
+name: security-authentication-flows
+version: '1.0.0'
+description: Secure design of login, registration, password reset, magic link, and SSO authentication flows -- preventing account enumeration, credential theft, and session fixation
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-credential-storage
+  - security-session-management
+  - security-mfa-design
+  - security-cryptographic-randomness
+  - owasp-auth-patterns
+  - owasp-csrf-protection
+  - api-authentication-patterns
+stack_signals: []
+keywords:
+  - login
+  - registration
+  - password reset
+  - magic link
+  - SSO
+  - OAuth
+  - OIDC
+  - account enumeration
+  - brute force
+  - credential stuffing
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/security-capability-based-security/SKILL.md

@@ -0,0 +1,158 @@
+# Capability-Based Security
+
+> Replace ambient authority ("who are you?") with explicit capabilities ("what token do you hold?") -- eliminating confused deputy attacks by making every permission a transferable, revocable, unforgeable object
+
+## When to Use
+
+- Designing a plugin or extension system where untrusted code runs with limited permissions
+- Building a sandboxed execution environment (serverless functions, browser iframes, Deno)
+- Preventing confused deputy attacks in service-to-service communication
+- Implementing fine-grained, delegatable permissions that can be scoped and revoked
+- Evaluating whether ambient authority (ACLs/RBAC) or capability-based models better fit your threat model
+- Designing pre-signed URLs or capability URLs for resource sharing
+
+## Threat Context
+
+The confused deputy problem (first described by Norm Hardy in 1988) occurs when a privileged program is tricked into misusing its authority on behalf of an attacker. Classic example: a compiler service has write access to billing logs through ambient authority (its process identity grants access); an attacker passes a crafted output filename that targets the billing log, and the compiler overwrites it using authority that was granted for a different purpose entirely. In ACL-based systems, the compiler's identity grants write access regardless of who initiated the request or for what purpose. In capability-based systems, the compiler only possesses capabilities explicitly passed to it by the caller -- no ambient authority exists to misuse.
+
+CSRF is a web-specific confused deputy: the browser attaches cookies (ambient authority) to cross-origin requests, allowing a malicious site to act with the user's authority on any site the user is logged into. SameSite cookies are a partial mitigation; capability-based tokens (where the request must explicitly include a token, not relying on automatic cookie attachment) eliminate the attack class entirely.
+
+Pre-signed URLs (S3, GCS, Azure Blob) are real-world capabilities deployed at massive scale: unforgeable, time-limited, scoped to a specific action on a specific resource -- the architectural opposite of ambient authority.
+
+## Instructions
+
+1. **Understand the core principle: authority follows the reference.** A capability is an unforgeable reference that both designates a resource and authorizes an action on it. Possessing the capability is sufficient to perform the action -- no additional identity check is needed. This contrasts fundamentally with ACL/RBAC systems where the system asks "who are you?" and checks a permission list associated with the resource. In capability systems, the question is "what token do you hold?" The capability itself carries the authorization.
+
+2. **Design capabilities as unforgeable tokens.** A capability must be impossible to guess or fabricate. Three implementation approaches:
+   - **Cryptographic opaque tokens:** CSPRNG-generated strings (128+ bits of randomness) mapped to permissions on the server side. The holder presents the token; the server looks up the associated rights in a database. Simple to implement, requires server-side state.
+   - **Signed structured tokens:** A payload containing resource ID, allowed action, expiration, and constraints, signed with HMAC or a digital signature. The server verifies the signature without a database lookup. Macaroons extend this model with chainable caveats.
+   - **Object references in memory-safe runtimes:** In memory-safe languages and sandboxed environments, an object reference is itself a capability because the runtime guarantees it cannot be forged (no pointer arithmetic, no access to arbitrary memory addresses). This is the foundation of the object-capability (ocap) model.
+
+   The critical property across all approaches is unforgeability: a party that does not possess a capability cannot create one through guessing, computation, or manipulation.
+
+3. **Apply the Principle of Least Authority (POLA).** When creating a new process, plugin, service call, or function invocation, grant only the capabilities it needs -- nothing more. Do not pass a database connection object when the function only needs to read one table. Do not pass a write capability when read suffices. Do not pass an unbounded-time capability when a 5-minute window is appropriate.
+
+   Capability systems make POLA natural because authority is explicit at the call site: the caller constructs and passes exactly the set of capabilities the callee needs. In contrast, ACL systems make POLA difficult because services accumulate ambient authority through their identity, and restricting that authority requires modifying the central permission list rather than the call site.
+
+4. **Support attenuation (narrowing but never expanding rights).** A holder of a write capability should be able to derive a read-only capability from it and pass that derived capability to a less-trusted party. Attenuation is strictly one-directional: you can narrow capabilities but never widen them.
+
+   If Alice has `(document:X, read+write, expires:2025-12-31)`, she can derive `(document:X, read-only, expires:2025-06-30)` -- same or narrower action scope, same or earlier expiration -- and share it with Bob. Bob cannot re-derive write access or extend the expiration. Macaroons implement attenuation via HMAC-chained caveats that can only be appended, never removed.
+
+5. **Implement revocation.** Capabilities that cannot be revoked are permanent, transferable, irrevocable grants of authority -- unacceptable for most production systems. Revocation strategies ordered by complexity:
+   - **Short expiration:** The capability auto-expires after a fixed duration. No active revocation needed, but no early revocation possible. Suitable for pre-signed URLs (5-minute to 24-hour lifetimes).
+   - **Revocation list:** Maintain a set of revoked capability IDs checked at the enforcement point on every use. Adds a lookup on every check but enables immediate revocation.
+   - **Caretaker pattern:** An intermediary object mediates all access. Disabling the caretaker blocks all capabilities routed through it. Useful for revoking an entire delegation chain at once (e.g., revoking a team's access by disabling the team's caretaker).
+   - **Epoch-based rotation:** Issue capabilities with an epoch number. Incrementing the epoch invalidates all capabilities from the previous epoch. Coarse-grained but simple to implement.
+
+6. **Apply to real-world systems.** Capability-based security is not theoretical -- it is deployed at massive scale in production systems:
+   - **Deno:** `--allow-read=/tmp` grants a filesystem read capability scoped to `/tmp`. Without the flag, the runtime has zero filesystem access. Every permission is an explicit capability grant on the command line.
+   - **Browser iframes:** The `sandbox` attribute strips all ambient capabilities (scripts, forms, popups, top navigation). Adding `allow-scripts` restores only the script execution capability.
+   - **Docker:** `--cap-drop ALL --cap-add NET_BIND_SERVICE` drops all Linux kernel capabilities and selectively restores only the ability to bind privileged ports below 1024.
+   - **Pre-signed URLs:** S3, GCS, and Azure Blob pre-signed URLs embed the resource, action, expiration, and a cryptographic signature. Anyone possessing the URL can perform the specified action without any additional authentication.
+   - **WebAssembly Component Model:** Wasm components declare their required imports (capabilities). The host runtime provides only the capabilities it chooses. Unfulfilled imports mean the component simply cannot access the corresponding resource.
+
+## Details
+
+### Capability vs ACL Comparison
+
+| Property                   | ACL / RBAC                                                               | Capability-Based                                                           |
+| -------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
+| Authority model            | Ambient (identity checked against resource's permission list)            | Explicit (token/reference held by the caller)                              |
+| Confused deputy resistance | Vulnerable (program uses its own ambient authority on attacker's behalf) | Resistant by construction (program only has capabilities passed to it)     |
+| Delegation                 | Complex (requires delegating identity or modifying ACLs)                 | Natural (pass the capability token to the delegate)                        |
+| Attenuation                | Not native (requires creating new restricted roles)                      | Native (derive narrower capability from existing one)                      |
+| Revocation                 | Immediate (remove entry from ACL)                                        | Requires explicit mechanism (expiration, revocation list)                  |
+| Centralized audit          | Natural (one ACL per resource, query centrally)                          | Harder (capabilities are distributed, must track delegation chains)        |
+| Integration effort         | Standard in most frameworks (RBAC middleware)                            | Requires architectural changes (explicit capability passing at call sites) |
+
+Many production systems use both models: ACL-based identity checks at the perimeter (who can log in, what features can they access) and capability-based tokens for specific resource operations (pre-signed URLs for file access, scoped API tokens for third-party integrations, sandboxed execution environments for plugins).
+
+### Macaroons (Google, 2014)
+
+Macaroons are bearer credentials that support decentralized attenuation through HMAC-chained caveats. Published by Google researchers, they are the most sophisticated capability token format in widespread use.
+
+**Construction:**
+
+1. The **root macaroon** is created by the resource server: `HMAC(root_key, identifier)`. This represents the unrestricted capability.
+2. **First-party caveats** add verifiable restrictions: `new_mac = HMAC(previous_mac, "time < 2025-06-01")`. Each caveat further restricts what the token authorizes. Any holder can append caveats, but no one can remove them -- removal would require recomputing the HMAC chain from the root key, which only the issuing server possesses.
+3. **Third-party caveats** enable delegated verification: the macaroon includes a caveat requiring a discharge macaroon from a third-party service (e.g., "holder must present proof of authentication from IdP X"). This enables federated authorization without sharing secrets between services.
+
+**Example attenuation chain:**
+
+- Root: "access to /data/reports" (issued by resource server)
+- Caveat 1: "action = read" (added by API gateway to restrict to read-only)
+- Caveat 2: "source_ip in 10.0.0.0/8" (added by network proxy to restrict to internal network)
+- Caveat 3: "expires < 2025-06-01T12:00:00Z" (added by delegating user to set a time limit)
+
+Each party in the chain narrows the capability independently without contacting the others. The resource server verifies the entire chain by recomputing the HMAC from the root key and evaluating all caveats against the current request context.
+
+### Capability URLs
+
+URLs like `https://app.com/share/a8f3c9d1e2b4f5a6789012345678abcd` where the random token in the path is the capability. Knowing the URL grants access -- no additional authentication required. This pattern is used extensively by Google Docs ("anyone with the link can view"), Figma, Notion, Dropbox, WeTransfer, and most modern file-sharing services.
+
+**Security considerations:**
+
+- **URL logging:** Web servers, reverse proxies, CDNs, and browser history all log full URLs including the capability token. Anyone with access to logs gains access to the shared resource.
+- **Referrer header leakage:** When a user clicks a link on the shared page, the referrer header sends the full URL (including the capability token) to the destination site. Mitigate with `Referrer-Policy: no-referrer` or `Referrer-Policy: origin`.
+- **Uncontrolled sharing:** Users copy and paste capability URLs freely. Unlike ACL-based sharing where removing a user from the list revokes their access, a forwarded capability URL continues to work for anyone who receives it.
+- **Search engine indexing:** If a capability URL is posted publicly or linked from a crawlable page, search engines will index it. Use `robots.txt` exclusions and `X-Robots-Tag: noindex` headers on capability URL paths.
+
+Mitigations: short expiration times, access logging with alerting on anomalous patterns, download count limits, and the ability to revoke (regenerate) the sharing link from the UI.
+
+### Capabilities in Microservice Architecture
+
+In microservice systems, capabilities solve the confused deputy problem that arises when Service A calls Service B on behalf of User X. With ambient authority (service-to-service mTLS + RBAC), Service B checks that Service A is authorized -- but Service A might be calling on behalf of any user, including an attacker who found an SSRF vulnerability in Service A.
+
+With capability-based inter-service communication:
+
+1. The API gateway issues a scoped capability token when the user authenticates: `{resource: "order:123", action: "read", user: "alice", expires: "2025-06-01T12:05:00Z", sig: "..."}`.
+2. Service A receives this capability and forwards it to Service B when making the downstream call.
+3. Service B verifies the capability token's signature, checks expiration, and validates that the requested action matches the capability's scope.
+4. If an attacker exploits an SSRF in Service A, they cannot forge a capability token (they do not have the signing key), and any capability they intercept is scoped to the original user's authorized actions and expires quickly.
+
+This pattern is implemented by Google's ALTS (Application Layer Transport Security) and by service mesh systems using SPIFFE-based identity with request-level authorization tokens.
+
+### Object Capabilities in Programming Languages
+
+The object-capability (ocap) model uses language-level object references as capabilities. In a true ocap language:
+
+- **No global mutable state:** A module cannot access any resource it was not explicitly given a reference to at construction time.
+- **No ambient imports:** Standard library access (filesystem, network, system clock, random number generator) is mediated through capability objects passed as constructor parameters, not through global import statements that any code can call.
+- **No runtime reflection on capabilities:** A module cannot enumerate, inspect, or forge object references it does not hold.
+
+Languages with ocap properties: E (the original ocap language by Mark S. Miller), Newspeak (Gilad Bracha), Monte (descendant of E), and the WebAssembly Component Model. JavaScript approaches ocap through Hardened JS (SES -- Secure ECMAScript) using `lockdown()` and `Compartment`, deployed in production by Agoric for blockchain smart contracts and by MetaMask for secure plugin isolation.
+
+The practical benefit of the ocap model: security analysis becomes tractable because authority flows are visible in the code structure. You can audit a module's authority by examining its constructor parameters and method arguments -- there is no hidden ambient access to search for. If a module's constructor does not receive a filesystem capability, it provably cannot access the filesystem, regardless of what code it contains.
+
+### Capability Patterns in API Design
+
+Capability-based thinking improves API security even in systems that use ACLs as the primary authorization model:
+
+- **Scoped API tokens:** Instead of issuing a single API key with full account access, issue tokens scoped to specific resources and actions. GitHub's fine-grained personal access tokens are an example: each token specifies which repositories it can access and what operations it can perform.
+
+- **Pre-signed upload URLs:** Instead of giving the client credentials to upload to S3 directly, the server generates a pre-signed PUT URL scoped to a specific object key with a short expiration. The client uploads without ever possessing AWS credentials.
+
+- **Invite links:** Instead of adding a user to a resource's ACL and notifying them, generate a capability URL that grants specific access when followed. The link itself carries the authorization. The recipient does not need an account -- the link is the credential.
+
+- **Delegated tokens for third-party integrations:** When a user connects a third-party app to your service, issue a capability token scoped to exactly the data and actions the integration needs. OAuth 2.0 scopes are a coarse version of this; true capabilities would scope to specific resource instances, not just resource types.
+
+### Auditing Capability-Based Systems
+
+Auditing capabilities requires different approaches than auditing ACLs:
+
+- **ACL audit:** Query the ACL for each resource to see who has access. Centralized and straightforward.
+- **Capability audit:** Track which capabilities have been issued, to whom, with what scope, and whether they have been used. Requires a capability issuance log and usage log.
+
+Best practices for capability auditing: log every capability issuance with the scope, recipient, and expiration; log every capability exercise (successful use) with the resource accessed; alert on capabilities that are used after the expected session lifetime; and periodically enumerate all outstanding capabilities to identify over-permissioned or expired-but-not-revoked tokens.
+
+## Anti-Patterns
+
+1. **Capabilities that cannot be revoked.** A capability with no expiration and no revocation mechanism is a permanent, transferable, irrevocable grant of authority. If the token leaks (logged by a proxy, forwarded via email, scraped from a public page), the authority persists indefinitely. Always include either a short expiration, an active revocation mechanism, or both. The maximum acceptable lifetime depends on the sensitivity of the resource being protected.
+
+2. **Leaking capabilities through logs or URL parameters.** Pre-signed URLs and capability tokens in URL paths are recorded by web servers, proxy servers, CDNs, analytics platforms, browser history, and browser extensions. Use POST request bodies or HTTP headers for capability transmission when the protocol allows it. When URLs must be used (sharing links, email links), enforce short expiration times and monitor access patterns for anomalies.
+
+3. **Ambient authority disguised as capabilities.** An API key that grants access to all resources a user can reach is not a capability -- it is an identity credential with ambient authority formatted as a bearer token. True capabilities are scoped to a specific resource, a specific action, and ideally a specific time window. If revoking one token requires regenerating a single global key that breaks all integrations, the system uses ambient authority regardless of the token format.
+
+4. **Forgeable capabilities.** A capability URL using sequential IDs (`/share/1234`, `/share/1235`) or predictable tokens (MD5 of the resource name, base64-encoded resource ID, timestamp-based generation) is trivially forgeable by enumeration or computation. Capabilities must be unguessable: 128+ bits of CSPRNG output for opaque tokens, or cryptographically signed structured payloads with tamper detection.
+
+5. **All-or-nothing permission scoping.** A capability system that only offers "full access" and "no access" misses the fundamental value proposition. The power of capabilities lies in fine-grained scoping: read vs write vs delete, specific resource vs collection, time-limited vs permanent, single-use vs reusable, specific IP range vs anywhere. Design the capability model with the granularity that the application's security requirements demand -- then enforce it at the verification point.

package/dist/agents/skills/gemini-cli/security-capability-based-security/skill.yaml

@@ -0,0 +1,40 @@
+name: security-capability-based-security
+version: '1.0.0'
+description: Object capabilities vs ambient authority -- unforgeable tokens that grant specific rights, eliminating confused deputy attacks by construction
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-rbac-design
+  - security-abac-design
+  - security-rebac-design
+  - security-zero-trust-principles
+  - owasp-idor-prevention
+stack_signals: []
+keywords:
+  - capability-based security
+  - object capability
+  - ocap
+  - confused deputy
+  - ambient authority
+  - principle of least authority
+  - POLA
+  - unforgeable reference
+  - capability token
+  - Deno permissions
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/security-certificate-management/SKILL.md

@@ -0,0 +1,153 @@
+# Certificate Management
+
+> X.509 certificates are the backbone of internet trust -- manage them correctly or accept
+> that attackers can impersonate any service, intercept any connection, and forge any
+> identity
+
+## When to Use
+
+- Setting up TLS for a new service or domain
+- Automating certificate issuance and renewal with ACME/Let's Encrypt
+- Designing an internal PKI for service-to-service mTLS
+- Evaluating certificate pinning for mobile applications
+- Monitoring Certificate Transparency logs for unauthorized certificates
+- Handling certificate revocation (CRL vs OCSP vs short-lived certs)
+
+## Threat Context
+
+Compromised or mis-issued certificates enable man-in-the-middle attacks at scale. The
+2011 DigiNotar breach resulted in fraudulent certificates for \*.google.com, used by the
+Iranian government to intercept Gmail traffic for 300,000 users -- DigiNotar was
+subsequently removed from all browser trust stores and went bankrupt. The 2015 CNNIC
+incident involved an intermediate CA issuing unauthorized certificates for Google domains,
+leading to CNNIC's removal from Chrome and Firefox trust stores. Certificate Transparency
+(CT) was created in direct response to these incidents to make all certificate issuance
+publicly auditable. Expired certificates cause outages at massive scale: the 2020
+Microsoft Teams outage left millions unable to collaborate, and the 2018 Ericsson LTE
+outage (affecting 32 million users across 11 countries) were both caused by expired
+certificates that no one was monitoring.
+
+## Instructions
+
+1. **Understand the CA hierarchy.** Root CAs (self-signed, stored in browser/OS trust
+   stores) sign intermediate CA certificates, which sign end-entity (leaf) certificates.
+   Best practice: keep root CAs offline (air-gapped HSM). Use intermediate CAs for
+   day-to-day issuance. If an intermediate CA is compromised, revoke it without replacing
+   the root. The root CA private key should be used only to sign intermediate CA
+   certificates and CRLs, and should never be exposed to any networked system.
+
+2. **Automate with ACME.** Use Let's Encrypt (free, automated) for public-facing TLS. The
+   ACME protocol proves domain control through challenges: HTTP-01 (serve a file at
+   `/.well-known/acme-challenge/`), DNS-01 (create a TXT record, required for wildcard
+   certificates), TLS-ALPN-01 (respond during TLS handshake). Use certbot, cert-manager
+   (Kubernetes), or acme.sh. Automate renewal: Let's Encrypt certificates expire in 90
+   days; set renewal at 60 days. Test renewal in staging before production deployment.
+
+3. **Monitor Certificate Transparency logs.** CT logs record all publicly issued
+   certificates in append-only, cryptographically verifiable logs. Since 2018, Chrome
+   requires all new certificates to be logged to CT. Monitor CT logs for your domains to
+   detect unauthorized certificate issuance. Tools: crt.sh (manual search), Facebook CT
+   Monitor, Cert Spotter (SSLMate). Set up automated alerts for any new certificate
+   issued for your domains that you did not request -- this is your early warning system
+   for CA compromise or domain hijacking.
+
+4. **Handle revocation correctly.** CRL (Certificate Revocation List): a signed list of
+   revoked serial numbers, downloaded periodically by clients -- slow to propagate, can be
+   megabytes in size, often stale. OCSP (Online Certificate Status Protocol): real-time
+   check of certificate status, but adds latency and is a privacy concern (the CA sees
+   which sites you visit). OCSP stapling: the server includes a signed OCSP response in
+   the TLS handshake, eliminating the client's need to contact the OCSP responder. Best
+   practice: use OCSP stapling and short-lived certificates. If a cert lives for 24 hours,
+   revocation is unnecessary because it expires before exploitation is meaningful.
+
+5. **Design internal PKI for mTLS.** For service-to-service authentication, run an
+   internal CA (Vault PKI, cfssl, step-ca from Smallstep). Issue short-lived certificates
+   (24-72 hours) to services. Short-lived certificates eliminate the need for revocation
+   infrastructure entirely. Use SPIFFE (Secure Production Identity Framework for Everyone)
+   for standardized service identity URIs. Automate issuance with cert-manager or SPIRE.
+
+6. **Certificate pinning for mobile apps.** Pin the leaf certificate or the public key in
+   mobile apps to prevent MITM via compromised CAs. Include backup pins for rotation. Pin
+   the intermediate CA key (not the leaf) if you want to rotate leaf certificates without
+   app updates. Be cautious: incorrect pinning causes app-breaking outages that require
+   app store updates to fix. Include an escape hatch and test rotation thoroughly.
+
+## Details
+
+### X.509 Certificate Anatomy
+
+A certificate contains: Subject (CN, O, OU -- who the certificate identifies), Issuer
+(the CA that signed it), Serial Number (unique within the CA), Validity Period (Not
+Before / Not After), Public Key (the subject's public key), Signature Algorithm
+(RSA-SHA256, ECDSA-SHA384, etc.), and Extensions. Critical extensions: Subject
+Alternative Name (SAN) lists all domain names and IPs the certificate covers -- modern
+browsers use SAN, not CN. Key Usage specifies allowed operations (digital signature, key
+encipherment). Basic Constraints indicates whether the certificate is a CA. Authority
+Information Access contains the OCSP responder URL and CA issuers URL.
+
+### ACME Protocol Flow
+
+1. Client contacts ACME server and requests a new order for domain(s)
+2. Server returns authorization challenges (HTTP-01, DNS-01, or TLS-ALPN-01)
+3. Client provisions the challenge response (file, DNS record, or TLS extension)
+4. Client notifies server that the challenge is ready
+5. Server validates the challenge (fetches the file, queries DNS, or connects via TLS)
+6. On success, client submits a CSR (Certificate Signing Request)
+7. Server issues the certificate and returns it
+
+Wildcard certificates (\*.example.com) require the DNS-01 challenge because HTTP-01 cannot
+prove control over all subdomains. Let's Encrypt rate limits: 50 certificates per
+registered domain per week, 5 duplicate certificates per week.
+
+### Certificate Lifecycle
+
+Request, Issuance, Deployment, Monitoring, Renewal, Revocation (if needed). The most
+common failure: forgetting to renew, causing an outage. The second most common:
+deploying with an incomplete certificate chain (missing intermediate CA certificates) --
+some clients have the intermediate cached and work fine; others fail with "unable to
+verify" errors, creating intermittent failures that are difficult to diagnose.
+
+### Certificate Monitoring and Expiration Alerts
+
+Set up automated monitoring for certificate expiration across all services. Tools:
+Prometheus with the `blackbox_exporter` (TLS probe checks certificate validity and days
+until expiration), Nagios/Icinga certificate checks, or cloud-native monitoring (AWS
+Config rule for ACM certificate expiration, GCP Certificate Manager alerts). Alert at
+30 days before expiration (informational), 14 days (warning), and 7 days (critical). For
+automated ACME renewal, monitor the renewal process itself -- if renewal fails silently,
+the first sign of trouble should not be a production outage.
+
+### Short-Lived Certificates as Revocation Replacement
+
+If a certificate lives for 24 hours, the maximum exposure window for a compromised
+certificate is 24 hours. Contrast with a 1-year certificate: the compromised certificate
+is valid for up to 1 year unless revocation works perfectly. In practice, revocation
+rarely works: CRL checking is best-effort in most clients (Chrome does not check CRLs
+at all), OCSP has soft-fail behavior (if the OCSP responder is down, most clients accept
+the certificate anyway). Short-lived certificates make revocation irrelevant.
+
+## Anti-Patterns
+
+1. **Self-signed certificates in production.** Self-signed certificates disable the CA
+   trust chain and train users and developers to ignore certificate warnings. Use Let's
+   Encrypt (free, automated) for public services. Use an internal CA for internal
+   services. The only acceptable use of self-signed certificates is local development.
+
+2. **Manual certificate renewal.** Certificates that require human intervention for
+   renewal will expire and cause outages. The question is not "if" but "when." Automate
+   renewal with ACME, cert-manager, or Vault PKI. Monitor expiration dates as a backup.
+
+3. **Incomplete certificate chains.** Deploying a leaf certificate without including the
+   intermediate CA certificates. Some clients have the intermediate cached; others do not.
+   The result is sporadic TLS failures that depend on the client's cache state. Always
+   deploy the full chain: leaf plus all intermediates (not the root).
+
+4. **Certificate pinning without rotation plan.** Pinning a leaf certificate in a mobile
+   app means you cannot rotate the certificate without an app update. Pin the intermediate
+   CA public key instead, or include backup pins. Never deploy pinning without a tested
+   rotation procedure and a documented emergency unpinning process.
+
+5. **Ignoring Certificate Transparency.** If you are not monitoring CT logs for your
+   domains, you will not know if a rogue CA or compromised intermediate issues a
+   certificate for your domain until users are phished or traffic is intercepted. CT
+   monitoring is free and takes minutes to set up.

package/dist/agents/skills/gemini-cli/security-certificate-management/skill.yaml

@@ -0,0 +1,42 @@
+name: security-certificate-management
+version: '1.0.0'
+description: CA hierarchy, certificate pinning, Certificate Transparency, ACME/Let's Encrypt, and the lifecycle of X.509 certificates from issuance to revocation
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-tls-fundamentals
+  - security-hsts-preloading
+  - security-mtls-design
+  - security-asymmetric-encryption
+  - owasp-cryptography
+stack_signals: []
+keywords:
+  - certificate
+  - CA
+  - certificate authority
+  - X.509
+  - certificate transparency
+  - CT logs
+  - ACME
+  - Let's Encrypt
+  - certificate pinning
+  - certificate revocation
+  - CRL
+  - OCSP
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/security-ci-security-testing/SKILL.md

@@ -0,0 +1,159 @@
+# CI Security Testing
+
+> Run SAST, DAST, SCA, and secrets scanning on every commit -- automated security gates that
+> catch vulnerabilities before they reach production
+
+## When to Use
+
+- Setting up a new CI/CD pipeline and need to integrate security scanning from the start
+- Adding automated security testing to an existing pipeline that currently has none
+- Evaluating SAST, DAST, and SCA tools for your technology stack
+- Reducing the time between vulnerability introduction and detection
+- Meeting compliance requirements for automated security testing (SOC2, PCI-DSS, ISO 27001)
+- Managing false positives from security scanners without disabling them entirely
+
+## Threat Context
+
+Automated security testing in CI catches vulnerabilities at the earliest possible point after
+code is written. Without CI security testing, vulnerabilities accumulate silently until a
+periodic security review or penetration test discovers them -- by which time hundreds of
+vulnerable commits have been deployed, the original developers have moved to other features,
+and the fix requires understanding code written weeks or months ago.
+
+The 2021 Codecov supply chain attack exploited a vulnerability in Codecov's Bash Uploader
+script to exfiltrate environment variables (including CI secrets) from thousands of CI/CD
+pipelines. The attack went undetected for two months because most organizations did not scan
+their CI pipeline components for tampering. Pipeline security -- securing the CI/CD system
+itself, not just the code it builds -- is as critical as the application security testing the
+pipeline performs.
+
+The 2023 CircleCI breach exposed customer secrets stored in CircleCI's environment. The 2024
+xz-utils backdoor (CVE-2024-3094) was injected through a compromised maintainer who modified
+build scripts. These incidents demonstrate that CI/CD pipelines are high-value targets: they
+have access to production credentials, signing keys, and deployment permissions.
+
+## Instructions
+
+1. **Implement Static Application Security Testing (SAST) on every pull request.** SAST
+   analyzes source code for vulnerability patterns without executing it. Tool options: CodeQL
+   (GitHub, semantic analysis, supports C/C++, Java, JavaScript, Python, Go, Ruby, C#),
+   Semgrep (pattern-based, fast, supports 30+ languages, community rules plus custom rules),
+   SonarQube (broad language support, code quality plus security). Run SAST on pull requests,
+   not just the main branch, so developers see findings before merging. Configure findings as
+   PR comments or check annotations, not just dashboard entries.
+
+2. **Implement Software Composition Analysis (SCA) for dependency vulnerabilities.** SCA
+   identifies known vulnerabilities in third-party dependencies. Tools: Dependabot (GitHub
+   native, auto-creates PRs for vulnerable dependencies), Snyk (broad ecosystem support,
+   license compliance), Trivy (container and filesystem scanning, open-source), Grype (Anchore,
+   SBOM-based vulnerability matching). Run SCA on every PR and on a daily schedule against the
+   main branch (new CVEs are published daily against existing dependencies). Block merges for
+   critical and high severity vulnerabilities with known exploits.
+
+3. **Implement secrets scanning to prevent credential leaks.** Secrets scanning detects API
+   keys, passwords, tokens, and private keys in source code. Tools: gitleaks (fast, regex-based,
+   open-source), truffleHog (entropy-based plus regex, scans git history), GitGuardian
+   (commercial, real-time monitoring, broad secret type coverage). Run secrets scanning as a
+   pre-commit hook (catches secrets before they enter git history) and in CI (catches secrets
+   that bypass the pre-commit hook). Scan the full git history periodically -- a secret committed
+   and then deleted is still in the git history and still compromised.
+
+4. **Implement Dynamic Application Security Testing (DAST) against staging environments.** DAST
+   tests the running application by sending malicious requests and observing responses. Tools:
+   OWASP ZAP (open-source, scriptable, API and web scanning), Burp Suite (commercial, more
+   comprehensive, better for complex applications), Nuclei (template-based, fast, good for
+   known vulnerability checks). Run DAST against a staging environment deployed from the PR
+   branch. Configure authenticated scanning so the scanner tests authenticated endpoints, not
+   just the login page. DAST finds runtime vulnerabilities that SAST misses: misconfigured
+   headers, exposed error pages, authentication bypasses.
+
+5. **Harden the CI/CD pipeline itself.** The pipeline has access to production secrets,
+   deployment credentials, and signing keys -- it is a high-value target. Runner isolation: use
+   ephemeral runners that are destroyed after each job (GitHub Actions hosted runners, ephemeral
+   self-hosted runners). Secret masking: ensure CI secrets are never printed in logs. Pin
+   dependencies: pin GitHub Actions and other CI plugins by SHA, not by tag (a tag can be
+   reassigned to point to a malicious commit). Least privilege: CI service accounts should have
+   the minimum permissions needed for their specific job, not admin access to the entire
+   infrastructure.
+
+6. **Establish a triage and suppression workflow for findings.** Every security scanner produces
+   false positives. Without a triage workflow, developers either ignore all findings (alert
+   fatigue) or waste time on non-issues. Implement a triage process: new findings are reviewed
+   within a defined SLA (24 hours for critical, 1 week for medium). Confirmed findings become
+   backlog items with severity-based SLAs. False positives are suppressed with a documented
+   justification (code comment, scanner configuration, or triage tool entry). Track the
+   false-positive rate per scanner and per rule to identify rules that need tuning or removal.
+
+7. **Measure and report on CI security metrics.** Track: mean time to detect (from commit to
+   finding), mean time to remediate (from finding to fix), false-positive rate by scanner and
+   rule, findings by severity and category, percentage of PRs with security findings. Report
+   these metrics monthly to engineering leadership. The goal is not zero findings -- it is a
+   decreasing trend in time-to-detect and time-to-remediate, with a manageable false-positive
+   rate that keeps developers engaged rather than fatigued.
+
+## Details
+
+- **SAST: pattern-based vs semantic analysis**: Pattern-based tools (Semgrep) match code against
+  known vulnerability patterns using AST matching or regex. They are fast, easy to write custom
+  rules for, and have low setup cost. Semantic analysis tools (CodeQL) build a queryable database
+  of the code's data flow and control flow, enabling taint tracking (tracing untrusted input
+  from source to sink). CodeQL can find vulnerabilities that require understanding data flow
+  across multiple functions and files, which pattern matching cannot. Use both: Semgrep for
+  fast, broad coverage with custom rules; CodeQL for deep taint analysis on critical code paths.
+
+- **False positive management strategies**: Accept that false positives are inherent in static
+  analysis. Strategies to manage them: configure scanner sensitivity (start strict, loosen rules
+  with high FP rates), use inline suppression annotations with mandatory justification comments,
+  create a central suppressions file reviewed in security champion meetings, track FP rates per
+  rule and disable rules with >50% FP rate after investigation, deduplicate findings across
+  scanners to avoid reviewing the same issue twice.
+
+- **Pipeline-as-code security**: If the CI configuration (GitHub Actions YAML, Jenkinsfile,
+  GitLab CI YAML) is stored in the repository, any developer with commit access can modify the
+  pipeline to skip security checks. Mitigations: use CODEOWNERS to require security team
+  approval for CI configuration changes, use reusable workflows (GitHub) or templates (GitLab)
+  that projects cannot modify, use branch protection rules that require specific checks to pass
+  before merging.
+
+- **Scanning schedule strategy**: PR-time scanning (SAST, secrets, SCA): fast feedback, catches
+  new introductions. Daily scheduled scanning (SCA against main): catches newly disclosed CVEs
+  in existing dependencies. Weekly full DAST scans: comprehensive runtime testing. Monthly
+  historical secrets scan: catches secrets committed and deleted in past history. Each cadence
+  serves a different detection objective.
+
+## Anti-Patterns
+
+1. **Alert fatigue from untuned scanners.** Deploying a scanner with default rules and no tuning
+   generates hundreds of findings, most of which are false positives or low-severity issues.
+   Developers learn to ignore the scanner. Start with a small set of high-confidence rules,
+   verify that findings are actionable, and gradually expand coverage. A scanner that produces
+   10 accurate findings is more valuable than one that produces 500 findings of which 450 are
+   false positives.
+
+2. **Security scanning as a separate pipeline stage.** Running security scans in a separate,
+   optional pipeline stage that developers can skip or ignore. Security scanning should be
+   integrated into the required CI checks -- the same checks that must pass before a PR can be
+   merged. If security scanning is optional, it will be skipped when it is inconvenient, which
+   is exactly when it is most needed.
+
+3. **Scanning only the main branch instead of pull requests.** Scanning after merge means the
+   vulnerability is already in the production codebase when it is detected. The developer who
+   introduced it may have moved to another task. Scan pull requests so that findings appear in
+   the context of the change that introduced them, when the developer can fix them immediately.
+
+4. **No triage process for findings.** Scanner output dumped into a dashboard that nobody
+   reviews. Findings accumulate, the dashboard becomes a graveyard of unresolved issues, and
+   the scanner provides no security value. Every finding must have an owner, a severity-based
+   SLA, and a tracked resolution (fixed, suppressed with justification, or accepted risk).
+
+5. **Treating scanner output as a compliance checkbox.** Running scanners to satisfy an audit
+   requirement without acting on the findings. The audit asks "do you run SAST?" and the answer
+   is "yes" -- but the 200 open critical findings tell a different story. Scanners provide value
+   only when their findings drive remediation. Track and report the percentage of findings
+   remediated within SLA, not just whether the scanner ran.
+
+6. **Hardcoding suppression of findings without review.** Developers adding blanket suppression
+   annotations to silence scanner warnings without understanding the finding. Require that all
+   suppressions include a justification comment and are reviewed by a security champion or the
+   security team. Periodically audit suppressed findings to verify the justification is still
+   valid.

package/dist/agents/skills/gemini-cli/security-ci-security-testing/skill.yaml

@@ -0,0 +1,43 @@
+name: security-ci-security-testing
+version: '1.0.0'
+description: SAST, DAST, SCA, and secrets scanning in CI/CD pipelines -- automated security testing that runs on every commit
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-shift-left-design
+  - security-dependency-auditing
+  - security-penetration-testing
+  - security-secrets-lifecycle
+  - owasp-injection-prevention
+  - owasp-dependency-security
+stack_signals: []
+keywords:
+  - SAST
+  - DAST
+  - SCA
+  - secrets scanning
+  - CI security
+  - pipeline security
+  - static analysis
+  - dynamic analysis
+  - CodeQL
+  - Semgrep
+  - Trivy
+  - gitleaks
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []