@harness-engineering/cli 1.24.0 → 1.24.3

package/dist/agents/skills/gemini-cli/security-vulnerability-disclosure/SKILL.md

@@ -0,0 +1,207 @@
+# Vulnerability Disclosure
+
+> A vulnerability without a disclosure process is a vulnerability that gets sold to exploit
+> brokers, dropped as a zero-day, or posted on Twitter -- coordinated disclosure turns
+> discovered vulnerabilities into patches instead of breaches
+
+## When to Use
+
+- Setting up a vulnerability disclosure program for your organization or product
+- Receiving a vulnerability report from an external researcher and deciding how to respond
+- Discovering a vulnerability in a third-party product and deciding how to report it
+- Writing a security advisory for a vulnerability in your product
+- Requesting a CVE identifier and coordinating public disclosure
+- Evaluating whether to establish a bug bounty program
+
+## Threat Context
+
+The absence of a clear disclosure process creates perverse incentives that make
+vulnerabilities more dangerous, not less:
+
+- **The 2017 Shadow Brokers leak**: NSA-developed exploits (EternalBlue, DoublePulsar) were
+  leaked publicly without coordination with Microsoft. Microsoft had patched EternalBlue
+  (MS17-010) one month before the leak -- likely after being notified by NSA -- but many
+  organizations had not applied the patch. The uncoordinated disclosure of the full exploit
+  toolkit enabled WannaCry and NotPetya, two of the most destructive cyberattacks in history,
+  causing billions of dollars in damage. Coordinated disclosure would have provided more time
+  for patching before exploit availability.
+- **Google Project Zero's 90-day policy**: Google's vulnerability research team notifies
+  vendors and gives them 90 days to release a patch. After 90 days, the vulnerability is
+  disclosed publicly regardless of patch status. This policy has been controversial but
+  effective -- it creates a hard deadline that prevents vendors from ignoring or indefinitely
+  delaying fixes. Since its inception, most major vendors have improved their patch timelines.
+- **Researchers prosecuted under CFAA**: Security researchers have faced legal threats and
+  prosecution under the Computer Fraud and Abuse Act for good-faith vulnerability research.
+  In 2022, the US Department of Justice updated its CFAA policy to state that good-faith
+  security research should not be prosecuted. Organizations that threaten researchers with
+  legal action create a chilling effect that suppresses vulnerability reports, leaving
+  vulnerabilities unfixed and users at risk.
+- **Zerodium and the exploit market**: Zerodium and similar brokers pay up to $2.5 million
+  for iOS zero-days and $1 million for Chrome zero-days. When vendors do not have disclosure
+  programs, or when they respond to reports with indifference or hostility, researchers have
+  a financial incentive to sell to exploit brokers instead of reporting to the vendor. The
+  vulnerability remains unpatched while the broker sells it to government clients.
+
+## Instructions
+
+1. **Establish a vulnerability disclosure program.** Every organization that produces software
+   should have a clear, public process for receiving vulnerability reports:
+   - **security.txt (RFC 9116)**: Place a `/.well-known/security.txt` file on your web
+     domain. At minimum, include: `Contact:` (security email or web form URL), `Expires:`
+     (date when the file should be considered stale), `Preferred-Languages:`, and optionally
+     `Encryption:` (PGP key for encrypted reports) and `Policy:` (link to full disclosure
+     policy). This standardized file allows researchers to find your reporting channel quickly.
+   - **security@ email**: Establish `security@yourdomain.com` as the standard contact point.
+     Monitor it 24/7 or within a defined SLA. Configure PGP/GPG encryption so researchers
+     can submit reports confidentially.
+   - **Disclosure policy**: Publish a clear policy that states: what is in scope (your
+     products, your infrastructure, third-party components), what is out of scope (social
+     engineering of employees, physical attacks, denial of service testing), safe harbor
+     language (you will not pursue legal action against researchers acting in good faith),
+     expected response timeline (acknowledge within 48 hours, initial assessment within 7
+     days, target fix timeline within 90 days), and recognition (how you credit researchers).
+   - **Response SLA**: Acknowledge receipt within 24-48 hours. Provide an initial severity
+     assessment within 7 business days. Provide a timeline for the fix. Communicate status
+     updates at least every 2 weeks for high-severity issues. Coordinate public disclosure
+     with the researcher.
+
+2. **Follow the coordinated disclosure process.** When you discover a vulnerability in someone
+   else's product, or when a researcher reports one to you:
+   - **Researcher reports to vendor**: The researcher contacts the vendor through the
+     designated channel with a detailed report including: description of the vulnerability,
+     affected versions, reproduction steps, proof of concept (non-destructive), and suggested
+     severity (CVSS score if possible).
+   - **Vendor acknowledges and assesses**: The vendor confirms receipt, assigns a tracking
+     number, and evaluates severity. The vendor communicates the assessment and expected fix
+     timeline to the researcher.
+   - **Vendor develops and tests the fix**: The vendor develops a patch, tests it across
+     affected versions, and prepares the advisory. The researcher may verify the fix if the
+     vendor provides a pre-release.
+   - **Coordinated public disclosure**: Vendor and researcher agree on a disclosure date. The
+     vendor releases the patch and advisory simultaneously. The researcher publishes their
+     write-up. Users can apply the patch immediately upon learning of the vulnerability.
+   - **Standard disclosure timeline**: 90 days is the de facto industry standard (per Google
+     Project Zero). Some organizations use 45 days for critical vulnerabilities or 120 days
+     for complex issues. The timeline should balance giving the vendor time to fix the issue
+     with protecting users from indefinite exposure.
+
+3. **Request and manage CVE identifiers.** CVEs (Common Vulnerabilities and Exposures) provide
+   a standardized way to identify vulnerabilities:
+   - **When to request a CVE**: For any vulnerability in a product or library used by others.
+     Internal-only systems do not need CVEs. CVEs help users track vulnerabilities across
+     vendors, tools, and advisories.
+   - **CVE Numbering Authorities (CNAs)**: If your organization is a CNA (major software
+     vendors, open-source projects, cloud providers), you can assign CVE IDs directly.
+     Otherwise, request a CVE from MITRE (cveform.mitre.org) or through a CNA that covers
+     your domain.
+   - **CVE record contents**: CVE ID, affected product and versions, vulnerability type (CWE
+     ID), description, severity (CVSS score), references (advisory URL, patch URL, write-up
+     URL), and credit to the reporter.
+   - **NVD publication**: After CVE assignment, the record is published to the National
+     Vulnerability Database (NVD), where it is enriched with CVSS scores and CPE (Common
+     Platform Enumeration) identifiers. This makes the vulnerability searchable and
+     trackable by vulnerability management tools.
+
+4. **Write effective security advisories.** The advisory is the primary communication to users
+   about the vulnerability and its fix:
+   - **Title**: Short, specific. "Remote Code Execution in Widget Parser" not "Security
+     Update."
+   - **CVE ID**: Include the assigned CVE identifier.
+   - **Severity**: CVSS v3.1 base score and vector string. Provide a qualitative rating
+     (Critical, High, Medium, Low) alongside the numeric score.
+   - **Affected versions**: Explicit version ranges. "Versions 2.0.0 through 2.4.3 are
+     affected. Version 2.4.4 contains the fix."
+   - **Description**: What the vulnerability is (buffer overflow, SQL injection, insecure
+     deserialization), what an attacker can achieve (RCE, data disclosure, DoS), and what
+     conditions are required for exploitation (authentication required, network-accessible,
+     default configuration).
+   - **Remediation**: Specific upgrade instructions. If a patch is not available, provide a
+     workaround (configuration change, WAF rule, feature disable) with a timeline for the
+     permanent fix.
+   - **Credit**: Name the researcher who reported the vulnerability (with their consent). This
+     incentivizes future reports and demonstrates good-faith participation in the security
+     community.
+   - **Timeline**: Optionally include the disclosure timeline (reported date, fix date,
+     advisory date) for transparency.
+
+5. **Consider a bug bounty program for mature organizations.** Bug bounties incentivize
+   external security research with financial rewards:
+   - **Prerequisites**: Before launching a bug bounty, ensure you have: a functioning
+     vulnerability disclosure program, the ability to receive, triage, and fix reports within
+     the SLA, and engineering capacity to handle the volume of reports.
+   - **Scope**: Define what is in scope (production systems, staging environments, specific
+     applications) and what is out of scope (denial of service, social engineering, third-
+     party services you do not control).
+   - **Reward structure**: Base rewards on severity (CVSS score) and impact. Critical RCE:
+     $5,000-$50,000+. High: $1,000-$10,000. Medium: $500-$2,000. Low: $100-$500. These
+     ranges vary dramatically by organization and industry.
+   - **Platforms**: HackerOne, Bugcrowd, and Intigriti provide managed bug bounty platforms
+     with triage support, researcher vetting, and legal frameworks. These reduce operational
+     overhead compared to running a program independently.
+
+## Details
+
+- **The economics of disclosure**: A researcher who discovers a zero-day has several options:
+  report to the vendor (free or bug bounty reward), sell to an exploit broker ($10,000 to
+  $2,500,000 depending on the target), use it for penetration testing engagements, or publish
+  it for reputation. The vendor's response determines which option is most attractive. A
+  vendor with no disclosure program, no acknowledgment, and no bounty makes the broker option
+  more attractive. A vendor with a responsive program, fair bounties, and public credit makes
+  responsible disclosure the rational choice.
+
+- **PSIRT (Product Security Incident Response Team) operations**: Large organizations
+  establish a PSIRT to manage the vulnerability lifecycle: receive reports, triage, coordinate
+  with engineering for fixes, manage CVE assignment, write advisories, coordinate disclosure
+  timing, and track metrics (time to acknowledgment, time to fix, time to advisory). The
+  PSIRT is the organization's interface with the external security research community.
+  ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling
+  Processes) provide frameworks for PSIRT operations.
+
+- **Legal landscape for security research**: The Computer Fraud and Abuse Act (CFAA) in the
+  US, the Computer Misuse Act in the UK, and similar laws in other jurisdictions can
+  criminalize unauthorized access, even when performed with good intentions. Safe harbor
+  language in disclosure policies provides a commitment not to pursue legal action. The DOJ's
+  2022 CFAA policy update states that good-faith security research should not be charged, but
+  this is prosecutorial guidance, not law. The EU's proposed Cyber Resilience Act includes
+  provisions for coordinated vulnerability disclosure. Organizations should consult legal
+  counsel when drafting disclosure policies and safe harbor language.
+
+- **Disclosure timeline negotiation**: The 90-day standard is not rigid. If the vendor
+  demonstrates active progress (regular status updates, a confirmed fix date within a
+  reasonable window), researchers typically grant extensions. If the vendor is unresponsive
+  or denies the vulnerability, researchers may shorten the timeline. If the vulnerability is
+  being actively exploited in the wild (a zero-day), immediate disclosure may be warranted
+  because users need to know to apply mitigations even before a patch exists. The goal is
+  always to minimize the total exposure of users.
+
+## Anti-Patterns
+
+1. **No disclosure policy.** Researchers find a vulnerability but have no way to report it.
+   There is no security.txt, no security@ email, and no contact information in the product's
+   documentation. The researcher has three options: give up, disclose publicly (creating a
+   zero-day), or sell to a broker. None of these options result in a coordinated patch.
+   Publish a security.txt and a disclosure policy.
+
+2. **Threatening legal action against researchers.** A researcher reports a vulnerability and
+   the organization's legal department sends a cease-and-desist or threatens prosecution.
+   This chills future reports -- other researchers see the threat and decide not to report.
+   The vulnerability remains unfixed, but now the organization has also damaged its reputation
+   in the security community. Include safe harbor language in the disclosure policy and honor
+   it.
+
+3. **Disclosing without a patch available.** Publishing a vulnerability advisory before a fix
+   exists, giving attackers a roadmap without giving users a defense. Coordinate disclosure
+   timing so that the patch and the advisory are released simultaneously. If a workaround
+   exists, publish the workaround immediately and the full details after the patch.
+
+4. **Ignoring vulnerability reports.** A researcher reports a critical vulnerability and
+   receives no response for weeks or months. The researcher follows up, still no response.
+   Eventually the researcher discloses publicly out of obligation to affected users. The
+   organization is caught unprepared with no patch. Acknowledge reports within 48 hours even
+   if the full assessment takes longer.
+
+5. **No CVE assignment.** Fixing a vulnerability silently without assigning a CVE or
+   publishing an advisory. Users who track vulnerabilities through CVEs and vulnerability
+   databases do not know the fix exists and do not prioritize the update. Silent fixes
+   leave users exposed because they do not know they need to update. Assign CVEs for all
+   vulnerabilities in products used by others and publish advisories.

package/dist/agents/skills/gemini-cli/security-vulnerability-disclosure/skill.yaml

@@ -0,0 +1,39 @@
+name: security-vulnerability-disclosure
+version: '1.0.0'
+description: Responsible disclosure, CVE process, coordinated vulnerability disclosure, and managing the lifecycle from discovery to public advisory
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-incident-containment
+  - security-post-incident-review
+  - security-penetration-testing
+  - owasp-logging-monitoring
+stack_signals: []
+keywords:
+  - vulnerability disclosure
+  - responsible disclosure
+  - coordinated disclosure
+  - CVE
+  - security advisory
+  - bug bounty
+  - PSIRT
+  - security.txt
+  - disclosure policy
+  - vendor notification
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

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

@@ -0,0 +1,229 @@
+# Zero Trust Principles
+
+> No implicit trust based on network position, VPN status, or previous authentication -- every request is authenticated, authorized, and encrypted regardless of origin
+
+## When to Use
+
+- Designing a new system architecture and need to establish the security model
+- Migrating from a perimeter-based security model to a modern architecture
+- Planning service-to-service authentication in a microservices environment
+- Evaluating whether internal APIs need authentication and encryption
+- Responding to a breach and hardening the architecture against lateral movement
+- Implementing security for remote and hybrid workforce access
+
+## Threat Context
+
+Perimeter-based security -- the "hard shell, soft interior" model where a firewall or VPN guards the boundary and everything inside the network is trusted -- fails because attackers who breach the perimeter have unrestricted lateral movement across all internal resources.
+The assumption that "inside the network equals trustworthy" has been catastrophically disproven by every major breach of the last decade.
+
+The 2020 SolarWinds supply chain attack demonstrated this at nation-state scale.
+Once the compromised Orion update was deployed inside government agencies and Fortune 500 companies, the attackers (attributed to Russia's SVR) moved laterally through "trusted" internal networks for nine months, accessing email systems, source code repositories, and classified infrastructure.
+Internal services trusted other internal services implicitly; there was no authentication or authorization between components within the perimeter.
+
+The 2023 Microsoft Storm-0558 breach exploited implicit trust in internal token-signing infrastructure.
+Attackers obtained a Microsoft account consumer signing key and used it to forge enterprise Azure AD tokens, accessing email accounts of US government officials.
+The signing key was trusted implicitly across services -- there was no per-request verification of whether the key should be authorized to sign tokens for that specific audience.
+
+The 2021 Colonial Pipeline ransomware attack began with a compromised VPN credential -- a single password without multi-factor authentication.
+Once inside the VPN, the attackers had broad network access because the internal network did not segment or authenticate traffic between systems.
+
+Zero trust assumes the network is always hostile and every component may already be compromised.
+This is not paranoia; it is the empirically validated reality of modern threat environments.
+
+## Instructions
+
+1. **Never trust, always verify.**
+   Every request to every resource must be authenticated and authorized, regardless of its network origin.
+   An API call from inside the corporate network, from a Kubernetes pod in the same cluster, or from a service on the same physical host receives the same authentication and authorization scrutiny as a request from the public internet.
+
+   There is no "trusted zone," no "internal network exception," and no "localhost bypass."
+   Every request is unverified until proven otherwise.
+
+2. **Apply least privilege everywhere and continuously.**
+   Users, services, infrastructure components, and automated processes receive the minimum permissions required for their current task -- not their potential tasks, not their historical tasks, and not "everything they might need someday."
+
+   Permissions are scoped to specific resources and time-limited where possible:
+   - A CI/CD pipeline token that deploys to staging should not have production credentials
+   - A microservice that reads from a database should not have write access
+   - A developer who manages application code should not have access to production secrets
+
+   Review and reduce permissions continuously; access that was appropriate six months ago may not be appropriate today.
+
+3. **Assume breach as the baseline design posture.**
+   Design every component under the assumption that adjacent components may already be compromised.
+   This architectural assumption drives concrete design decisions:
+   - Mutual authentication between all services (mTLS)
+   - Encrypted communication even on internal networks (TLS everywhere)
+   - Network segmentation that limits blast radius (a compromised web server cannot reach the database server directly)
+   - Monitoring that detects lateral movement (anomalous service-to-service communication patterns)
+
+   If Service A is compromised, it should not be able to access Service B's data, Service C's configuration, or Service D's secrets without individually authenticating and being individually authorized for each.
+
+4. **Verify explicitly and continuously.**
+   Authentication is not a one-time event at session start.
+   Continuously evaluate the trust factors that supported the original access decision:
+   - Is the user's session still valid?
+   - Has the device's security posture changed (OS patch level, disk encryption status, endpoint detection agent running)?
+   - Has the user's risk profile changed (impossible travel between login locations, unusual access patterns, access outside normal hours)?
+   - Has the network context changed (different IP range, different geographic region)?
+
+   When risk indicators change, require step-up authentication.
+   Implement continuous access evaluation as a background process, not just at login time.
+
+5. **Use identity as the new perimeter.**
+   Replace network-based access controls (VPN, firewall rules based on IP ranges, network ACLs) with identity-based controls.
+   Access decisions use a rich context of signals:
+   - User identity: who is requesting?
+   - Device identity and health: is the device managed, patched, and compliant?
+   - Application identity: which service is making the request?
+   - Data classification: how sensitive is the requested resource?
+   - Real-time risk signals: behavioral analytics, threat intelligence
+
+   Google's BeyondCorp model is the canonical implementation: employees access internal applications through an identity-aware proxy that evaluates all these signals on every request, with no VPN required.
+   Network location is not a factor in the access decision.
+
+6. **Encrypt all communications without exception.**
+   TLS for all HTTP traffic, including between services on the same internal network.
+   mTLS (mutual TLS) for service-to-service communication, where both the client and server present certificates and verify each other's identity.
+   Encryption at rest for all stored data.
+
+   Even "internal" network traffic may be observed by:
+   - Compromised hosts on the same network segment
+   - Compromised network switches or routers
+   - Cloud provider infrastructure (where "your" network is a virtual overlay on shared physical hardware)
+   - Legitimate monitoring tools that are misconfigured or compromised
+
+7. **Log everything and use the logs.**
+   Zero trust architecture generates an audit trail at every access decision point.
+   Centralize these logs in a SIEM (Security Information and Event Management) system.
+   Apply anomaly detection to identify patterns that indicate compromise:
+   - A service suddenly calling APIs it has never called before
+   - A user accessing resources outside their normal pattern
+   - Authentication failures from new geographic locations
+   - Privilege escalation attempts
+
+   Alert on policy violations in real time.
+   If you cannot observe and verify what is happening, you cannot enforce zero trust -- you are just hoping the policies work.
+
+## Details
+
+### The BeyondCorp Model (Google)
+
+Google's internal zero trust implementation has been operational since 2014, replacing the traditional VPN-based access model for over 100,000 employees.
+
+Key components:
+
+1. **Device inventory database**: Every device that accesses Google resources has a certificate-based identity issued during provisioning. The device's hardware characteristics, OS version, patch level, disk encryption status, and endpoint security agent status are continuously monitored.
+
+2. **User identity database**: Single sign-on with hardware security key MFA (FIDO2/WebAuthn). User identity is verified on every request, not just at VPN login. Risk-based authentication adjusts requirements based on the sensitivity of the requested resource.
+
+3. **Access proxy**: All requests to internal applications route through an identity-aware proxy. The proxy enforces per-request authorization based on user identity, device identity, device posture, and resource sensitivity. No direct network access to applications is possible.
+
+4. **Trust tiers**: Devices and users are classified into trust levels based on posture, role, and behavioral signals. A fully managed device with current patches and a hardware security key gets Tier 1 access. A personal device with only a password gets Tier 3 access with restricted resource availability.
+
+5. **No VPN**: Access decisions are made per-request based on identity and context, not based on network position. An employee at a coffee shop has the same access as an employee in a Google office, provided their identity and device meet the required trust tier.
+
+### NIST SP 800-207: Zero Trust Architecture
+
+The NIST reference standard (published 2020) defines the core tenets:
+
+- All data sources and computing services are considered resources
+- All communication is secured regardless of network location
+- Access to individual resources is granted on a per-session basis
+- Access is determined by dynamic policy -- including user identity, application/service identity, device state, and behavioral and environmental attributes
+- The enterprise monitors and measures the security posture of all owned and associated assets
+- All resource authentication and authorization are dynamic and strictly enforced before access is allowed
+- The enterprise collects information about asset state, network infrastructure, and communications and uses it to improve security posture
+
+### Practical Implementation Layers
+
+Zero trust is not an all-or-nothing proposition.
+Implement incrementally, starting with the highest-value controls:
+
+**Layer 1 -- Quick wins (weeks):**
+
+- Enforce TLS on all internal communication
+- Add authentication to all internal APIs (even "internal-only" ones)
+- Implement service-to-service mTLS using a service mesh or certificate infrastructure
+- Enable audit logging on all access decisions
+
+These changes have the highest security impact relative to effort.
+
+**Layer 2 -- Identity-centric controls (months):**
+
+- Deploy an identity-aware proxy or API gateway that enforces per-request authorization
+- Implement device trust verification (managed device certificates, posture checks)
+- Add continuous authentication that re-evaluates sessions based on risk signals
+- Implement just-in-time access provisioning for privileged operations
+
+**Layer 3 -- Advanced capabilities (quarters):**
+
+- Real-time risk scoring that adjusts access decisions dynamically
+- Policy engine that evaluates environmental attributes (time, location, behavioral patterns)
+- Microsegmentation at the application level (not just the network level)
+- Automated response to anomalous access patterns (session termination, forced re-authentication, alert escalation)
+
+### Zero Trust in Kubernetes and Microservices
+
+In a containerized microservices environment, zero trust translates to specific architectural patterns:
+
+- **Service identity**: Every pod has a cryptographic identity, typically provided by SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment). The identity is bound to the workload, not the network address.
+
+- **Service mesh for mTLS**: A service mesh (Istio, Linkerd, Cilium) transparently enforces mTLS between all pods. Application code does not need to manage TLS certificates -- the mesh sidecar proxy handles encryption and identity verification.
+
+- **Network policies**: Kubernetes NetworkPolicy resources restrict pod-to-pod communication to explicit allow lists. Default deny all ingress and egress traffic; selectively allow only the communication paths that are architecturally required.
+
+- **API gateway authorization**: An API gateway (or ingress controller with authorization plugins) enforces user-level authorization on every inbound request. The gateway validates the user's identity token, checks permissions, and only forwards authorized requests to backend services.
+
+- **Secrets management**: Secrets (database credentials, API keys, TLS certificates) are injected at runtime from a secrets manager (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets with external secrets operator), not baked into container images or deployment manifests.
+
+### Zero Trust for Developer Workflows
+
+Zero trust applies to the software development lifecycle as well:
+
+- **Source code access**: Repository access requires per-repository authorization, not blanket organization membership. Read access and write access are distinct permissions.
+- **CI/CD pipelines**: Pipeline credentials are scoped to the specific environment and resources the pipeline deploys to. Production deployment requires separate approval and uses distinct, short-lived credentials.
+- **Infrastructure access**: SSH to production servers requires just-in-time access provisioning with MFA, time-limited sessions, and full command audit logging. Persistent SSH keys are a zero trust violation.
+- **Secrets in development**: Developers use personal credentials for development environments, not shared production secrets. Production secrets are accessible only through the deployment pipeline.
+
+## Anti-Patterns
+
+1. **"We have a VPN, so internal traffic is safe."**
+   A VPN moves the perimeter boundary to the VPN server but does nothing to secure communication between internal hosts.
+   Any compromised host on the VPN -- whether from malware, a phished employee, or a compromised contractor device -- has the same network access as a legitimate host.
+   VPN is a transport mechanism for remote access, not a security architecture.
+   The Colonial Pipeline attack began with a single compromised VPN password.
+
+2. **Zero trust in name only: mTLS without authorization.**
+   Encrypting and authenticating internal traffic is necessary but not sufficient.
+   If Service A can call any endpoint on Service B with a valid mTLS certificate, lateral movement is still trivial -- the attacker just needs to compromise any service with a valid certificate.
+   Per-endpoint, per-operation authorization is required.
+   Authentication answers "who is calling?" Authorization answers "are they allowed to do this specific thing?"
+
+3. **One-time authentication treated as continuous trust.**
+   Authenticating a user at login and trusting the session for 8-24 hours without re-evaluation.
+   During those hours, the device could be compromised by malware, the user's credentials could be phished and used from another device, or the user's role could change (terminated employee).
+   Implement step-up authentication for sensitive operations, continuous device posture evaluation, and session risk scoring.
+
+4. **Treating zero trust as a product purchase.**
+   No single vendor provides "zero trust in a box."
+   Zero trust is an architectural model and a set of design principles, not a product.
+   It requires coordinated changes to identity management, network architecture, application design, data classification, monitoring, and incident response.
+   Vendor products implement components of a zero trust architecture, but purchasing them without the architectural changes provides security theater, not security.
+
+5. **All-or-nothing implementation.**
+   Attempting to implement zero trust across the entire organization simultaneously leads to either analysis paralysis (nothing gets done) or rushed deployment (controls are misconfigured and bypassed).
+   Start with the highest-value assets: production databases, customer data stores, administrative interfaces, and secrets management infrastructure.
+   Implement zero trust for those first, validate, measure operational impact, then expand.
+   Google's BeyondCorp was rolled out incrementally over six years.
+
+6. **Exempting service accounts from zero trust policies.**
+   Service accounts, machine identities, and API keys are frequently exempted from MFA, session timeouts, and authorization checks because "they are not users."
+   Service accounts are the most common vector for lateral movement because they typically have broad permissions, long-lived credentials, and no behavioral monitoring.
+   Apply the same principles: least privilege, short-lived credentials, mutual authentication, and continuous monitoring.
+
+7. **Confusing network segmentation with zero trust.**
+   Network segmentation (VLANs, firewall rules between subnets) reduces blast radius but does not provide zero trust.
+   Within each segment, hosts still trust each other implicitly.
+   Zero trust requires authentication and authorization at the application layer, between individual services, regardless of network topology.
+   Segmentation is a complementary control, not a substitute.

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

@@ -0,0 +1,40 @@
+name: security-zero-trust-principles
+version: "1.0.0"
+description: Zero trust architecture principles -- never trust, always verify, least privilege, assume breach, and continuous verification regardless of network position
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-trust-boundaries
+  - security-microsegmentation
+  - security-identity-verification
+  - security-rbac-design
+  - security-tls-fundamentals
+  - security-mtls-design
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - zero trust
+  - never trust always verify
+  - least privilege
+  - assume breach
+  - continuous verification
+  - BeyondCorp
+  - network segmentation
+  - identity-based security
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/state-context-pattern/skill.yaml

@@ -1,6 +1,7 @@
 name: state-context-pattern
 version: '1.0.0'
 description: Manage shared state with React Context and useReducer for prop-drilling avoidance
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-jotai-atoms/skill.yaml

@@ -1,6 +1,7 @@
 name: state-jotai-atoms
 version: '1.0.0'
 description: Build bottom-up atomic state with Jotai atoms for granular React state management
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-selection-patterns/skill.yaml

@@ -1,6 +1,7 @@
 name: state-selection-patterns
 version: '1.0.0'
 description: Select and derive state efficiently across stores to minimize component re-renders
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-server-client-sync/skill.yaml

@@ -1,6 +1,7 @@
 name: state-server-client-sync
 version: '1.0.0'
 description: Synchronize server state with client state using React Query patterns and cache coordination
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-devtools/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-devtools
 version: '1.0.0'
 description: Debug Zustand stores with Redux DevTools integration via the devtools middleware
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-immer/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-immer
 version: '1.0.0'
 description: Write mutable-style updates in Zustand stores with the Immer middleware
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-persist/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-persist
 version: '1.0.0'
 description: Persist Zustand store to localStorage or custom storage with the persist middleware
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-react/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-react
 version: '1.0.0'
 description: Optimize Zustand re-renders with selectors, shallow comparison, and subscription patterns
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-slices/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-slices
 version: '1.0.0'
 description: Split large Zustand stores into composable slices for modular state
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/state-zustand-store/skill.yaml

@@ -1,6 +1,7 @@
 name: state-zustand-store
 version: '1.0.0'
 description: Create lightweight global stores with Zustand's create function
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/svelte-adapter-config/skill.yaml

@@ -1,6 +1,7 @@
 name: svelte-adapter-config
 version: '1.0.0'
 description: Configure SvelteKit deployment adapters for Node, Vercel, Cloudflare, and static hosting
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/svelte-component-composition/skill.yaml

@@ -1,6 +1,7 @@
 name: svelte-component-composition
 version: '1.0.0'
 description: Compose Svelte 5 components with snippets, {@render}, children, and named content slots
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/svelte-error-pages/skill.yaml

@@ -1,6 +1,7 @@
 name: svelte-error-pages
 version: '1.0.0'
 description: Handle expected and unexpected errors in SvelteKit using +error.svelte, error(), and handleError hooks
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/gemini-cli/svelte-form-actions/skill.yaml

@@ -1,6 +1,7 @@
 name: svelte-form-actions
 version: '1.0.0'
 description: Handle form submissions with SvelteKit actions, use:enhance, fail(), redirect(), and progressive enhancement
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3