@harness-engineering/cli 1.24.0 → 1.24.1

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

@@ -0,0 +1,39 @@
+name: security-post-incident-review
+version: '1.0.0'
+description: Blameless post-incident reviews for security incidents -- structured analysis, root cause identification, remediation tracking, and organizational learning
+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-forensics-fundamentals
+  - security-vulnerability-disclosure
+  - owasp-logging-monitoring
+stack_signals: []
+keywords:
+  - post-incident review
+  - post-mortem
+  - blameless retrospective
+  - root cause analysis
+  - remediation tracking
+  - lessons learned
+  - incident review
+  - five whys
+  - contributing factors
+  - corrective action
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/security-race-conditions/SKILL.md

@@ -0,0 +1,186 @@
+# Race Conditions
+
+> When security depends on the order of operations but the system does not enforce that
+> order, attackers exploit the gap between check and use -- turning microsecond timing windows
+> into privilege escalation, double-spend, and data corruption
+
+## When to Use
+
+- Designing financial transactions, balance checks, or any operation where concurrent
+  requests could produce incorrect results
+- Reviewing code that checks a condition and then acts on it without holding a lock
+- Building file operations that create, read, or write files based on prior checks
+- Implementing coupon redemption, vote counting, inventory management, or any system where
+  duplicate processing has business impact
+- Choosing database isolation levels and locking strategies for concurrent access
+- Reviewing authentication or authorization flows for time-of-check-to-time-of-use gaps
+
+## Threat Context
+
+Race conditions are among the most underestimated vulnerability classes because they are
+non-deterministic -- they may not appear in testing but are reliably exploitable by an
+attacker who controls timing:
+
+- **Ethereum DAO hack (2016)**: A reentrancy race condition in the DAO smart contract
+  allowed the attacker to recursively withdraw funds before the balance was updated.
+  The attacker drained 3.6 million ETH (approximately $50 million at the time). The
+  vulnerability existed because the contract sent ETH to the caller before updating the
+  caller's balance -- the caller's receive function re-entered the withdraw function and
+  repeated the withdrawal against the stale balance.
+- **Dirty COW (CVE-2016-5195)**: A race condition in the Linux kernel's memory management
+  subsystem allowed an unprivileged local user to gain write access to read-only memory
+  mappings. The race existed in the copy-on-write (COW) mechanism -- by racing two threads
+  (one faulting on the mapping, one calling `madvise(MADV_DONTNEED)`), the attacker could
+  write to files they had only read permission for, including `/etc/passwd`. This privilege
+  escalation vulnerability existed in the Linux kernel for 9 years before discovery.
+- **Web application double-spend**: An e-commerce platform allowed customers to apply a
+  discount code. Two concurrent requests, each checking that the code had not been used and
+  then marking it as used, both read the code as unused and both applied the discount. At
+  scale, automated tools send hundreds of concurrent requests to exploit such windows.
+- **Symlink race in temporary files**: A privileged program checks that a temporary file
+  does not exist, then creates it. Between the check and the creation, the attacker creates
+  a symlink at that path pointing to `/etc/shadow`. The privileged program writes to the
+  symlink, overwriting the password file. This classic TOCTOU pattern has affected `sudo`,
+  `sendmail`, and numerous other privileged Unix programs.
+
+## Instructions
+
+1. **Recognize the TOCTOU pattern.** Time-of-check-to-time-of-use vulnerabilities follow a
+   universal structure: the program checks a condition (file exists, balance is sufficient,
+   user is authorized, code is unused), then performs an action based on that condition (write
+   the file, deduct the balance, grant access, apply the discount). If the condition can
+   change between the check and the action, the action operates on a stale assumption. The
+   fix is always the same principle: make the check and the action atomic -- either they
+   happen as one indivisible operation, or a lock ensures nothing changes between them.
+
+2. **Use database-level atomicity for business logic.** The database is the only reliable
+   point of serialization in a multi-instance web application:
+   - **SELECT FOR UPDATE**: Acquires a row-level lock that prevents other transactions from
+     reading or modifying the row until the lock is released. Use for balance checks followed
+     by balance updates: `SELECT balance FROM accounts WHERE id = ? FOR UPDATE`, verify
+     balance is sufficient, then `UPDATE accounts SET balance = balance - ? WHERE id = ?`.
+   - **Serializable isolation**: The strictest isolation level. Transactions execute as if
+     they ran sequentially. Use for financial operations where phantom reads or write skew
+     would cause incorrect results. Be aware of the performance cost -- serializable isolation
+     increases lock contention and aborted transactions.
+   - **Unique constraints**: For operations that must happen exactly once (coupon redemption,
+     account creation with a unique email), enforce uniqueness at the database level with a
+     UNIQUE constraint or UNIQUE INDEX. The database rejects the duplicate insert atomically.
+     Do not rely on application-level checks (`SELECT` to see if exists, then `INSERT`).
+   - **Advisory locks**: Database-specific named locks (`pg_advisory_lock` in PostgreSQL,
+     `GET_LOCK` in MySQL) for coordinating operations that span multiple tables or require
+     application-level logic between the check and the action.
+   - **Atomic updates**: Use `UPDATE accounts SET balance = balance - 100 WHERE id = ? AND
+balance >= 100` -- this combines the check and the update in a single atomic statement.
+     If the balance is insufficient, zero rows are updated. No race window exists.
+
+3. **Implement idempotency keys for external-facing operations.** Idempotency ensures that
+   processing the same request multiple times produces the same result as processing it once:
+   - The client generates a unique idempotency key (UUID) and includes it in the request.
+   - The server stores the key and the result of the first processing.
+   - Subsequent requests with the same key return the stored result without re-executing the
+     operation.
+   - Store idempotency keys with a UNIQUE constraint. The database prevents duplicate
+     processing atomically.
+   - Idempotency keys protect against network retries, client bugs, and deliberate duplicate
+     submissions.
+
+4. **Use optimistic locking for low-contention updates.** Add a version column to the row.
+   Every update includes `WHERE version = ?` with the version the client read. If another
+   transaction modified the row (incrementing the version), the update affects zero rows and
+   the application knows to retry with the new version:
+   - Read: `SELECT id, balance, version FROM accounts WHERE id = ?`
+   - Update: `UPDATE accounts SET balance = ?, version = version + 1 WHERE id = ? AND
+version = ?`
+   - If zero rows affected: re-read and retry (with a retry limit to prevent infinite loops)
+   - Optimistic locking avoids holding database locks during user think-time and is preferred
+     for web applications where contention is typically low.
+
+5. **Eliminate file system race conditions.** File operations are particularly vulnerable
+   because the file system namespace is shared:
+   - **Atomic file creation**: Use `O_CREAT | O_EXCL` flags with `open()`. This creates the
+     file only if it does not already exist, atomically. If the file exists (including as a
+     symlink), the call fails. Do not use `access()` or `stat()` followed by `open()`.
+   - **Operate on file descriptors, not paths**: After opening a file, use `fstat()`,
+     `fchmod()`, `fchown()` instead of `stat()`, `chmod()`, `chown()`. File descriptor
+     operations act on the actual file, not the path -- an attacker cannot redirect them via
+     symlink replacement.
+   - **Use `mkstemp()` or `tmpfile()`**: These create temporary files with unique names
+     atomically. Do not use `tmpnam()` or `tempnam()` followed by `open()` -- the name can
+     be predicted and replaced between generation and use.
+   - **Use `renameat2()` with `RENAME_NOREPLACE`** (Linux) for atomic file placement.
+     Write content to a temporary file, then atomically rename it to the target path. The
+     rename is atomic -- readers see either the old file or the new file, never a partial
+     write.
+
+6. **Design for concurrent execution from the start.** Assume every operation will be
+   executed concurrently by multiple instances:
+   - Never assume single-instance deployment. Even if there is one instance today, horizontal
+     scaling or failover will introduce concurrency.
+   - Use atomic compare-and-swap (CAS) operations for in-memory state in multi-threaded
+     applications. CAS is the primitive that makes lock-free data structures possible.
+   - Identify all "check-then-act" sequences in the codebase and evaluate whether the check
+     and act are atomic. If they are not, add appropriate locking or use atomic operations.
+
+## Details
+
+- **How attackers exploit web application race conditions at scale**: Tools like Turbo
+  Intruder (Burp Suite extension) and custom scripts send dozens to hundreds of concurrent
+  HTTP requests, all arriving at the server within a few milliseconds. The attacker does not
+  need precise timing -- they flood the server with concurrent requests and statistical
+  probability ensures that some requests hit the race window. A discount code that can be
+  used once is used 50 times. A bank transfer of $100 from a $150 account is executed 10
+  times. A free trial activation creates 100 accounts. The defense must be correct under
+  maximum concurrency, not just typical load.
+
+- **Database isolation levels and their race condition implications**: READ UNCOMMITTED allows
+  dirty reads (seeing uncommitted changes from other transactions). READ COMMITTED (the
+  default in PostgreSQL and Oracle) prevents dirty reads but allows non-repeatable reads (a
+  row read twice in the same transaction returns different values) and phantom reads (a range
+  query returns different rows). REPEATABLE READ (the default in MySQL/InnoDB) prevents dirty
+  and non-repeatable reads but allows phantom reads in the SQL standard (though InnoDB's
+  implementation also prevents phantoms). SERIALIZABLE prevents all anomalies but increases
+  contention. For financial transactions, READ COMMITTED with explicit `SELECT FOR UPDATE`
+  locking is the most common practical approach -- it provides the necessary atomicity
+  without the global performance cost of serializable isolation.
+
+- **The double-spend pattern in detail**: User has $150. Two concurrent transfers of $100
+  each arrive. Thread A: `SELECT balance FROM accounts WHERE id = 1` returns $150. Thread B:
+  `SELECT balance FROM accounts WHERE id = 1` returns $150 (Thread A has not yet updated).
+  Thread A: balance >= 100, so `UPDATE accounts SET balance = 50 WHERE id = 1`. Thread B:
+  balance >= 100 (it read $150), so `UPDATE accounts SET balance = 50 WHERE id = 1`. Both
+  succeed. The user transferred $200 from a $150 balance. With `SELECT FOR UPDATE`, Thread B
+  blocks until Thread A commits, then re-reads balance as $50 and correctly rejects the
+  transfer.
+
+## Anti-Patterns
+
+1. **Check-then-act without holding a lock.** Reading a value, making a decision based on
+   that value, and then writing -- without ensuring the value has not changed. This is the
+   fundamental race condition pattern. The gap between the check and the act is the
+   vulnerability window. Use atomic operations, database locks, or optimistic locking to
+   close the window.
+
+2. **Using READ COMMITTED isolation for financial transactions without explicit locking.**
+   READ COMMITTED does not prevent two transactions from reading the same balance and both
+   deducting from it. Without `SELECT FOR UPDATE` or an atomic `UPDATE ... WHERE balance >=
+?`, the double-spend pattern is exploitable. READ COMMITTED is safe for reads that do not
+   influence writes, but financial transactions require explicit serialization.
+
+3. **Relying on application-level uniqueness checks without database constraints.** Checking
+   `SELECT COUNT(*) FROM users WHERE email = ?` and then `INSERT INTO users (email, ...)
+VALUES (?, ...)` if the count is zero. Two concurrent registrations with the same email
+   both read count = 0 and both insert. Add a UNIQUE constraint on the email column and
+   handle the constraint violation error -- the database enforces uniqueness atomically.
+
+4. **Non-atomic file operations with predictable temporary filenames.** Using `tempnam()` to
+   generate a filename, then `open()` to create it. An attacker predicts the filename (or
+   creates symlinks for all likely names) and interposes between generation and creation.
+   Use `mkstemp()` which generates and opens the file in a single atomic operation.
+
+5. **Assuming single-threaded execution in a multi-instance deployment.** Code that uses
+   in-memory locks (`synchronized` in Java, `threading.Lock` in Python) to prevent race
+   conditions. These locks protect against concurrency within a single process but do nothing
+   when the application runs as multiple instances behind a load balancer. The lock must be
+   at the shared state level -- typically the database or a distributed lock (Redis SETNX,
+   ZooKeeper, etcd).

