@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/codex/security-security-champions/SKILL.md

@@ -0,0 +1,165 @@
+# Security Champions Program
+
+> Scale security knowledge across the engineering organization by embedding trained security
+> advocates in every development team -- because the security team cannot review every line of
+> code, but developers can
+
+## When to Use
+
+- The security team is a bottleneck and cannot keep up with the pace of development
+- Security findings are discovered late in the SDLC because developers lack security awareness
+- Starting a formal application security (AppSec) program and need to scale beyond the central
+  security team
+- Developers are resistant to security requirements because they perceive them as imposed by an
+  external team
+- Building a security culture where security is a shared responsibility, not a gatekeeping
+  function
+- Establishing a communication bridge between development teams and the security team
+
+## Threat Context
+
+The ratio of security engineers to software developers in most organizations ranges from 1:100
+to 1:200. At this ratio, the security team cannot review every design, every pull request, or
+every deployment. Security becomes a bottleneck: teams wait days or weeks for security reviews,
+then ship without review when deadlines press. The result is that the majority of code reaches
+production with no security review at all.
+
+The 2021 Log4Shell vulnerability (CVE-2021-44228) demonstrated this scaling problem: the
+vulnerability existed in a ubiquitous logging library for years, unnoticed by the security
+community. Organizations that had security-aware developers in their teams -- developers who
+understood the risk of passing untrusted input to logging functions -- were better positioned
+to identify and remediate the issue quickly. Organizations without distributed security
+knowledge spent weeks determining their exposure.
+
+The BSIMM (Building Security In Maturity Model) study of 130+ organizations found that the
+most mature security programs share a common characteristic: security knowledge is distributed
+across development teams through satellite or champion models, not concentrated in a central
+team. OWASP's Security Champions Guide and SAFECode's "Fundamental Practices for Secure Software
+Development" both identify security champions as a critical scaling mechanism.
+
+## Instructions
+
+1. **Define the security champion role clearly.** A security champion is a developer who
+   volunteers to be the security point of contact for their team. They are not a security
+   engineer and do not replace the security team. Their responsibilities: participate in threat
+   modeling sessions for their team's features, perform security-focused code review on
+   sensitive changes (authentication, authorization, data handling, input validation), champion
+   the use of security tools (SAST, SCA, secrets scanning) within their team, escalate complex
+   security questions to the security team, and share security learnings with their team. The
+   champion spends approximately 10-20% of their time on security activities.
+
+2. **Select champions based on interest and aptitude, not assignment.** Mandatory participation
+   creates resentment and produces disengaged champions. Seek volunteers who have demonstrated
+   interest in security -- developers who ask security questions in code reviews, participate
+   in CTF events, or proactively fix security issues. Technical aptitude matters: the champion
+   must be a respected developer on their team so that their security feedback carries weight.
+   Aim for at least one champion per development team (typically 1 per 6-10 developers).
+
+3. **Provide structured training with progressive skill development.** Initial training (first
+   month): OWASP Top 10 deep dive, threat modeling fundamentals, secure code review techniques,
+   tool usage (running and interpreting SAST/SCA scans). Intermediate training (months 2-6):
+   authentication and authorization design patterns, cryptography basics, API security, incident
+   response awareness. Advanced training (ongoing): advanced attack techniques, security
+   architecture review, mentoring new champions. Training should be hands-on: labs, CTF
+   challenges, and real-world code review exercises, not just presentations.
+
+4. **Establish a regular communication cadence.** Monthly security guild meetings: all champions
+   meet to share findings, discuss new threats, review security tool updates, and learn from
+   each other's experiences. A dedicated Slack or Teams channel for real-time security questions
+   and knowledge sharing. Quarterly training sessions with the security team covering new attack
+   techniques, tool updates, and organizational security priorities. A shared knowledge base
+   (wiki, Confluence, Notion) with security checklists, design patterns, and decision records.
+
+5. **Give champions dedicated time and recognition.** The champion role is additional work on top
+   of regular development responsibilities. Without dedicated time, the champion role becomes
+   unpaid overtime and champions burn out or disengage. Allocate 10-20% of the champion's
+   sprint capacity for security activities. Include security champion contributions in
+   performance reviews. Recognize champions publicly: newsletter mentions, conference talk
+   sponsorship, security champion certification, or career path advancement that acknowledges
+   the dual expertise.
+
+6. **Define the escalation model between champions and the security team.** Champions handle
+   routine security decisions within their team: reviewing PRs for common vulnerabilities,
+   running threat models for standard features, configuring security tools. Champions escalate
+   to the security team for: new or unusual attack patterns, architecture-level security
+   decisions, incidents, compliance questions, and findings they are unsure about. The security
+   team should respond to champion escalations within 24 hours -- slow response kills the
+   program. The security team also provides mentorship, advanced training, and quality assurance
+   of champion activities.
+
+7. **Measure program effectiveness with actionable metrics.** Track: number of security findings
+   identified in design review (by champions, not by penetration tests), mean time to remediate
+   security findings (expect improvement as champions catch issues earlier), percentage of
+   security-sensitive PRs reviewed by a champion before merge, champion engagement (attendance
+   at guild meetings, Slack activity, escalations), and developer security awareness (periodic
+   assessments or quiz scores). Report metrics quarterly and use them to adjust training,
+   recognition, and program structure.
+
+## Details
+
+- **Program maturity stages**: Stage 1 (Foundation, months 1-3): identify and onboard initial
+  champions, deliver foundational training, establish communication channels, define the
+  champion role document. Stage 2 (Integration, months 4-6): integrate champion activities into
+  team workflows (PR review assignments, sprint planning participation), establish escalation
+  protocols, begin tracking metrics. Stage 3 (Optimization, months 7-12): advanced training
+  program, champion-led threat modeling, champion mentoring new champions, data-driven program
+  adjustments. Stage 4 (Scaling, year 2+): champion alumni network, champion-authored security
+  guidelines, champions contributing to organizational security strategy.
+
+- **OWASP Security Champions Guide**: The OWASP guide recommends a tiered model: Tier 1
+  champions (all developers, basic security awareness), Tier 2 champions (dedicated per-team
+  champions, intermediate training), Tier 3 champions (senior champions who mentor others and
+  contribute to security policy). This tiered approach provides broad baseline awareness while
+  concentrating deeper expertise where it is most needed.
+
+- **BSIMM satellite model**: The Building Security In Maturity Model identifies three satellite
+  roles: Security Champion (developer with security training who performs security-focused code
+  review), Security Master (senior developer with advanced security expertise who conducts
+  threat modeling and architecture review), and Software Security Group Contributor (developer
+  who contributes to security team projects -- tool development, security library maintenance,
+  security documentation). Organizations can start with champions and evolve to masters as the
+  program matures.
+
+- **Training resources for champions**: OWASP WebGoat and Juice Shop (hands-on vulnerable
+  applications), PortSwigger Web Security Academy (free, comprehensive web security training),
+  SANS SEC540 (Cloud Security and DevSecOps Automation), Secure Code Warrior (language-specific
+  secure coding exercises), internal CTF events customized to the organization's technology
+  stack. Prefer hands-on, application-level training over theoretical security certifications.
+
+## Anti-Patterns
+
+1. **Mandatory participation with no opt-out.** Forcing developers to be security champions
+   creates resentment and produces champions who do the minimum to satisfy the requirement.
+   Security champions must be volunteers who are genuinely interested in security. Mandatory
+   security awareness training for all developers is appropriate; mandatory champion
+   participation is counterproductive.
+
+2. **No dedicated time -- champion role as unpaid overtime.** Telling developers to be security
+   champions while keeping their sprint velocity expectations unchanged means security work
+   happens evenings and weekends, or not at all. Without dedicated capacity (10-20% of sprint
+   time), the program will lose champions to burnout within months.
+
+3. **Security team uses champions as a triage dump.** Routing all security findings, compliance
+   questionnaires, and vendor security reviews to champions because "they are the security
+   person on the team." Champions are trained developers, not junior security analysts. They
+   handle security within the software development workflow (code review, threat modeling, tool
+   usage). Security operations, compliance, and vendor management remain the security team's
+   responsibility.
+
+4. **No career path or recognition for the champion role.** Developers who invest time in
+   security skills and champion activities but receive no recognition in promotions, performance
+   reviews, or compensation will eventually stop volunteering. Create a visible career path:
+   champion -> senior champion -> security architect, or include security contributions as a
+   factor in the engineering promotion criteria.
+
+5. **Champions without training or authority.** Appointing champions but providing no training
+   means they cannot identify vulnerabilities beyond the obvious. Appointing champions with no
+   authority means their security feedback is ignored by the team. Champions need both:
+   structured training that builds real expertise, and organizational backing that makes their
+   security review a required (not optional) step in the development process.
+
+6. **Single point of failure -- one champion per large team.** If a team of 15 developers has
+   one champion and that champion goes on vacation, changes teams, or leaves the organization,
+   the team has zero security coverage. Train at least two champions per team for redundancy,
+   and maintain a champion alumni community so that former champions retain their security
+   knowledge even after leaving the formal role.

package/dist/agents/skills/codex/security-security-champions/skill.yaml

@@ -0,0 +1,37 @@
+name: security-security-champions
+version: '1.0.0'
+description: Embedding security expertise in development teams through security champion programs -- scaling security knowledge without scaling the security team
+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-threat-modeling-process
+  - security-ci-security-testing
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - security champion
+  - security culture
+  - security training
+  - developer security
+  - security advocate
+  - secure coding
+  - security awareness
+  - AppSec program
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-session-management/SKILL.md

@@ -0,0 +1,196 @@
+# Session Management
+
+> Session tokens are bearer credentials -- generate with CSPRNG, bind to client context, enforce idle and absolute timeouts, and regenerate on privilege changes
+
+## When to Use
+
+- Designing the authentication and session layer of a web application
+- Choosing between server-side sessions and JWTs (stateless tokens)
+- Reviewing session cookie configuration for security gaps
+- Implementing session timeout and revocation policies
+- Investigating session hijacking or session fixation vulnerabilities
+- Adding "remember me" functionality or concurrent session controls
+
+## Threat Context
+
+Session hijacking -- stealing a valid session token -- gives an attacker full access to the victim's account without knowing the password.
+The attack surface is broad:
+
+- **Network sniffing** on unencrypted connections (mitigated by TLS and the Secure cookie flag)
+- **Cross-site scripting** that reads `document.cookie` (mitigated by HttpOnly)
+- **Session fixation** where the attacker pre-sets the session ID before the victim authenticates
+- **Cross-site request forgery** that rides on automatically-attached cookies (mitigated by SameSite)
+- **Client-side token theft** from malware, browser extensions, or shared computers
+
+The consequences are severe.
+The 2023 Okta support breach exploited stolen session tokens embedded in HAR files (HTTP archive recordings that included cookies) to access customer admin accounts.
+The 2022 GitHub OAuth token theft allowed attackers to download private repositories by stealing OAuth session tokens from Heroku and Travis CI integrations.
+In both cases, the attackers never needed passwords -- the session token was the credential.
+
+Session management is the bridge between authentication (proving identity) and authorization (enforcing permissions).
+A flaw in session management undermines both, regardless of how strong the password hashing or access control system is.
+
+## Instructions
+
+1. **Generate session tokens with a CSPRNG.**
+   Use a cryptographically secure pseudorandom number generator to produce tokens with a minimum of 128 bits of entropy (32 hex characters or 22 base64 characters).
+   Use the platform's dedicated cryptographic random generator:
+   - Node.js: `crypto.randomBytes(32)`
+   - Python: `os.urandom(32)` or `secrets.token_hex(32)`
+   - Java: `SecureRandom.getInstanceStrong()`
+   - Go: `crypto/rand.Read`
+
+   Never use `Math.random()`, sequential database IDs, timestamps, user IDs, or any predictable value.
+   The token must be computationally infeasible to guess even if the attacker knows the generation algorithm.
+
+2. **Configure session cookies with all security flags.**
+   Every session cookie must have:
+   - `Secure`: Transmit only over HTTPS. Prevents session tokens from being exposed on unencrypted connections. Without this flag, a single HTTP request (even caused by a mixed-content resource) leaks the token.
+   - `HttpOnly`: Inaccessible to JavaScript via `document.cookie`. Prevents XSS attacks from reading the session token. This is the single most effective mitigation against XSS-based session theft.
+   - `SameSite=Lax` (minimum) or `SameSite=Strict`: Controls when cookies are sent on cross-origin requests. `Strict` never sends the cookie on cross-origin requests (maximum protection, but breaks inbound links that should maintain login state). `Lax` sends the cookie on top-level navigations (GET requests from external links) but not on cross-origin subresources or POST requests. Use `Strict` for high-security applications (banking, healthcare); `Lax` for applications where users follow links from email or external sites.
+   - `Path=/`: Scope the cookie to the entire application. Avoid overly narrow paths that create confusion about which requests include the session.
+   - `Domain`: Set explicitly to the exact domain. Omitting the Domain attribute restricts the cookie to the exact origin (most restrictive and safest default). Setting Domain to a parent domain (e.g., `.example.com`) shares the session across all subdomains, which expands the attack surface.
+   - Short `Max-Age` or `Expires`: Align with your absolute timeout policy. For session cookies (no persistence), omit both attributes so the cookie is deleted when the browser closes.
+
+3. **Regenerate the session ID on every authentication state change.**
+   After successful login, privilege escalation (entering admin mode, impersonating another user), password change, MFA enrollment, or any change in the user's security context, issue a completely new session token and invalidate the previous one server-side.
+
+   This is the primary defense against session fixation, where an attacker plants a known session ID in the victim's browser (via URL parameter, cookie injection on a subdomain, or meta tag injection) before the victim logs in.
+   Without regeneration, the attacker's pre-set session ID becomes authenticated when the victim completes login.
+
+4. **Enforce dual timeouts with server-side tracking.**
+   - **Idle timeout** (15-30 minutes for sensitive applications like banking and healthcare; 2-8 hours for low-risk applications): If the user performs no server-recognized activity for this duration, invalidate the session. Track the last-activity timestamp on the server, not the client. Client-side timers are trivially bypassable.
+   - **Absolute timeout** (8-24 hours): Maximum session lifetime regardless of activity. Forces periodic re-authentication. Critical for limiting the damage window if a token is stolen -- even an actively-used stolen token expires at the absolute timeout. For high-security contexts, absolute timeouts of 1-4 hours are appropriate.
+
+   Store both timestamps (`last_activity`, `created_at`) in the server-side session record and check both on every request.
+
+5. **Implement immediate server-side revocation.**
+   Maintain a server-side session store (database table, Redis, Memcached) that maps session tokens to session records.
+   When the user logs out, changes their password, is administratively suspended, or triggers a security event, delete the session record from the store.
+   The next request with the old token fails authentication immediately.
+
+   This is the fundamental limitation of stateless JWTs for session management: a JWT cannot be revoked before its `exp` claim without maintaining a server-side blocklist, which negates the stateless benefit.
+
+6. **Bind sessions to client context for theft detection.**
+   At session creation, record the client's IP address (or IP prefix for mobile users on carrier NAT), User-Agent string, and optionally the TLS client certificate fingerprint or device identifier.
+   On subsequent requests, compare current values against the recorded ones.
+
+   If the IP address changes to a different geographic region, or the User-Agent changes entirely, require step-up authentication (re-enter password or complete MFA) rather than silently accepting the request.
+   This does not prevent token theft but limits its utility -- a token stolen and used from a different continent or browser triggers re-authentication.
+
+7. **JWT-specific guidance when JWTs are used for sessions.**
+   Keep access token expiry short (5-15 minutes).
+   Use a separate refresh token stored in an HttpOnly Secure cookie to obtain new access tokens.
+   Store refresh tokens server-side (in a database) for revocability.
+   Never store JWTs in localStorage or sessionStorage -- both are accessible to JavaScript and therefore vulnerable to XSS.
+
+   Sign with asymmetric algorithms (RS256, ES256, EdDSA) so that services can verify tokens without possessing the signing key.
+   Validate all claims on every request: `iss`, `aud`, `exp`, `nbf`, `sub`.
+   Reject tokens with `alg: none` or unexpected algorithms (the `alg` confusion attack).
+
+## Details
+
+### Server-Side Sessions vs. JWTs
+
+Server-side sessions store session state on the server; the session token sent to the client is an opaque random identifier that maps to a server-side record.
+JWTs store session state in the token itself (self-contained claims signed by the server).
+
+**Server-side sessions** are inherently revocable (delete the server-side record), support arbitrary session data without size concerns, and do not expose session metadata to the client.
+The cost is a session store (Redis or database) that must be available on every request.
+
+**JWTs** are not revocable without a server-side blocklist, which introduces the same infrastructure dependency as server-side sessions while adding complexity.
+JWT payloads are base64-encoded (not encrypted) and expose claims to the client and any intermediary.
+JWTs grow in size with additional claims and are transmitted on every request.
+
+For most web applications, server-side sessions backed by Redis are simpler, more secure, and more operationally straightforward.
+JWTs are appropriate for short-lived access tokens in microservice architectures where an API gateway validates the JWT and downstream services trust the gateway's authentication decision.
+
+### The "Remember Me" Pattern
+
+A persistent login token with a 30-90 day expiry, stored in a separate HttpOnly Secure cookie distinct from the session cookie.
+
+Implementation:
+
+1. Generate a random token (128+ bits)
+2. Store it hashed (SHA-256) in a database table alongside the user ID and expiry timestamp
+3. Never store the persistent token in plaintext -- if the database is breached, plaintext tokens allow immediate account access
+
+When the session expires but the persistent token is valid, create a new session with restricted privileges: allow reading and browsing but require re-authentication for sensitive operations (changing password, modifying payment methods, accessing sensitive data).
+
+After using the persistent token, rotate it: invalidate the current token and issue a new one.
+This limits the window of a stolen persistent token.
+
+### Concurrent Session Controls
+
+Decide whether a user can have multiple simultaneous sessions across devices:
+
+- **Unlimited sessions** (most common): Simple, user-friendly, but a compromised token on one device is not invalidated by activity on another.
+- **Limit to N sessions**: When the user exceeds N sessions, revoke the oldest. Provides a natural cap on exposure.
+- **Single session only**: Each new login invalidates all previous sessions. Maximum security but poor UX for users with multiple devices.
+- **Visibility and selective revocation**: Show the user their active sessions (device, location, last active) and allow them to revoke individual sessions. This is the modern best practice for consumer and enterprise applications alike.
+
+### Session Storage Backend Selection
+
+The session store must support:
+
+- Fast reads on every request (sub-millisecond latency)
+- Atomic writes for session creation and update
+- TTL-based expiration for automatic cleanup
+- Deletion for immediate revocation
+
+Common choices:
+
+- **Redis**: Sub-millisecond latency, built-in TTL, widely supported by session middleware. The most common choice for production session stores.
+- **Memcached**: Similar performance to Redis but no persistence. Acceptable for sessions (which are ephemeral) but lost sessions force re-authentication on restart.
+- **Database (PostgreSQL, MySQL)**: Higher latency but simpler infrastructure. Acceptable for applications with moderate traffic. Use a TTL column and periodic cleanup job.
+- **In-memory (application process)**: Not suitable for production. Sessions are lost on restart and not shared across instances.
+
+### Token Entropy Requirements
+
+OWASP recommends a minimum of 128 bits of entropy for session identifiers.
+This produces a token space of 2^128 (approximately 3.4 x 10^38) possible values.
+
+For context: if an attacker can try 10 billion tokens per second, exhausting a 128-bit space would take approximately 10^19 years.
+Even with optimistic attack assumptions, 128 bits provides a comfortable margin.
+
+Use 256-bit tokens when defense in depth is warranted (high-security applications, tokens that may be long-lived).
+
+## Anti-Patterns
+
+1. **Session tokens in URLs.**
+   Query parameters appear in browser history, server access logs, Referer headers sent to third-party resources, and proxy logs.
+   A URL like `/dashboard?session=abc123` leaks the session to every linked resource, every log aggregator, and every browser extension with history access.
+   Session tokens must be in cookies (preferred for web applications) or Authorization headers (for APIs).
+
+2. **Not regenerating the session ID after login.**
+   This is the textbook session fixation vulnerability.
+   The attacker sets the victim's session ID to a known value (via a crafted link, a subdomain cookie injection, or a meta tag).
+   The victim logs in.
+   The server associates the attacker's known session ID with the victim's authenticated identity.
+   The attacker now has an authenticated session.
+
+3. **Storing JWTs in localStorage.**
+   `localStorage` is accessible to any JavaScript executing in the page's origin.
+   A single XSS vulnerability -- whether from a dependency, a user-generated content rendering flaw, or a third-party script -- can exfiltrate every JWT in localStorage.
+   Unlike cookies with HttpOnly, there is no browser-level protection.
+   Use HttpOnly Secure cookies for all token storage in web applications.
+
+4. **No idle timeout.**
+   A session that lives until the absolute timeout (or forever, if no absolute timeout exists) on an unattended browser is an open door.
+   Shared workstations, kiosk computers, stolen laptops, and unlocked phones all provide persistent access to anyone with physical proximity.
+   Idle timeouts force re-authentication after periods of inactivity.
+
+5. **Logout that only clears the client-side cookie.**
+   If the server-side session record is not invalidated, an attacker who captured the session token before logout can continue using it.
+   Server-side invalidation is mandatory.
+   The client-side cookie deletion is a UX convenience, not a security control.
+
+6. **Using predictable session identifiers.**
+   Sequential database IDs, timestamps, user IDs, or any value an attacker can guess or enumerate.
+   If the session token space is predictable, an attacker can iterate through valid tokens without stealing them.
+   Session tokens must have at least 128 bits of entropy from a CSPRNG.
+
+7. **Trusting client-reported timeout state.**
+   Implementing idle timeout by having client JavaScript report "I am still active" and resetting the server timer.
+   An attacker with a stolen token can trivially send keep-alive requests.
+   Idle timeout must be measured server-side by tracking the timestamp of the last legitimate request processed.

package/dist/agents/skills/codex/security-session-management/skill.yaml

@@ -0,0 +1,41 @@
+name: security-session-management
+version: "1.0.0"
+description: Session lifecycle design -- token generation, fixation prevention, binding, idle and absolute timeouts, revocation, and secure cookie configuration
+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-authentication-flows
+  - security-cryptographic-randomness
+  - security-tls-fundamentals
+  - owasp-auth-patterns
+  - owasp-csrf-protection
+  - owasp-security-headers
+stack_signals: []
+keywords:
+  - session management
+  - session token
+  - session fixation
+  - session hijacking
+  - cookie security
+  - token revocation
+  - idle timeout
+  - absolute timeout
+  - JWT session
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-shift-left-design/SKILL.md

@@ -0,0 +1,153 @@
+# Shift-Left Security Design
+
+> Find security flaws in the design document, not in the penetration test report -- because
+> fixing an architecture flaw costs 100x more after deployment than during design
+
+## When to Use
+
+- Starting the design phase of a new feature, service, or system that handles sensitive data
+- Conducting a design review and need a structured approach to identifying security concerns
+- Integrating security into agile ceremonies without creating bottlenecks
+- Building a secure SDLC process for an organization that currently does security only in QA
+- Evaluating whether a proposed architecture has fundamental security weaknesses before writing
+  code
+- Defining security requirements alongside functional requirements for a new project
+
+## Threat Context
+
+The NIST/IBM Systems Sciences Institute data on defect cost escalation shows that a security flaw
+found in the design phase costs 1x to fix, in implementation costs 6.5x, in testing costs 15x,
+and in production costs 100x. These numbers are not theoretical -- they reflect the difference
+between changing a design document and performing an emergency production deployment with data
+breach notification, incident response, customer communication, and regulatory reporting.
+
+The 2017 Equifax breach (CVE-2017-5638, Apache Struts) exposed 147 million records. The
+vulnerability was in a third-party component, but the architectural failure was deeper: the
+application ran with direct access to a database containing 147 million unencrypted SSNs, with no
+network segmentation, no data access monitoring, and no principle of least privilege. These are
+design-phase decisions. A threat model during design would have identified that a single web
+application vulnerability should not grant access to the entire consumer database.
+
+Organizations that defer security analysis to the testing phase consistently find architectural
+flaws that cannot be fixed without redesigning the system. At that point, the choice is between
+shipping an insecure architecture or missing the deadline by months. Shift-left security ensures
+that security-critical design decisions are made when they are cheapest and easiest to change.
+
+## Instructions
+
+1. **Elicit security requirements alongside functional requirements.** For every user story or
+   feature specification, ask: What data does this feature access, store, or transmit? Who is
+   authorized to use this feature? What happens if this feature is abused? What compliance
+   requirements apply? Security requirements are not separate from functional requirements --
+   they are constraints on how functionality is implemented. Document them in the same backlog
+   and give them the same priority as functional requirements.
+
+2. **Conduct a threat model for every new feature that changes the trust boundary.** Not every
+   feature needs a full STRIDE analysis, but any feature that introduces a new data flow, a new
+   external integration, a new user role, or a new API endpoint should have a lightweight threat
+   model. Use the "four question" approach: What are we building? What can go wrong? What are we
+   going to do about it? Did we do a good job? This takes 30-60 minutes in a design review
+   meeting and identifies architectural vulnerabilities that no scanner will find.
+
+3. **Integrate security checkpoints into agile ceremonies.** Sprint planning: review new stories
+   for security implications. Design review: include a "security considerations" section in every
+   design document. Definition of done: include "threat model reviewed" and "security
+   requirements addressed" alongside "tests pass" and "code reviewed." Retrospective: review
+   security findings from the sprint and adjust processes. These are lightweight additions to
+   existing ceremonies, not new meetings.
+
+4. **Create and maintain a security design review checklist.** The checklist should cover:
+   authentication (how does the feature verify user identity?), authorization (who can perform
+   which actions on which resources?), input validation (what inputs does the feature accept and
+   how are they validated?), data protection (is sensitive data encrypted at rest and in
+   transit?), logging (what security-relevant events does this feature produce?), error handling
+   (do error messages leak internal details?), and dependency risk (what new dependencies does
+   this feature introduce?). The checklist is a starting point, not a substitute for thinking.
+
+5. **Use abuse cases alongside use cases.** For every use case ("User uploads a profile photo"),
+   write the corresponding abuse case ("Attacker uploads a PHP webshell as a profile photo,"
+   "Attacker uploads a 10GB file to exhaust storage," "Attacker uploads an image with EXIF GPS
+   data harvesting"). Abuse cases force the team to think adversarially during design, not after
+   deployment. They also produce concrete test cases for the QA team.
+
+6. **Establish architecture-level security patterns as defaults.** Reduce the design-phase
+   security burden by establishing organizational defaults: all inter-service communication uses
+   mTLS, all data stores encrypt at rest, all APIs require authentication, all user input is
+   validated against a schema, all sensitive operations produce audit events. When these are
+   defaults, the design review focuses on feature-specific risks rather than relitigating
+   baseline security decisions.
+
+7. **Track security design decisions as architectural decision records (ADRs).** When a design
+   review produces a security-relevant decision (using JWT instead of session cookies, choosing
+   row-level security over application-level filtering, accepting a specific risk with
+   mitigation), record it as an ADR. This creates a searchable history of why security decisions
+   were made, prevents relitigating resolved decisions, and provides context for future threat
+   model updates.
+
+## Details
+
+- **The cost curve of defect remediation**: IBM Systems Sciences Institute and NIST data show
+  exponential cost increases as defects move through the SDLC. Design phase: 1x (change the
+  document). Implementation phase: 6.5x (rewrite code, update tests). Testing phase: 15x
+  (fix code, retest, delay release). Production phase: 100x (emergency patch, incident response,
+  customer notification, regulatory reporting, reputation damage). The Ponemon Institute's Cost
+  of a Data Breach Report (2023) puts the average cost of a data breach at $4.45 million, with
+  breaches caused by security system complexity and cloud migration failures (both design-phase
+  issues) costing significantly more.
+
+- **Security requirements elicitation techniques**: OWASP Application Security Verification
+  Standard (ASVS) provides a comprehensive checklist of security requirements organized by
+  level (L1: opportunistic, L2: standard, L3: advanced). Use ASVS as a requirements source
+  during design. Microsoft's Security Development Lifecycle (SDL) provides security requirements
+  templates. NIST SP 800-53 provides security control families for federal systems. Map
+  compliance requirements (SOC2, PCI-DSS, HIPAA) to specific security requirements early.
+
+- **Lightweight threat modeling for agile teams**: The full STRIDE-per-element analysis is too
+  heavyweight for every sprint. Use rapid threat modeling: 15-minute session during design
+  review, focused on the specific feature being built. Draw the data flow diagram for the new
+  feature on a whiteboard, identify trust boundaries, and brainstorm threats at each boundary
+  crossing. Document findings as backlog items. This scales to agile velocity.
+
+- **Security design review triggers**: Not every code change needs a security review. Define
+  triggers: new authentication or authorization logic, new data stores for sensitive data, new
+  external integrations or API endpoints, changes to encryption or key management, new user
+  roles or permission models, infrastructure changes (new services, network changes). Changes
+  that do not cross a trust boundary can proceed without security design review.
+
+## Anti-Patterns
+
+1. **Security review as a gatekeeping bottleneck.** When the security team must approve every
+   design before development can start, security becomes a scheduling constraint that teams work
+   around rather than with. Instead, embed security knowledge in development teams (security
+   champions), provide self-service design review checklists, and reserve the security team's
+   direct involvement for high-risk features that cross trust boundaries.
+
+2. **Treating threat modeling as a document rather than a design influence.** A threat model
+   produced to satisfy a process requirement and then filed away provides no security value. The
+   purpose of threat modeling is to change the design. If the threat model does not result in
+   at least one design modification, backlog item, or accepted-risk decision, it was either done
+   too late or not taken seriously.
+
+3. **The "security sprint" anti-pattern.** Batching all security work into a dedicated sprint
+   (usually before a release) means security issues accumulate for weeks, are rushed through in a
+   compressed timeline, and the fixes are inadequately tested. Security is a continuous concern,
+   not a batch process. Integrate security requirements into every sprint, address findings as
+   they are discovered, and include security criteria in the definition of done for every story.
+
+4. **Relying solely on automated scanning without design-phase analysis.** SAST and DAST tools
+   find implementation bugs (SQL injection, XSS, buffer overflows) but cannot find architectural
+   flaws (missing authorization checks, improper trust boundaries, insecure data flows, lack of
+   rate limiting). A design that routes all traffic through a single unauthenticated API gateway
+   is an architectural vulnerability that no scanner will detect. Design-phase analysis and
+   automated scanning are complementary, not substitutes.
+
+5. **Security requirements as non-functional requirements.** Labeling security as "non-functional"
+   marginalizes it. Security requirements are functional constraints: "the API must reject
+   requests without a valid authentication token" is as functional as "the API must return user
+   data in JSON format." Treat security requirements with the same priority, tracking, and
+   testing discipline as any other requirement.
+
+6. **One-time threat model never updated.** A threat model created during initial design and
+   never revisited becomes stale as the system evolves. New features, new integrations, and new
+   threat intelligence change the risk landscape. Review and update threat models when
+   significant changes are made to the system, or at minimum quarterly for high-risk systems.

package/dist/agents/skills/codex/security-shift-left-design/skill.yaml

@@ -0,0 +1,38 @@
+name: security-shift-left-design
+version: '1.0.0'
+description: Integrating threat modeling and security analysis into the design phase -- finding security flaws when they cost $1 to fix instead of $100 in production
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-threat-modeling-process
+  - security-threat-modeling-stride
+  - security-ci-security-testing
+  - security-security-champions
+  - owasp-auth-patterns
+stack_signals: []
+keywords:
+  - shift left
+  - security by design
+  - secure design review
+  - security requirements
+  - threat modeling in design
+  - NIST cost of defects
+  - security architecture review
+  - design phase security
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []