codejury 0.17.1__tar.gz → 0.18.0__tar.gz

codejury-0.18.0/PKG-INFO

@@ -0,0 +1,147 @@
+Metadata-Version: 2.4
+Name: codejury
+Version: 0.18.0
+Summary: AI code security review: an adversarial diff-audit engine and an agent-driven whole-repo review methodology, with security knowledge as rich rules
+Author: AISecLabs
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/aiseclabs/codejury
+Project-URL: Repository, https://github.com/aiseclabs/codejury
+Keywords: security,appsec,static analysis,llm,owasp,asvs,code review
+Classifier: Development Status :: 4 - Beta
+Classifier: Intended Audience :: Developers
+Classifier: Topic :: Security
+Classifier: Topic :: Software Development :: Quality Assurance
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Operating System :: OS Independent
+Requires-Python: >=3.12
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: json-repair>=0.30
+Provides-Extra: anthropic
+Requires-Dist: anthropic>=0.40; extra == "anthropic"
+Provides-Extra: openai
+Requires-Dist: openai>=1.0; extra == "openai"
+Provides-Extra: litellm
+Requires-Dist: litellm>=1.0; extra == "litellm"
+Provides-Extra: dev
+Requires-Dist: pytest>=8.0; extra == "dev"
+Requires-Dist: jsonschema>=4.0; extra == "dev"
+Dynamic: license-file
+
+```
+ ██████╗ ██████╗ ██████╗ ███████╗     ██╗██╗   ██╗██████╗ ██╗   ██╗
+██╔════╝██╔═══██╗██╔══██╗██╔════╝     ██║██║   ██║██╔══██╗╚██╗ ██╔╝
+██║     ██║   ██║██║  ██║█████╗       ██║██║   ██║██████╔╝ ╚████╔╝
+██║     ██║   ██║██║  ██║██╔══╝  ██   ██║██║   ██║██╔══██╗  ╚██╔╝
+╚██████╗╚██████╔╝██████╔╝███████╗╚█████╔╝╚██████╔╝██║  ██║   ██║
+ ╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚════╝  ╚═════╝ ╚═╝  ╚═╝   ╚═╝
+```
+
+> AI code security review for diffs and whole repositories.
+
+It runs two paths matched to their nature.
+
+- **Diff Review** is coded. It audits a pull request diff for newly introduced
+  exploitable risk, as a single balanced LLM call or an adversarial Finder,
+  Challenger, and Judge pass that trades roughly 3x the cost for extra recall on
+  subtle flaws that span files.
+- **Repo Review** is agent driven. It is a methodology an interactive agent such
+  as Claude Code or Codex runs to map a codebase attack surface, trace inputs to
+  sinks across files, verify issues with a real PoC, and iterate over rounds with
+  a persistent memory. A whole repository is too large for one LLM call, so it
+  ships the methodology and scaffolds the workspace instead of running a
+  pipeline.
+
+Security knowledge lives in rich vulnerability classes under `codejury/data/vulnerabilities/*.md`, with a
+vulnerable and a secure example per language, injected into the audit prompt
+rather than buried in code.
+
+## Install
+
+```bash
+pip install codejury                 # core
+pip install "codejury[anthropic]"    # add a backend, also openai or litellm
+```
+
+## Diff Review
+
+```bash
+# audit a diff file
+codejury review diff --diff-file changes.diff
+
+# audit a git range in a repo
+codejury review diff --repo /path/to/app --git-range origin/main...HEAD
+
+# from stdin
+git diff HEAD~1 | codejury review diff
+
+# adversarial mode, more recall on subtle flaws, about 3x the cost
+codejury review diff --diff-file changes.diff --mode adversarial
+
+# CI gate and SARIF
+codejury review diff --diff-file changes.diff --format sarif --fail-on high
+```
+
+Configure a backend with `--provider`, `--model`, `--api-key`, `--api-base`, or
+the `CODEJURY_API_KEY`, `CODEJURY_MODEL`, and `CODEJURY_API_BASE` environment
+variables. `codejury review diff --dry-run` exercises the engine with a mock
+provider and no key, and falls back to a built in demo diff when you pass none.
+
+### Choosing a Model and Mode
+
+Detection quality is dominated by the model first, then the mode. On real diff
+probes:
+
+- A strong model at the Claude Sonnet tier in standard mode caught every planted
+  vulnerability with almost no false positives. A weaker model raised false
+  positives in both modes, so the model is the lever that matters most.
+- Adversarial mode did not lower false positives over standard on those probes
+  and costs about 3x. Reach for it to gain recall on subtle logic that spans
+  files, not as a way to cut false positives.
+
+Default to standard mode with a strong model, set with `--model` or
+`CODEJURY_MODEL`. False positives are held down by the do not report list and the
+post filter, not by the mode.
+
+### Use in CI with GitHub Actions
+
+Audit every pull request and surface findings in the code scanning tab. Copy
+`examples/codejury-pr-review.yml` into `.github/workflows/`, add a
+`CODEJURY_API_KEY` repository secret, and it will
+
+1. diff the pull request against its base with `--git-range origin/<base>...HEAD`,
+2. write SARIF and upload it with `github/codeql-action/upload-sarif`,
+3. fail the check on a HIGH or CRITICAL finding with `--fail-on high`.
+
+The job makes one model call per pull request in standard mode. The SARIF is
+uploaded even when the gate fails, so findings always show up on the pull
+request.
+
+## Repo Review
+
+```bash
+codejury review repo /path/to/your/repo
+```
+
+This scaffolds a review workspace with `entrypoints/`, `issues/`, `analysis/`,
+and a `security-review-memory.md`, seeds the entrypoint inventory from a
+deterministic scan, and prints the methodology. Run it with an interactive agent.
+It reads the methodology and the vulnerability classes, maps the attack surface, traces inputs to
+sinks across files, records high confidence issues with a PoC, and asks you to
+confirm credentials or false positives along the way. Nothing runs against
+production.
+
+## Findings
+
+Each finding carries a file and line, a severity and category, a concrete exploit
+scenario, a recommendation, and a confidence. A false positive filter drops test
+paths, mock paths, and low confidence noise. The model is also told not to report
+dependency CVEs, style notes, speculation, or risks that only matter when
+production config leaks.
+
+## Extending
+
+Add a vulnerability class by dropping a new file `codejury/data/vulnerabilities/<class>.md`
+with the standard frontmatter of title, impact, tags, and triggers plus a
+vulnerable and a secure example. It is data, no code change needed.

codejury-0.18.0/README.md

@@ -0,0 +1,116 @@
+```
+ ██████╗ ██████╗ ██████╗ ███████╗     ██╗██╗   ██╗██████╗ ██╗   ██╗
+██╔════╝██╔═══██╗██╔══██╗██╔════╝     ██║██║   ██║██╔══██╗╚██╗ ██╔╝
+██║     ██║   ██║██║  ██║█████╗       ██║██║   ██║██████╔╝ ╚████╔╝
+██║     ██║   ██║██║  ██║██╔══╝  ██   ██║██║   ██║██╔══██╗  ╚██╔╝
+╚██████╗╚██████╔╝██████╔╝███████╗╚█████╔╝╚██████╔╝██║  ██║   ██║
+ ╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚════╝  ╚═════╝ ╚═╝  ╚═╝   ╚═╝
+```
+
+> AI code security review for diffs and whole repositories.
+
+It runs two paths matched to their nature.
+
+- **Diff Review** is coded. It audits a pull request diff for newly introduced
+  exploitable risk, as a single balanced LLM call or an adversarial Finder,
+  Challenger, and Judge pass that trades roughly 3x the cost for extra recall on
+  subtle flaws that span files.
+- **Repo Review** is agent driven. It is a methodology an interactive agent such
+  as Claude Code or Codex runs to map a codebase attack surface, trace inputs to
+  sinks across files, verify issues with a real PoC, and iterate over rounds with
+  a persistent memory. A whole repository is too large for one LLM call, so it
+  ships the methodology and scaffolds the workspace instead of running a
+  pipeline.
+
+Security knowledge lives in rich vulnerability classes under `codejury/data/vulnerabilities/*.md`, with a
+vulnerable and a secure example per language, injected into the audit prompt
+rather than buried in code.
+
+## Install
+
+```bash
+pip install codejury                 # core
+pip install "codejury[anthropic]"    # add a backend, also openai or litellm
+```
+
+## Diff Review
+
+```bash
+# audit a diff file
+codejury review diff --diff-file changes.diff
+
+# audit a git range in a repo
+codejury review diff --repo /path/to/app --git-range origin/main...HEAD
+
+# from stdin
+git diff HEAD~1 | codejury review diff
+
+# adversarial mode, more recall on subtle flaws, about 3x the cost
+codejury review diff --diff-file changes.diff --mode adversarial
+
+# CI gate and SARIF
+codejury review diff --diff-file changes.diff --format sarif --fail-on high
+```
+
+Configure a backend with `--provider`, `--model`, `--api-key`, `--api-base`, or
+the `CODEJURY_API_KEY`, `CODEJURY_MODEL`, and `CODEJURY_API_BASE` environment
+variables. `codejury review diff --dry-run` exercises the engine with a mock
+provider and no key, and falls back to a built in demo diff when you pass none.
+
+### Choosing a Model and Mode
+
+Detection quality is dominated by the model first, then the mode. On real diff
+probes:
+
+- A strong model at the Claude Sonnet tier in standard mode caught every planted
+  vulnerability with almost no false positives. A weaker model raised false
+  positives in both modes, so the model is the lever that matters most.
+- Adversarial mode did not lower false positives over standard on those probes
+  and costs about 3x. Reach for it to gain recall on subtle logic that spans
+  files, not as a way to cut false positives.
+
+Default to standard mode with a strong model, set with `--model` or
+`CODEJURY_MODEL`. False positives are held down by the do not report list and the
+post filter, not by the mode.
+
+### Use in CI with GitHub Actions
+
+Audit every pull request and surface findings in the code scanning tab. Copy
+`examples/codejury-pr-review.yml` into `.github/workflows/`, add a
+`CODEJURY_API_KEY` repository secret, and it will
+
+1. diff the pull request against its base with `--git-range origin/<base>...HEAD`,
+2. write SARIF and upload it with `github/codeql-action/upload-sarif`,
+3. fail the check on a HIGH or CRITICAL finding with `--fail-on high`.
+
+The job makes one model call per pull request in standard mode. The SARIF is
+uploaded even when the gate fails, so findings always show up on the pull
+request.
+
+## Repo Review
+
+```bash
+codejury review repo /path/to/your/repo
+```
+
+This scaffolds a review workspace with `entrypoints/`, `issues/`, `analysis/`,
+and a `security-review-memory.md`, seeds the entrypoint inventory from a
+deterministic scan, and prints the methodology. Run it with an interactive agent.
+It reads the methodology and the vulnerability classes, maps the attack surface, traces inputs to
+sinks across files, records high confidence issues with a PoC, and asks you to
+confirm credentials or false positives along the way. Nothing runs against
+production.
+
+## Findings
+
+Each finding carries a file and line, a severity and category, a concrete exploit
+scenario, a recommendation, and a confidence. A false positive filter drops test
+paths, mock paths, and low confidence noise. The model is also told not to report
+dependency CVEs, style notes, speculation, or risks that only matter when
+production config leaks.
+
+## Extending
+
+Add a vulnerability class by dropping a new file `codejury/data/vulnerabilities/<class>.md`
+with the standard frontmatter of title, impact, tags, and triggers plus a
+vulnerable and a secure example. It is data, no code change needed.

{codejury-0.17.1 → codejury-0.18.0}/codejury/__init__.py

@@ -1,9 +1,10 @@
-"""codejury: an AI code security review tool.
+"""AI code security review tool.
 
 Two paths matched to their nature: a coded diff-audit engine (standard single
 call or adversarial Finder/Challenger/Judge), and a whole-repo review run as a
 methodology by an interactive agent. Security knowledge lives in rich markdown
-rules (data/rules) injected into the audit prompt, not in a rendered schema.
+vulnerability classes (data/vulnerabilities) injected into the audit prompt, not
+in a rendered schema.
 """
 
 from importlib.metadata import PackageNotFoundError, version

{codejury-0.17.1 → codejury-0.18.0}/codejury/cli.py

@@ -1,4 +1,4 @@
-"""codejury CLI: thin argument parsing and dispatch.
+"""Command line interface: thin argument parsing and dispatch.
 
 Two paths matched to their nature:
 

codejury-0.18.0/codejury/data/frameworks/python/celery.md

@@ -0,0 +1,36 @@
+---
+id: celery
+title: Celery
+kind: framework
+language: python
+detect:
+  imports: ["celery", "shared_task"]
+entrypoint_files: ["*tasks.py", "*/tasks/*.py"]
+entrypoint_markers: ["@shared_task", "@app.task", "@celery_app.task", "@periodic_task", ".delay(", ".apply_async(", "crontab("]
+---
+# Celery Review Notes
+
+A task is an entrypoint, not just glue. Its arguments are attacker-influenced
+whenever the enqueue site passes request input through, so review a task the same
+way as an HTTP handler. The web view that calls `.delay()` or `.apply_async()` is
+the producer, and the task body is where the value lands.
+
+## Entrypoints
+- Task definitions in `tasks.py` or a `tasks/` package, marked by `@shared_task`,
+  `@app.task`, or `@celery_app.task`. Periodic tasks wired by `crontab()` or a
+  beat schedule run with no caller, so their inputs are config or stored state.
+- Trace each task back to its `.delay(...)` and `.apply_async(...)` callers to see
+  which arguments are user-controlled.
+
+## What to Hunt
+- A task that fetches a URL, runs a command, opens a file path, or renders a
+  template from an argument, the same sink classes as a web handler, now reached
+  off the request cycle.
+- Authorization re-check. A producer that checked the caller does not carry that
+  identity into the task, so a task that acts on a resource by an id in its
+  arguments needs its own owner or tenant check.
+- Secret and token exposure. A task that logs full request headers, a response
+  body, or a fetched credential leaks it into worker logs. See the
+  information-exposure vulnerability class.
+- Replayable or duplicate enqueue. A task with a side effect that is enqueued from
+  an unauthenticated or replayable producer runs more than once.

{codejury-0.17.1/codejury/data/frameworks → codejury-0.18.0/codejury/data/frameworks/python}/django.md

@@ -2,13 +2,15 @@
 id: django
 title: Django
 kind: framework
+language: python
 detect:
   files: ["*urls.py", "manage.py", "*settings.py"]
   manifest: ["django"]
   imports: ["from django", "import django"]
-entrypoint_files: ["*urls.py"]
+entrypoint_files: ["*urls.py", "*views.py", "*viewsets.py", "*/views/*.py", "*serializers.py", "*api.py", "*consumers.py"]
+entrypoint_markers: ["APIView", "ViewSet", "@api_view", "@action", "router.register", "path(", "re_path(", "as_view("]
 ---
-# Django review notes
+# Django Review Notes
 
 ## Entrypoints
 - Routes live in `urls.py`: `path()` / `re_path()` map a URL to a view.
@@ -18,14 +20,14 @@ entrypoint_files: ["*urls.py"]
   signals, and middleware.
 
 ## Authorization / IDOR
-- Auth is enforced by decorators (`@login_required`), DRF permission classes, or
+- Auth is enforced by decorators such as `@login_required`, DRF permission classes, or
   middleware. Note where it is and where it is missing.
-- Classic IDOR shape: `Model.objects.get(pk=<user input>)` (or `filter(id=...)`)
+- Classic IDOR shape: `Model.objects.get(pk=<user input>)` or `filter(id=...)`
   with no owner/tenant scoping, then returned to the caller. Inspect every object
   fetch keyed by a user-supplied id.
 
-## Common sinks / gotchas
+## Common Sinks / Gotchas
 - SQL: `.raw()`, `.extra()`, `RawSQL`, or string-built SQL via `connection.cursor()`.
 - Templates: `mark_safe`, `|safe`, `format_html` on unescaped user input, autoescape off.
-- `pickle` / `yaml.load` on a cookie or upload, `DEBUG=True` leaking internals,
-  a hardcoded `SECRET_KEY`.
+- Settings: `DEBUG=True` leaks internals, a hardcoded `SECRET_KEY`. Untrusted
+  deserialization is a language-level sink, see the Python guide.

{codejury-0.17.1 → codejury-0.18.0}/codejury/data/languages/python.md

@@ -7,17 +7,17 @@ detect:
   manifest: []
   imports: []
 ---
-# Python review notes
+# Python Review Notes
 
-Where untrusted input enters (beyond web routes, which the framework guide covers):
-CLI (`argparse`/`click`), scheduled jobs, queue consumers, and any function fed an
+Where untrusted input enters beyond web routes, which the framework guide covers:
+CLI such as `argparse` or `click`, scheduled jobs, queue consumers, and any function fed an
 external value. Non-HTTP sources matter as much as routes:
 
 - deserialization: `pickle.loads`, `yaml.load` without `SafeLoader`, `marshal`
 - code execution: `eval`, `exec`, `subprocess(..., shell=True)`, `os.system`
 - XML/XXE: `lxml`/`xml.etree` parsing attacker XML
 - filesystem: `open()` / `os.path.join` on a path built from user input
-- network: `requests.get(user_url)` and friends (SSRF).
+- network: `requests.get(user_url)` and similar, the SSRF sink.
 
 Common sinks: string-built SQL handed to a DB cursor or ORM `.raw()`/`.extra()`,
 a shell command, `eval`/`exec`, a user-controlled file path, a fetch of a

{codejury-0.17.1/codejury/data/methodology → codejury-0.18.0/codejury/data/methodologies}/repo-review.md

@@ -7,47 +7,54 @@ PoC, and iterates over multiple rounds with a persistent memory. One round is
 roughly 30 minutes. Run as many rounds as needed.
 
 Target repository: the directory you were given.
-Workspace: `<workspace>/<project>/` (created for you), holding `entrypoints/`,
+Workspace: `<workspace>/<project>/`, created for you, holding `entrypoints/`,
 `issues/`, `analysis/`, and `security-review-memory.md`.
 
 ---
 
-## On start
+## On Start
 
 1. Read `security-review-memory.md` in the workspace if it exists:
    - skip every pattern under "Confirmed false positives".
    - do not re-report anything under "Fixed".
    - weight the files under "High-risk areas" more heavily.
-2. Read `entrypoints/_entrypoints.md` (seeded): the files the detected stack
+2. Read `entrypoints/_entrypoints.md`, the seeded list of files the detected stack
    flags as likely to define entrypoints. Open them to find the actual
-   entrypoints. It is a *starting* subset, not the whole surface (see "Map the
-   attack surface").
-3. Read `_stack.md` (seeded): the detected languages and frameworks and review
-   notes for them, so you know where this stack's entrypoints, sinks, and auth
-   checks live. If it matched nothing, lean on your own knowledge of the stack.
-4. Read the relevant rule files under the shipped `rules/` for the target's stack
-   (sql-injection, idor, ssrf, authentication-jwt, insecure-deserialization, ...).
-
-## Map the attack surface
-
-The seeded inventory lists HTTP routes and CLI commands only. Before analysing,
-complete the surface: untrusted input enters at more than HTTP. Enumerate every
-source the attacker can influence and add it to `entrypoints/`:
+   entrypoints. It is a *starting* subset, not the whole surface. See "Map the
+   attack surface".
+3. Read `_stack.md`, the seeded detected languages, frameworks, and protocols plus
+   review notes for them, so you know where this stack's entrypoints and sinks
+   live and which protocol checks apply, for example the OAuth checklist. If it
+   matched nothing, lean on your own knowledge of the stack.
+4. Read the relevant vulnerability files under the shipped `vulnerabilities/` for
+   the target's stack such as sql-injection, idor, ssrf, jwt-validation, or
+   insecure-deserialization.
+
+## Map the Attack Surface
+
+The seeded `entrypoints/_entrypoints.md` flags files that likely define
+entrypoints. It is a starting point, not the whole surface. Before any per-source
+analysis, build a COMPLETE inventory: open every flagged file, read its routes
+and handlers, and enumerate every source the attacker can influence, including
+the ones no scan finds. Untrusted input enters at more than HTTP:
 
 - HTTP routes, GraphQL resolvers, gRPC / RPC handlers, WebSocket handlers.
 - CLI commands, scheduled jobs / cron, queue and topic consumers, webhooks and
   third-party callbacks.
-- deserialization points (pickle, yaml.load, marshal), file and document parsers
-  (XML / XXE, YAML, CSV, zip, image / office), template rendering of user input.
+- deserialization points such as pickle, yaml.load, or marshal, file and document parsers
+  for XML / XXE, YAML, CSV, zip, image / office, and template rendering of user input.
 - file uploads, archive extraction, and any filesystem path built from user input.
 - headers, cookies, environment, and config read as trusted, and inbound
   inter-service calls.
 
 `pickle.loads(cookie)` and `yaml.load(upload)` are entrypoints just as much as a
-route is. Record the inventory in `entrypoints/` (one file per module: source +
-auth method + review status ✅/⚠️/❌).
+route is. Record the full inventory in `entrypoints/`, one file per module, each
+listing the source, the auth method, and a review status ✅/⚠️/❌. Do not begin
+per-source analysis until the inventory covers every endpoint, since an endpoint
+you never list is one you never review. This single step is what most decides
+whether the review finds the deep issues.
 
-## Analyse each source
+## Analyse Each Source
 
 Read the implementation reachable from each source. For every one ask:
 
@@ -56,22 +63,43 @@ Read the implementation reachable from each source. For every one ask:
   a business-state check bypassed or missing?
 - IDOR: can a user reach another user's, tenant's, or service's resource by a
   supplied id?
-- Do privileged operations (payment, signing, approval, state change) allow state
-  bypass or replay (no nonce / time window)?
+- Do privileged operations such as payment, signing, approval, or state change allow state
+  bypass or replay with no nonce or time window?
 - Mass assignment: is a user-controlled body bound wholesale into a model?
 - Signature: is a caller-supplied key trusted as the trust anchor?
 
-## Trace attack paths, the core work
+## Authorization Model
+
+The missing-authorization and IDOR classes are not local to one function, so they
+need their own pass. This step is language and framework agnostic. The access
+gate looks different per stack, a decorator, a middleware, a permission class, a
+filter, a guard, or an annotation, but every protected endpoint must authenticate
+the caller and authorize the specific resource.
+
+First map how this codebase enforces access control, then record on each
+inventory entry which gate it applies and which identity and resource it checks.
+Then hunt three shapes:
+
+- A peer that dropped a check. Compare sibling endpoints such as a v1 and a v2, a
+  batch and a single, or an admin and a public variant. When one applies an
+  ownership or permission check that a sibling omits, the sibling is a likely
+  flaw.
+- IDOR. An endpoint acts on a resource named by a client-supplied id with no
+  owner or tenant check, however the id arrives.
+- An unauthenticated privileged path. A state-changing or sensitive endpoint is
+  reachable without the gate its peers require.
+
+## Trace Attack Paths, the Core Work
 
 A whole-repo review earns its keep by reasoning *across files*: a flaw is usually
 a source in one file reaching a dangerous sink in another, past a control defined
-in a third (a route that trusts a helper which skips signature checks, an id that
-reaches a query with no ownership check). For each promising source, trace the
+in a third, for example a route that trusts a helper which skips signature checks, or an id that
+reaches a query with no ownership check. For each promising source, trace the
 path and record it in `analysis/`:
 
 - **Source**: the entrypoint and the attacker-controlled value.
-- **Sink**: the dangerous operation it reaches (query, shell, file path, fetch,
-  deserialize, template, redirect), with `file:line`.
+- **Sink**: the dangerous operation it reaches such as a query, shell, file path, fetch,
+  deserialize, template, or redirect, with `file:line`.
 - **Controls on the path**: every auth / authz / validation / sanitization /
   signature / tenant check between source and sink, and crucially which are
   missing or bypassable.
@@ -83,11 +111,11 @@ trace can refer to it instead of restating it.
 ## Scope
 
 Report only HIGH / CRITICAL, exploitable, high-confidence issues. **Do not report**
-(regardless of severity): dependency CVEs, style or best-practice notes,
+regardless of severity, dependency CVEs, style or best-practice notes,
 speculative issues you cannot tie to a concrete exploit, and risks that only
 matter if production config is leaked.
 
-## Recording an issue
+## Recording an Issue
 
 Write one `issues/<name>.md` per confirmed issue. Do not write an issue you cannot
 confirm with high confidence. Each must have:
@@ -102,7 +130,7 @@ confirm with high confidence. Each must have:
 ## Analysis
 (cite exact file paths and line numbers)
 
-## Attack path
+## Attack Path
 (end-to-end, actionable steps)
 
 ## PoC
@@ -114,7 +142,7 @@ confirm with high confidence. Each must have:
 ## Fix
 ```
 
-## PoC verification (human in the loop)
+## PoC Verification, Human in the Loop
 
 Confirm each issue by running the PoC against a sandbox / dev environment. When
 you need something only the operator has, stop and ask:
@@ -129,11 +157,13 @@ destructive action without the operator's explicit go-ahead.
 ## Iteration
 
 Each round, read the workspace history first and do not repeat finished work.
-Process leftover TODOs, otherwise pick an unreviewed (❌) or to-deepen (⚠️)
-source from the inventory. When every source is ✅ and there are no TODOs,
-report the review complete.
+Process leftover TODOs, otherwise pick an unreviewed ❌ or to-deepen ⚠️ source
+from the inventory. One round rarely finds the deep cross-file and stateful bugs,
+so keep going until two consecutive rounds surface nothing new, then report the
+review complete. The hard classes such as authorization, replay, and broken
+business state usually appear only after several rounds.
 
-## On finish
+## On Finish
 
 Append a row to the audit history in `security-review-memory.md`, and ask the
 operator which findings were false positives. Record those under "Confirmed false

{codejury-0.17.1/codejury/data/methodology → codejury-0.18.0/codejury/data/methodologies}/security-review-memory.md

@@ -4,7 +4,7 @@
 > updated at the end. It skips confirmed false positives, avoids re-reporting
 > fixed issues, and focuses on historically risky areas.
 
-## Confirmed false positives (skip, do not report)
+## Confirmed False Positives
 
 <!-- FP-001 <short description>
 - Date: YYYY-MM-DD
@@ -13,18 +13,18 @@
 - Why not a real issue: <reason>
 -->
 
-## Fixed (do not report again)
+## Fixed
 
 <!-- FIXED-001 <issue title>
 - Date / commit: YYYY-MM-DD / abc1234
 - Original issue: <summary>
 -->
 
-## High-risk areas (weight every round)
+## High-Risk Areas
 
 <!-- - `<path>`: <reason, for example a past auth bypass> -->
 
-## Audit history
+## Audit History
 
 | Date | Mode | HIGH | MEDIUM | Notes |
 |------|------|------|--------|-------|

codejury-0.18.0/codejury/data/protocols/oauth.md

@@ -0,0 +1,55 @@
+---
+id: oauth
+title: OAuth and OIDC
+kind: protocol
+detect:
+  content: ["grant_type", "authorization_code", "redirect_uri", "code_challenge", "response_type", "client_secret", "openid-configuration"]
+---
+# OAuth and OIDC Review Notes
+
+These are protocol invariants, independent of language or framework. The way each
+check looks in code differs by stack, so read the language and framework guides
+for the concrete idioms and confirm each invariant against the actual flow. An
+OAuth or OIDC server holds protocol state, so the high-value bugs are logic,
+authorization, and replay flaws rather than injection.
+
+## Authorization Code
+- Single use. The code is redeemable once. The redeem path reads and marks the
+  code consumed atomically, under a row lock or an equivalent conditional update,
+  so two concurrent requests cannot both succeed. A read then update with no lock
+  is a double-redeem.
+- Bound to the client. A code issued to one client is rejected when another
+  client presents it. The token step compares the code's client to the
+  authenticated client.
+- Bound to the redirect_uri and the PKCE verifier. Both at the token step match
+  what was used at authorize. A missing PKCE check on a public client is
+  exploitable.
+- Expiry enforced. An expired code is rejected. Confirm the expiry is read and
+  compared, not merely stored.
+
+## redirect_uri and State
+- redirect_uri is validated against a registered allowlist by exact match, not a
+  prefix or a substring, so an open redirect or a code leak is not possible.
+- A state or equivalent anti-forgery value is present and checked, to stop login
+  CSRF.
+
+## Tokens and Sessions
+- Access and refresh tokens are random, high entropy, scoped, and expiring.
+- Refresh rotates and the previous token is revoked, so a captured refresh cannot
+  be replayed.
+- A JWT access token has its signature, algorithm, issuer, audience, and expiry
+  verified. Disabling signature verification or allowing an unconstrained
+  algorithm is a flaw. See the jwt-validation vulnerability class.
+
+## Replay and Signatures
+- A signed or one-time request such as an MFA binding, a webhook, or a privileged
+  action carries a nonce or a short timestamp window and a single-use check, so a
+  captured request cannot be replayed. See the replay-attack vulnerability class.
+
+## Authorization per Endpoint
+- Every token, introspection, revocation, and management endpoint authenticates
+  the caller and authorizes the specific resource. Watch for an endpoint that
+  acts on a client-supplied id with no owner or tenant check, the IDOR shape, and
+  for a privileged endpoint left unauthenticated. See the
+  insecure-direct-object-reference and missing-authorization vulnerability classes,
+  and the Authorization Model step in the methodology.