package/dist/agents/skills/codex/security-race-conditions/skill.yaml

@@ -0,0 +1,39 @@
+name: security-race-conditions
+version: '1.0.0'
+description: TOCTOU vulnerabilities, double-spend attacks, file system races, and the security implications of non-atomic operations in concurrent systems
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-deserialization-attacks
+  - security-injection-families
+  - security-session-management
+  - owasp-csrf-protection
+stack_signals: []
+keywords:
+  - race condition
+  - TOCTOU
+  - time of check time of use
+  - double spend
+  - concurrent vulnerability
+  - atomicity
+  - file system race
+  - check-then-act
+  - idempotency
+  - optimistic locking
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

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

@@ -0,0 +1,209 @@
+# RBAC Design
+
+> Assign permissions to roles, assign roles to users -- simple, auditable, and sufficient for most applications when combined with resource-level checks
+
+## When to Use
+
+- Designing an authorization system for a new application
+- Evaluating whether RBAC is the right model (vs ABAC or ReBAC) for your use case
+- Refactoring an ad-hoc permission system into a structured model
+- Adding multi-tenancy authorization to an existing application
+- Auditing role assignments for principle of least privilege compliance
+- Preventing role explosion as the application grows
+
+## Threat Context
+
+Authorization failures are the number one vulnerability category in the OWASP Top 10 (A01:2021 -- Broken Access Control), having risen from fifth place in the 2017 edition.
+The category encompasses multiple distinct attack classes:
+
+- **Horizontal privilege escalation**: Accessing another user's data by manipulating an ID parameter (Insecure Direct Object Reference, or IDOR)
+- **Vertical privilege escalation**: Accessing admin functions as a regular user by directly calling privileged API endpoints
+- **Missing function-level access control**: API endpoints that exist but lack any permission check at all
+
+The 2019 Capital One breach exploited a misconfigured IAM role that had overly broad S3 access permissions, exposing 106 million customer records.
+The 2021 Parler data scrape was possible because the API lacked authorization checks on content enumeration -- sequential IDs with no ownership verification allowed downloading every post.
+The 2023 Microsoft Power Platform vulnerability exposed customer data because an API endpoint checked authentication (is the user logged in?) but not authorization (does the user have permission to access this specific tenant's data?).
+
+A well-designed RBAC system with enforced resource-level checks eliminates these attack classes by ensuring that every operation is checked against both the user's permissions (what operations can they perform?) and the resource's ownership (do they have access to this specific resource?).
+
+## Instructions
+
+1. **Start with the permission model, not the roles.**
+   Identify the resources in your system (users, orders, projects, documents, invoices, reports) and the operations that can be performed on them (create, read, update, delete, approve, publish, export, archive).
+   Define permissions as `resource:operation` pairs:
+   - `orders:read`, `orders:create`, `orders:approve`
+   - `users:manage`, `users:read`
+   - `reports:export`, `reports:create`
+
+   Be granular enough to enforce least privilege (separating `orders:read` from `orders:approve` prevents a viewer from approving orders) but not so granular that the model becomes unmanageable (do not create separate permissions for every field of every resource).
+
+2. **Define roles as named collections of permissions.**
+   A role is a set of permissions that corresponds to a job function.
+   Common starter roles for a business application:
+   - `viewer`: Read-only access to relevant resources (`orders:read`, `reports:read`)
+   - `editor`: Read and write access (`orders:read`, `orders:create`, `orders:update`)
+   - `manager`: Editor permissions plus approval capabilities (`orders:approve`, `users:read`)
+   - `admin`: Full access to the application's resources (`users:manage`, `settings:update`, plus all lower permissions)
+   - `owner`: Admin plus billing, subscription, and organization-level settings
+
+   Permission checks evaluate: "Does the union of the user's assigned roles include the required permission for this operation?"
+
+3. **Apply the principle of least privilege rigorously.**
+   Every user, service account, API key, and automated process should have the minimum permissions required for its current function -- nothing more.
+   Default to no access and grant permissions explicitly through role assignment.
+
+   When an employee changes roles, revoke the old role and assign the new one; do not accumulate roles.
+   Review role assignments quarterly and after every organizational change.
+   Dormant accounts (no login in 90 days) should be flagged for review and potential deactivation.
+
+4. **Implement role hierarchies with explicit documentation.**
+   Role inheritance (admin inherits all manager permissions, manager inherits all editor permissions, editor inherits all viewer permissions) reduces duplication and simplifies assignment.
+
+   However, hierarchies create implicit permissions that are difficult to audit -- when an admin inherits from a chain of four roles, the effective permission set is not immediately visible.
+   Mitigate this by:
+   - Documenting the inheritance chain explicitly in code or configuration
+   - Providing a tool or API that "expands" a role to show its complete effective permission set
+   - Writing tests that assert the exact permission set for each role
+
+5. **Add resource-level checks (object-level authorization).**
+   RBAC roles alone answer the question "Can this user perform this operation type?" but not "Can this user perform this operation on this specific resource?"
+   A user with `orders:read` permission must only be able to read orders that belong to them or their organization, not all orders in the system.
+
+   Implement ownership checks on every data access:
+
+   ```
+   user.hasPermission('orders:read') AND order.belongsTo(user.organization)
+   ```
+
+   This prevents IDOR vulnerabilities, which are the most common authorization flaw in web applications.
+   The permission check and the ownership check are both mandatory -- neither alone is sufficient.
+
+6. **Enforce authorization at the API layer, not the UI layer.**
+   Hiding a button in the frontend is a UX decision, not a security control.
+   Every API endpoint must independently verify that the authenticated user has the required permission for the requested operation on the requested resource.
+
+   Assume that attackers will call your API directly using curl, Postman, or custom scripts -- they will never see your UI restrictions.
+   UI visibility should mirror the permission model (do not show buttons the user cannot use) but the UI must never be the only enforcement mechanism.
+
+7. **Scope roles to tenants in multi-tenant systems.**
+   In SaaS applications, a user may be an `admin` in Organization A but a `viewer` in Organization B.
+   Model this with role assignments that include a tenant scope: `(user_id, role_id, tenant_id)` triples.
+
+   Permission checks must include the tenant context:
+
+   ```
+   user.hasRole('admin', currentOrganization)
+   ```
+
+   Never allow a role in one tenant to grant access to resources in another tenant.
+   Tenant isolation is a hard boundary -- cross-tenant access is a critical vulnerability, not a feature.
+
+## Details
+
+### RBAC Variants (NIST Model)
+
+The NIST RBAC standard (INCITS 359-2012) defines four levels of increasing sophistication:
+
+- **RBAC0 (Core RBAC)**: Flat roles with no hierarchy. Users are assigned roles; roles contain permissions. Simple and sufficient for applications with few roles and clear separation.
+- **RBAC1 (Hierarchical RBAC)**: Roles form an inheritance hierarchy. Senior roles inherit all permissions of junior roles. Reduces duplication but requires careful design to avoid unintended permission accumulation.
+- **RBAC2 (Constrained RBAC)**: Adds constraints such as separation of duty (a user cannot hold both "requester" and "approver" roles), cardinality constraints (maximum N users per role), and prerequisite constraints (must hold role A before being assigned role B).
+- **RBAC3 (Symmetric RBAC)**: Combines RBAC1 and RBAC2 -- hierarchical roles with constraints.
+
+Most production applications need RBAC1 with selective RBAC2 constraints for sensitive operations (financial approvals, user administration, data deletion).
+
+### The Role Explosion Problem
+
+As features and teams grow, organizations create new roles for every combination of permissions: `marketing-editor`, `marketing-viewer`, `sales-editor`, `sales-viewer`, `marketing-sales-editor`, `marketing-admin-except-delete`.
+This combinatorial explosion makes the role model unmanageable, unauditable, and error-prone.
+
+Solutions to role explosion:
+
+- **Permission groups with additive grants**: Assign users a base role plus individual permission grants for exceptions. Instead of creating `marketing-editor-with-export`, assign the `editor` role plus the `reports:export` permission directly.
+- **Scoped roles**: Instead of creating department-specific roles, create generic roles (`editor`, `viewer`) that are scoped to a context (module, department, project). The role definition is reusable; the scope limits its application.
+- **Switch to ABAC for complex rules**: When role proliferation is driven by attribute-based decisions (department, region, time of day, data classification), the problem space has outgrown RBAC. ABAC policies express these decisions naturally.
+- **Regular role pruning**: Audit roles quarterly. Identify roles with zero assignments, roles with identical permission sets (merge them), and roles that differ by a single permission (consider additive grants instead).
+
+### Separation of Duty
+
+Critical operations should require two distinct roles held by two distinct users.
+Example: the person who creates a payment (role: `payment-creator`) must not be the same person who approves it (role: `payment-approver`).
+
+Two implementation approaches:
+
+- **Static separation of duty**: A user cannot be assigned both conflicting roles simultaneously. Enforced at role assignment time.
+- **Dynamic separation of duty**: A user who created a specific payment cannot approve that same payment, even if they hold both roles in general. Enforced at operation time. More flexible but harder to implement.
+
+### When to Choose ABAC Over RBAC
+
+RBAC is sufficient when authorization decisions depend primarily on who the user is and what their job function is.
+
+ABAC (Attribute-Based Access Control) is needed when decisions depend on multiple attributes:
+
+- **Resource attributes**: classification level, owner, creation date, geographic region
+- **User attributes**: department, clearance level, employment status, location
+- **Environment attributes**: time of day, IP address, device posture, risk score
+
+The diagnostic signal for needing ABAC: if you find yourself creating roles that encode attribute combinations (e.g., `us-east-daytime-senior-analyst`), you are encoding policy in role names.
+Switch to ABAC and express the policy as rules over attributes.
+
+### When to Choose ReBAC Over RBAC
+
+ReBAC (Relationship-Based Access Control) models authorization as relationships in a graph.
+Instead of assigning roles, you define relationships: "User X is an editor of Document Y," "Team A owns Project B," "Organization C is the parent of Team A."
+
+ReBAC is appropriate when:
+
+- Access depends on the relationship between the user and the specific resource (not just the user's role)
+- Resources have complex ownership hierarchies (organizations contain teams, teams own projects, projects contain documents)
+- You need to answer questions like "Who can access this specific document?" efficiently
+
+Systems like Google Zanzibar (and its open-source implementations: SpiceDB, OpenFGA) implement ReBAC with global consistency and low-latency evaluation.
+
+### Authorization Middleware Patterns
+
+Implement authorization as middleware or decorators that execute before the business logic:
+
+- **Express.js**: `app.get('/orders/:id', authorize('orders:read'), checkOwnership, handler)`
+- **Django**: `@permission_required('orders.view_order')` decorator plus object-level check in the view
+- **Spring**: `@PreAuthorize("hasPermission(#id, 'Order', 'read')")` annotation with a custom PermissionEvaluator
+- **Go**: Middleware function that extracts the user from context, checks the permission, and returns 403 if denied
+
+The authorization check must happen on every request, at the framework level, before any business logic executes.
+
+## Anti-Patterns
+
+1. **The "god role" with all permissions and no audit trail.**
+   A single `super-admin` or `root` role that bypasses all permission checks entirely.
+   If this role's credentials are compromised, the attacker has unlimited, unlogged access to every resource.
+   Instead: even the highest-privilege role should be subject to permission checks and full audit logging.
+   Administrative actions should require MFA step-up authentication.
+
+2. **Permission checks only in the UI.**
+   Hiding buttons and menu items in the frontend without corresponding server-side checks.
+   Attackers use API clients (curl, Postman, custom scripts) and never see the UI.
+   Every API endpoint must independently verify authorization.
+
+3. **Hardcoded role names in business logic.**
+   Code like `if (user.role === 'admin')` scattered throughout the codebase.
+   This couples the authorization model to the codebase, making role changes and additions extremely fragile.
+   Check permissions, not role names: `if (user.hasPermission('orders:approve'))`.
+   This allows role definitions to evolve without code changes.
+
+4. **No resource-level checks (IDOR vulnerability).**
+   Verifying `user.hasRole('editor')` but not verifying that the user has access to the specific resource being edited.
+   This enables horizontal privilege escalation: User A edits User B's order by changing the order ID in the API request.
+   The role check passes (User A is an editor), but the ownership check is missing.
+
+5. **Roles that only grow, never shrink.**
+   Over time, roles accumulate permissions as features are added, but permissions are never removed when features are deprecated or projects end.
+   This violates least privilege through entropy.
+   Audit roles quarterly: review every permission in every role, remove permissions that are no longer needed, and document the rationale for each permission that remains.
+
+6. **Implicit deny not enforced as default.**
+   Authorization systems that default to "allow" when no rule matches, rather than defaulting to "deny."
+   The safe default is always deny -- if there is no explicit permission grant, access is denied.
+   This prevents new endpoints or resources from being accidentally accessible before permission rules are written.
+
+7. **No audit logging of authorization decisions.**
+   Authorization decisions (both grants and denials) must be logged with the user identity, the requested resource, the requested operation, the decision (allow/deny), and the reason (which permission or lack thereof).
+   Without audit logs, detecting privilege escalation, investigating breaches, and demonstrating compliance are impossible.

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

@@ -0,0 +1,40 @@
+name: security-rbac-design
+version: "1.0.0"
+description: Role-based access control modeling -- role hierarchies, permission granularity, role explosion prevention, and the principle of least privilege
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-abac-design
+  - security-rebac-design
+  - security-capability-based-security
+  - security-zero-trust-principles
+  - owasp-auth-patterns
+  - owasp-idor-prevention
+stack_signals: []
+keywords:
+  - RBAC
+  - role-based access control
+  - roles
+  - permissions
+  - authorization
+  - least privilege
+  - role hierarchy
+  - role explosion
+  - access control matrix
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []