@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/codex/security-identity-verification/SKILL.md

@@ -0,0 +1,157 @@
+# Continuous Identity Verification
+
+> Authentication at login is necessary but insufficient -- continuously evaluate identity
+> confidence using device trust, behavioral signals, and environmental context throughout
+> the session
+
+## When to Use
+
+- Implementing zero trust architecture that requires continuous verification
+- Designing device trust policies (MDM enrollment, OS version, encryption status)
+- Building risk-adaptive authentication that adjusts challenge level based on context
+- Replacing VPN-based network access with identity-aware access proxies
+- Evaluating Google BeyondCorp or similar zero trust access models
+- Adding session risk scoring to detect account takeover mid-session
+
+## Threat Context
+
+Traditional authentication verifies identity once at login and trusts the session for its
+entire lifetime. Session hijacking (stolen cookies, XSS-extracted tokens), credential
+compromise discovered mid-session, and device compromise after login all exploit this
+one-time-check model. Google's BeyondCorp (deployed internally after the 2009 Operation
+Aurora attack by Chinese state hackers) eliminated the trusted network perimeter and
+replaced it with continuous per-request identity and device verification. The 2022 Uber
+breach demonstrated that initial authentication (even with MFA) is insufficient when
+session tokens are subsequently stolen via social engineering -- the attacker MFA-bombed
+an employee, obtained a session token, and accessed internal systems for hours before
+detection. The 2023 MGM Resorts breach used social engineering to bypass MFA and then
+operated freely within sessions that were never re-evaluated.
+
+## Instructions
+
+1. **Evaluate device trust posture before granting access.** Collect device signals: OS
+   version (is it patched?), disk encryption status, screen lock enabled, MDM enrollment
+   status, firewall enabled, antivirus status. Define a minimum device posture profile for
+   each access level: accessing public docs requires basic posture; accessing production
+   systems requires fully managed, encrypted devices with current patches. Reject or
+   downgrade access for devices that do not meet the required posture.
+
+2. **Implement risk-based session scoring.** Assign a risk score to each session based on
+   signals: IP geolocation change, impossible travel (login from New York and London within
+   30 minutes), new device, new browser, unusual time of day, high-velocity actions (100
+   API calls per minute from a normally low-volume user). When the risk score exceeds a
+   threshold, trigger step-up authentication (re-enter password, MFA challenge) or
+   terminate the session. Score continuously, not just at login.
+
+3. **Use identity-aware access proxies.** Replace VPN with a reverse proxy that evaluates
+   identity, device posture, and access policy on every request. Google BeyondCorp,
+   Cloudflare Access, Zscaler Private Access, and Palo Alto Prisma Access implement this
+   model. The proxy intercepts every request, validates the user's identity (via session
+   token), checks device posture (via client certificate or agent attestation), and
+   evaluates the access policy before forwarding the request to the backend. No request
+   reaches the backend without passing all checks.
+
+4. **Implement device attestation.** Use client certificates (issued by your CA, bound to
+   the device's TPM) or device attestation protocols (Apple DeviceCheck, Android
+   SafetyNet/Play Integrity, Windows Device Health Attestation) to cryptographically
+   verify that the device meets your posture requirements. Self-reported device attributes
+   are insufficient -- they can be spoofed by malware or a rooted device.
+
+5. **Define access tiers by sensitivity.** Not all resources need the same level of
+   identity assurance. Tier 1 (public docs): authenticated user, any device. Tier 2
+   (internal tools): authenticated user, managed device, current patches. Tier 3
+   (production access, financial data): authenticated user, managed device, MFA within
+   last hour, device attestation, trusted network or VPN. Document these tiers and enforce
+   them consistently across all access paths.
+
+6. **Handle degradation gracefully.** When device posture degrades mid-session (e.g., MDM
+   detects the device is rooted or a required certificate expires), the system should
+   reduce access level, not crash. Downgrade from Tier 3 to Tier 1 and notify the user
+   that additional verification is needed to regain full access. Never fail open -- if
+   posture cannot be determined, default to the lowest access tier.
+
+## Details
+
+### Google BeyondCorp Architecture
+
+BeyondCorp has four components: device inventory (tracks all devices and their trust
+level), access control engine (evaluates policies per request), access proxy (intercepts
+all traffic), and single sign-on (authenticates users). Request flow: user sends request
+to access proxy, proxy checks SSO for authentication, proxy queries device inventory for
+device trust level, proxy evaluates access policy (user identity + device trust +
+resource sensitivity), proxy forwards or denies the request. No VPN, no trusted network,
+every request is individually authorized. Google published the BeyondCorp papers in
+2014-2016, and the model has become the foundation of modern zero trust architecture.
+
+### Risk Signals Taxonomy
+
+| Signal Category    | Signals                                                        | Risk Weight |
+| ------------------ | -------------------------------------------------------------- | ----------- |
+| Authentication age | Time since last MFA, token age                                 | High        |
+| Location           | IP geolocation change, impossible travel, VPN/Tor exit node    | High        |
+| Device             | New device, OS change, missing MDM, disabled encryption        | Medium-High |
+| Behavioral         | Unusual API calls, unusual data volume, off-hours access       | Medium      |
+| Session            | Concurrent sessions from different locations, rapid IP changes | Medium      |
+
+Combine signals into a composite risk score. Weight them based on your threat model.
+A geolocation change alone might not warrant a challenge, but a geolocation change
+combined with a new device and off-hours access should trigger immediate step-up
+authentication.
+
+### FIDO2/WebAuthn for Continuous Authentication
+
+WebAuthn can be used not just at login but for continuous re-authentication. Silent
+authentication using a platform authenticator (Touch ID, Windows Hello, Android
+biometric) provides a low-friction re-verification that confirms the user is still
+physically present. This is stronger than session timeout-based re-authentication because
+it proves physical presence, not just session liveness. Use silent WebAuthn challenges
+before high-sensitivity operations (financial transactions, admin changes, data exports).
+
+### Session Risk Scoring Implementation
+
+A practical session risk scoring system assigns numeric weights to each signal and
+maintains a running composite score per session. Example: new device (+30), impossible
+travel (+50), failed MFA attempt (+20), unusual time of day (+10), high API velocity
+(+15), known Tor exit node IP (+40). Thresholds: below 25 is normal (no action), 25-50
+triggers enhanced logging, 50-75 triggers step-up authentication, above 75 terminates
+the session. Store the score in the session metadata and update it on every request.
+Decay scores over time (reduce by 5 points per hour of normal activity) to avoid
+permanent lockout from a single anomalous event.
+
+### Identity Proxy Comparison
+
+| Solution          | Type        | Device Posture   | Best For                                    |
+| ----------------- | ----------- | ---------------- | ------------------------------------------- |
+| Cloudflare Access | Cloud proxy | Limited          | Simple setup, cloud-only                    |
+| Teleport          | Open source | Strong (mTLS)    | SSH, Kubernetes, database access            |
+| Boundary          | HashiCorp   | Via integrations | Session-based access, credential brokering  |
+| Pomerium          | Open source | mTLS-based       | Identity-aware proxy, self-hosted           |
+| Zscaler ZPA       | Commercial  | Full MDM         | Enterprise, complex compliance requirements |
+
+## Anti-Patterns
+
+1. **Authenticate once, trust forever.** A session that is valid for 30 days without
+   re-verification gives an attacker 30 days to exploit a stolen session token. Implement
+   session risk scoring and periodic re-authentication, especially for sensitive
+   operations. Long session lifetimes are a gift to attackers.
+
+2. **Self-reported device posture.** Trusting the client to report its own OS version,
+   encryption status, or MDM enrollment without cryptographic attestation. An attacker can
+   spoof any self-reported attribute. Require device attestation via TPM-bound certificates
+   or platform attestation APIs.
+
+3. **VPN as the zero trust solution.** VPN authenticates at connection time and then
+   grants broad network access to the internal network. This is perimeter security, not
+   zero trust. A compromised device with a VPN connection has the same access as a trusted
+   device. Replace VPN with identity-aware proxies that evaluate policy per-request.
+
+4. **Binary access decisions.** Either full access or no access, with no intermediate
+   states. This forces administrators to over-provision access to avoid blocking
+   legitimate users. Implement tiered access that degrades gracefully based on trust
+   level: high trust equals full access, medium trust equals read-only, low trust equals
+   blocked.
+
+5. **No visibility into device fleet.** If you do not know how many devices access your
+   systems, their OS versions, or their security posture, you cannot enforce device trust
+   policies. Implement device inventory and posture collection as a prerequisite to
+   continuous verification. You cannot protect what you cannot see.

package/dist/agents/skills/codex/security-identity-verification/skill.yaml

@@ -0,0 +1,39 @@
+name: security-identity-verification
+version: '1.0.0'
+description: Continuous authentication and device trust -- verifying identity beyond the initial login using behavioral signals, device posture, and risk-adaptive challenges
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-zero-trust-principles
+  - security-microsegmentation
+  - security-mfa-design
+  - security-session-management
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - continuous authentication
+  - device trust
+  - device posture
+  - risk-based authentication
+  - adaptive authentication
+  - BeyondCorp
+  - zero trust identity
+  - device attestation
+  - session risk scoring
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-incident-containment/SKILL.md

@@ -0,0 +1,190 @@
+# Incident Containment
+
+> The first 60 minutes of a security incident determine whether the organization loses days
+> of data or months of data -- containment is not about fixing the vulnerability, it is about
+> stopping the bleeding while preserving the evidence needed to understand what happened
+
+## When to Use
+
+- A security incident has been detected or suspected and immediate response is needed
+- Building or reviewing an incident response plan before an incident occurs
+- Defining severity classification and escalation procedures for security events
+- Establishing evidence preservation procedures for compromised systems
+- Designing network isolation and credential rotation runbooks
+- Preparing communication plans for breach notification (GDPR 72-hour requirement)
+
+## Threat Context
+
+The cost of a security incident scales directly with containment time. IBM's Cost of a Data
+Breach Report consistently shows that organizations that contain breaches within 30 days
+save over $1 million compared to those that take longer:
+
+- **SolarWinds (2020)**: The SUNBURST backdoor was present in SolarWinds Orion updates from
+  March to June 2020. It was not detected until December 2020 -- a 9-month dwell time.
+  During that period, the attacker (attributed to Russian SVR) accessed email systems at
+  multiple US government agencies and private companies. The extended dwell time was possible
+  because the initial compromise mimicked legitimate software behavior and the attack blended
+  with normal network traffic.
+- **Target (2013)**: Attackers compromised Target's network through an HVAC vendor. Despite
+  security tools generating alerts, the team did not act on them. The attackers had 2 weeks
+  of uncontained access to install malware on point-of-sale systems, exfiltrating 40 million
+  credit card numbers and 70 million customer records. The breach cost Target $292 million.
+- **Marriott (2018)**: The breach of Starwood's reservation system began in 2014 and was not
+  detected until 2018 -- a 4-year dwell time. The system was compromised before Marriott
+  acquired Starwood, and the lack of security assessment during the acquisition allowed the
+  breach to continue. 500 million guest records were exposed.
+- **NotPetya (2017)**: A destructive wiper disguised as ransomware spread through a Ukrainian
+  accounting software update mechanism. Organizations without network segmentation lost their
+  entire Windows infrastructure within hours. Maersk lost 49,000 laptops, 4,000 servers, and
+  all domain controllers. Rapid containment through network isolation was the only defense
+  once the wiper was active.
+
+## Instructions
+
+1. **Follow the NIST SP 800-61 incident response lifecycle.** The four phases are
+   Preparation, Detection and Analysis, Containment Eradication and Recovery, and
+   Post-Incident Activity. Each phase has specific objectives:
+   - **Preparation**: Before an incident occurs -- build the team, define roles, establish
+     communication channels, prepare tools and runbooks, conduct tabletop exercises. An
+     organization that has not prepared will improvise under pressure, making critical mistakes.
+   - **Detection and Analysis**: Confirm the incident is real (not a false positive), assess
+     the scope and severity, begin documentation. Every observation and decision from this
+     point forward must be recorded with timestamps.
+   - **Containment, Eradication, and Recovery**: Stop the attacker's access, remove their
+     presence from the environment, restore systems to a known-good state. These three
+     sub-phases often overlap.
+   - **Post-Incident Activity**: Conduct a post-incident review, update defenses, improve
+     detection capabilities. This phase is covered in the security-post-incident-review skill.
+
+2. **Execute the first 60 minutes with discipline.** The initial response period is the most
+   critical and the most prone to mistakes:
+   - **Minute 0-5: Confirm and classify.** Is this a real incident or a false positive?
+     Classify severity: P1 (active data exfiltration or destructive attack in progress), P2
+     (confirmed compromise with attacker presence but no active exfiltration detected), P3
+     (vulnerability identified that could lead to compromise), P4 (suspicious activity that
+     requires investigation).
+   - **Minute 5-15: Activate the response team.** Notify the incident commander, technical
+     lead, communications lead, and legal counsel. Use a pre-established communication channel
+     (dedicated Slack channel, bridge call, war room). Do not use the potentially compromised
+     corporate email system for sensitive incident details.
+   - **Minute 15-30: Begin evidence preservation.** Before taking any containment action that
+     modifies system state, capture volatile evidence: memory dumps, network connection state,
+     running process lists, and active session data. Once containment actions begin, this
+     evidence is altered or destroyed.
+   - **Minute 30-60: Execute initial containment.** Based on the incident type, execute the
+     appropriate containment strategy. Document every action taken and its timestamp.
+
+3. **Apply the correct containment strategy for the incident type.** Different incidents
+   require different containment approaches:
+   - **Compromised user account**: Disable the account, revoke all active sessions, rotate
+     the password and any API keys or tokens the user had access to. Review the account's
+     recent activity for data access, privilege changes, or lateral movement.
+   - **Compromised server/instance**: Isolate the system from the network (change security
+     group rules to deny all traffic except from the forensics workstation). Do not shut it
+     down -- memory forensics requires the system to remain running. Capture a memory dump
+     and disk image from the isolated system.
+   - **Active data exfiltration**: Block the exfiltration destination at the network perimeter
+     (firewall, DNS sinkhole). If the exfiltration channel cannot be identified, isolate the
+     source system. Begin assessing what data was accessible from the compromised system.
+   - **Ransomware/destructive malware**: Isolate affected network segments immediately to
+     prevent lateral spread. Identify and protect backup systems -- attackers increasingly
+     target backups before deploying ransomware. Do not pay ransom without legal counsel and
+     law enforcement consultation.
+   - **Supply chain compromise**: Identify all systems running the compromised component.
+     Block the component's update mechanism. Assess whether the compromise included a
+     backdoor, data exfiltration, or was limited to the update channel.
+
+4. **Preserve evidence before remediation.** Evidence preservation is not optional -- it is
+   required for understanding the full scope of the incident, for potential legal proceedings,
+   and for improving defenses:
+   - **Do not reboot compromised systems.** Rebooting destroys volatile memory, which may
+     contain the attacker's tools, decryption keys, active connections, and process artifacts
+     that are essential for understanding the attack.
+   - **Capture disk images before patching or reimaging.** A bit-for-bit disk image preserves
+     deleted files, file system timestamps, and artifacts that the attacker may have tried to
+     remove. Image the disk to a separate, clean storage device.
+   - **Preserve logs from all sources.** Export logs from the compromised system, load
+     balancers, firewalls, DNS servers, authentication systems, and any other infrastructure
+     that may contain evidence of the attacker's activity. Ensure log integrity by hashing
+     the exported files.
+   - **Document the timeline.** Record every observation, decision, and action with a
+     timestamp. This timeline is the foundation of the post-incident review and any legal or
+     regulatory reporting.
+
+5. **Establish and follow the communication plan.** Incident communication is as critical as
+   technical containment:
+   - **Internal notification chain**: Define who is notified at each severity level. P1
+     incidents notify the CISO, CTO, CEO, and legal counsel immediately. P2 incidents notify
+     the security team lead and engineering leadership. P3/P4 follow standard escalation.
+   - **External notification requirements**: GDPR Article 33 requires breach notification to
+     the supervisory authority within 72 hours of becoming aware of a breach involving personal
+     data. HIPAA requires notification to HHS within 60 days for breaches affecting 500+
+     individuals. PCI-DSS requires notification to the payment card brands and acquiring bank.
+   - **Customer communication**: If customer data is affected, prepare a notification that
+     describes what happened (factually, without speculation), what data was affected, what
+     actions the customer should take, and what the organization is doing to prevent recurrence.
+   - **Law enforcement**: For significant breaches, consult legal counsel about engaging law
+     enforcement (FBI, local authorities). Law enforcement may provide threat intelligence
+     about the attacker and their methods.
+
+## Details
+
+- **Severity classification framework in depth**: P1 (Critical) -- active data exfiltration,
+  destructive attack in progress, complete compromise of authentication infrastructure, or
+  ransomware actively spreading. Response SLA: immediate, all-hands. P2 (High) -- confirmed
+  attacker presence in the environment (e.g., backdoor found, unauthorized access to
+  sensitive systems) but no evidence of active exfiltration or destruction. Response SLA: 1
+  hour. P3 (Medium) -- exploitable vulnerability discovered in production, credential
+  exposure (e.g., secrets committed to a public repository), or phishing campaign targeting
+  employees. Response SLA: 4 hours. P4 (Low) -- suspicious activity requiring investigation,
+  security tool alert of uncertain significance, or minor policy violation. Response SLA:
+  next business day.
+
+- **Network isolation techniques**: Security group modification is the fastest cloud-native
+  isolation method -- modify the instance's security group to deny all inbound and outbound
+  traffic except from a designated forensics jump host. VLAN isolation moves the compromised
+  system to an isolated network segment. DNS sinkholing redirects the attacker's command-and-
+  control domain to a controlled IP address, severing the C2 channel without alerting the
+  attacker that they have been detected. Each technique has trade-offs between speed of
+  implementation, evidence preservation, and attacker awareness.
+
+- **Credential rotation scope and sequencing**: When a system is compromised, assume all
+  credentials accessible from that system are compromised. This includes: service account
+  passwords, API keys in environment variables or configuration files, database connection
+  strings, TLS private keys, SSH keys, and any secrets in the process's memory. Rotate in
+  order of blast radius: domain admin credentials first, then service accounts with broad
+  access, then application-specific credentials. Monitor for the rotated credentials being
+  used after rotation -- this indicates the attacker has a persistence mechanism that captures
+  new credentials.
+
+## Anti-Patterns
+
+1. **Rebooting the compromised system.** The instinct to "restart and see if it fixes it"
+   destroys volatile evidence: memory contents, network connections, running processes, and
+   cached credentials. Memory forensics can reveal the attacker's tools, their command-and-
+   control infrastructure, and what data they accessed. Reboot only after memory and disk have
+   been imaged.
+
+2. **Immediately patching without understanding the full scope.** Patching the exploited
+   vulnerability on the compromised system does not remove the attacker -- they likely
+   established persistence mechanisms (backdoor accounts, scheduled tasks, web shells,
+   modified binaries) on the compromised system and may have moved laterally to other systems.
+   Patching gives a false sense of security while the attacker maintains access through their
+   other footholds.
+
+3. **No predefined incident response plan.** Every incident becomes ad-hoc. The team wastes
+   the critical first hour deciding who should do what, what tools to use, and who to notify.
+   Decisions made under pressure without a plan are consistently worse than decisions made
+   calmly during preparation. Conduct tabletop exercises quarterly and update runbooks based
+   on lessons learned.
+
+4. **Single point of failure in the response team.** Only one person knows the runbooks, has
+   access to the forensics tools, or can authorize containment actions. If that person is
+   unavailable (vacation, sick, different time zone), the response is paralyzed. Cross-train
+   at least two people for every critical response role.
+
+5. **Notification delays.** Delaying breach notification to avoid bad press or in hopes that
+   the incident turns out to be less severe than feared. GDPR mandates 72-hour notification
+   to the supervisory authority. Delayed notification increases legal liability, regulatory
+   fines, and reputational damage when the delay becomes public. Start the notification clock
+   at the moment of awareness and communicate factually about what is known and unknown.

package/dist/agents/skills/codex/security-incident-containment/skill.yaml

@@ -0,0 +1,40 @@
+name: security-incident-containment
+version: '1.0.0'
+description: Incident triage, isolation strategies, evidence preservation, and the first 60 minutes of a security incident -- what to do and what not to touch
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-forensics-fundamentals
+  - security-vulnerability-disclosure
+  - security-post-incident-review
+  - security-log-correlation
+  - owasp-logging-monitoring
+stack_signals: []
+keywords:
+  - incident response
+  - incident containment
+  - triage
+  - isolation
+  - evidence preservation
+  - breach response
+  - security incident
+  - IR playbook
+  - NIST incident response
+  - containment strategy
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []