apisec-code-bolt 0.1.8__tar.gz → 0.1.10__tar.gz

{apisec_code_bolt-0.1.8 → apisec_code_bolt-0.1.10}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: apisec-code-bolt
-Version: 0.1.8
+Version: 0.1.10
 Summary: Static analysis probe for extracting architectural metadata from codebases
 Project-URL: Homepage, https://apisec.ai
 Project-URL: Documentation, https://docs.apisec.ai/code-bolt
@@ -24,13 +24,16 @@ Requires-Dist: httpx>=0.26.0
 Requires-Dist: javalang>=0.13.0
 Requires-Dist: libcst>=1.1.0
 Requires-Dist: networkx>=3.2
+Requires-Dist: packaging>=23.0
 Requires-Dist: pathspec>=0.12.0
 Requires-Dist: pydantic-settings>=2.1.0
 Requires-Dist: pydantic>=2.5.0
 Requires-Dist: pyyaml>=6.0
 Requires-Dist: rich>=13.7.0
 Requires-Dist: tree-sitter-c-sharp>=0.23
+Requires-Dist: tree-sitter-java>=0.23
 Requires-Dist: tree-sitter-javascript>=0.23
+Requires-Dist: tree-sitter-python>=0.23
 Requires-Dist: tree-sitter-ruby>=0.23
 Requires-Dist: tree-sitter-typescript>=0.23
 Requires-Dist: tree-sitter>=0.23
@@ -199,6 +202,7 @@ analysis:
       - "tests/**"
       - "**/migrations/**"
     max_files: 10000
+    detect_workspace_boundaries: true  # see "Monorepo support" below
 
   data_flow:
     mode: inter_procedural
@@ -212,6 +216,59 @@ output:
   format: json
 ```
 
+## Monorepo support
+
+When a scanned tree contains multiple independently-deployed sub-projects
+(a pnpm/npm workspace, a Maven or Gradle multi-module build, a `.sln` with
+several `.csproj`s, a `go.work`, or a uv/Poetry workspace — or, absent any of
+those, any directory with its own recognised dependency manifest file),
+`analyze` automatically detects each one as a separate boundary and uploads
+its own manifest as its own Application, instead of one flat manifest mixing
+every sub-project's routes, dependencies, and secrets together.
+
+- **Activation is automatic and safe by default.** Detection only takes
+  effect when **2 or more** real boundaries are found; a single-project repo
+  is completely unaffected — same manifest, same canonical id, same
+  `state.yaml`. Disable it entirely with `--no-detect-monorepo` or
+  `detect_workspace_boundaries: false`.
+- **Identity.** Each sub-project uploads under
+  `{repo_canonical_id}/{relative/path/to/sub-project}`; code that doesn't
+  belong to any detected sub-project (root-level config, CI files, a shared
+  library with no manifest of its own) uploads under
+  `{repo_canonical_id}/shared`.
+- **Display name.** Each sub-project's Application is named
+  `{repo_name}/{relative/path/to/sub-project}` (and `{repo_name}/shared` for
+  the catch-all), so sibling services are distinguishable in the APIsec
+  console's Applications list instead of all showing up under the identical
+  bare repo name. A single-project repo is unaffected — same bare `repo_name`
+  as always.
+- **Auth-middleware scoping rides on the same gate — and this one is
+  security-material.** A globally-registered auth middleware is attributed
+  only to routes inside its own boundary, so one service's middleware can no
+  longer mark a sibling service's routes as authenticated (which hides
+  genuinely-exposed endpoints). Because it is gated on the same "2 or more
+  boundaries" condition, a polyglot repo that presents only a **single**
+  boundary — e.g. one root manifest and no per-service marker file or
+  workspace config — falls back to the legacy path and gets repo-wide
+  attribution. If a repo mixes languages or services, give each one its own
+  dependency manifest (or declare a workspace) so boundary detection can see
+  them; otherwise auth attribution is repo-wide and may over-report routes as
+  protected.
+  Scoping covers every auth path that resolves by *name* rather than by file:
+  Spring Security filter chains, Rails `before_action` (including
+  `ApplicationController`-inherited callbacks), Django view classes and
+  decorators, and route-level auth dependencies — so two services that each
+  define, say, an `articles` controller no longer share each other's guards.
+- **Known v1 limitations:**
+  - A response/request schema referenced by routes in more than one
+    sub-project is duplicated into each of them; only one level of nested
+    model references is followed.
+  - The `shared` partition does not get the LLM-based surface-enrichment
+    pass (it has no single directory to scope that scan to).
+  - A cross-partition reference (e.g. a route depending on an auth guard
+    defined in another sub-project) is preserved as-is and surfaced as a
+    warning in that partition's manifest, not silently dropped or rewritten.
+
 ## Commands
 
 Global options (before the subcommand): `--version`, `-v/--verbose`,
@@ -227,10 +284,8 @@ apisec-code-bolt analyze [PATH] [OPTIONS]
 Options:
   -o, --output FILE     Save manifest to file instead of uploading
   --no-upload           Skip uploading to cloud (implies --output if not set)
-  --cloud-url TEXT      Reasoning engine URL (legacy direct connection, local dev)
   --api-key TEXT        Override stored API key
-  --api-url TEXT        Override stored API URL
-  --reasoning-url TEXT  Reasoning engine URL (if different from API URL)
+  --api-url TEXT        Applicationsservice base URL (all analysis traffic is proxied here)
   --format [json|yaml]  Output format
   --config FILE         Path to configuration file
   --frameworks TEXT     Comma-separated framework hints
@@ -239,6 +294,10 @@ Options:
   --timeout INTEGER     Analysis timeout in seconds
   --dry-run             Analyze and print a summary; write/upload nothing
   --stdout              Write manifest JSON to stdout (for pipelines)
+  --detect-monorepo / --no-detect-monorepo
+                        Detect monorepo sub-project boundaries and upload one
+                        Application per sub-project (default: on; see
+                        "Monorepo support" below)
 ```
 
 ### auth
@@ -349,6 +408,48 @@ ruff check .
 ruff format --check .
 ```
 
+### Publishing a release (maintainers)
+
+The CLI is published to [PyPI](https://pypi.org/project/apisec-code-bolt/) by the
+**Publish to PyPI** GitHub Action. **Merging to `build` does NOT publish** — the
+workflow only runs on `workflow_dispatch` or a published GitHub Release, and it
+builds from whatever ref it runs on.
+
+Prerequisites (one-time): the `PYPI_API_TOKEN` repository secret must be set
+(Settings → Secrets and variables → Actions).
+
+1. **Bump the version.** Edit `version` in `pyproject.toml` (single source of
+   truth; `--version` reads it via package metadata). PyPI **rejects re-uploads**
+   of an existing version, so the number must be higher than the current PyPI
+   release. Open a PR and merge it to `build`.
+
+2. **Publish** — dispatch the workflow (the standard path we use):
+   Actions → *Publish to PyPI* → **Run workflow** → select branch **`build`**.
+
+   ```bash
+   gh workflow run "Publish to PyPI" --ref build
+   ```
+
+   <details><summary>Alternative: publish via a GitHub Release</summary>
+
+   New release → create tag `vX.Y.Z` → set **Target: `build`** (it defaults to
+   the default branch; only `build` has the bumped version) → Publish. This
+   fires the same workflow via `release: [published]`.
+
+   ```bash
+   gh release create vX.Y.Z --target build --title "vX.Y.Z" --notes "…"
+   ```
+   </details>
+
+3. **Verify.** Confirm the new version appears on
+   [PyPI](https://pypi.org/project/apisec-code-bolt/), then upgrade an install:
+   ```bash
+   uv tool upgrade apisec-code-bolt   # or: pipx upgrade apisec-code-bolt
+   ```
+
+> Always release from `build` after the version bump has merged there — releasing
+> from a ref that still carries the old version will fail the PyPI upload.
+
 ## Privacy
 
 apisec-code-bolt is designed with privacy as a core principle:
@@ -361,3 +462,4 @@ apisec-code-bolt is designed with privacy as a core principle:
 ## License
 
 Proprietary. Copyright © APIsec.
+

{apisec_code_bolt-0.1.8 → apisec_code_bolt-0.1.10}/README.md

@@ -152,6 +152,7 @@ analysis:
       - "tests/**"
       - "**/migrations/**"
     max_files: 10000
+    detect_workspace_boundaries: true  # see "Monorepo support" below
 
   data_flow:
     mode: inter_procedural
@@ -165,6 +166,59 @@ output:
   format: json
 ```
 
+## Monorepo support
+
+When a scanned tree contains multiple independently-deployed sub-projects
+(a pnpm/npm workspace, a Maven or Gradle multi-module build, a `.sln` with
+several `.csproj`s, a `go.work`, or a uv/Poetry workspace — or, absent any of
+those, any directory with its own recognised dependency manifest file),
+`analyze` automatically detects each one as a separate boundary and uploads
+its own manifest as its own Application, instead of one flat manifest mixing
+every sub-project's routes, dependencies, and secrets together.
+
+- **Activation is automatic and safe by default.** Detection only takes
+  effect when **2 or more** real boundaries are found; a single-project repo
+  is completely unaffected — same manifest, same canonical id, same
+  `state.yaml`. Disable it entirely with `--no-detect-monorepo` or
+  `detect_workspace_boundaries: false`.
+- **Identity.** Each sub-project uploads under
+  `{repo_canonical_id}/{relative/path/to/sub-project}`; code that doesn't
+  belong to any detected sub-project (root-level config, CI files, a shared
+  library with no manifest of its own) uploads under
+  `{repo_canonical_id}/shared`.
+- **Display name.** Each sub-project's Application is named
+  `{repo_name}/{relative/path/to/sub-project}` (and `{repo_name}/shared` for
+  the catch-all), so sibling services are distinguishable in the APIsec
+  console's Applications list instead of all showing up under the identical
+  bare repo name. A single-project repo is unaffected — same bare `repo_name`
+  as always.
+- **Auth-middleware scoping rides on the same gate — and this one is
+  security-material.** A globally-registered auth middleware is attributed
+  only to routes inside its own boundary, so one service's middleware can no
+  longer mark a sibling service's routes as authenticated (which hides
+  genuinely-exposed endpoints). Because it is gated on the same "2 or more
+  boundaries" condition, a polyglot repo that presents only a **single**
+  boundary — e.g. one root manifest and no per-service marker file or
+  workspace config — falls back to the legacy path and gets repo-wide
+  attribution. If a repo mixes languages or services, give each one its own
+  dependency manifest (or declare a workspace) so boundary detection can see
+  them; otherwise auth attribution is repo-wide and may over-report routes as
+  protected.
+  Scoping covers every auth path that resolves by *name* rather than by file:
+  Spring Security filter chains, Rails `before_action` (including
+  `ApplicationController`-inherited callbacks), Django view classes and
+  decorators, and route-level auth dependencies — so two services that each
+  define, say, an `articles` controller no longer share each other's guards.
+- **Known v1 limitations:**
+  - A response/request schema referenced by routes in more than one
+    sub-project is duplicated into each of them; only one level of nested
+    model references is followed.
+  - The `shared` partition does not get the LLM-based surface-enrichment
+    pass (it has no single directory to scope that scan to).
+  - A cross-partition reference (e.g. a route depending on an auth guard
+    defined in another sub-project) is preserved as-is and surfaced as a
+    warning in that partition's manifest, not silently dropped or rewritten.
+
 ## Commands
 
 Global options (before the subcommand): `--version`, `-v/--verbose`,
@@ -180,10 +234,8 @@ apisec-code-bolt analyze [PATH] [OPTIONS]
 Options:
   -o, --output FILE     Save manifest to file instead of uploading
   --no-upload           Skip uploading to cloud (implies --output if not set)
-  --cloud-url TEXT      Reasoning engine URL (legacy direct connection, local dev)
   --api-key TEXT        Override stored API key
-  --api-url TEXT        Override stored API URL
-  --reasoning-url TEXT  Reasoning engine URL (if different from API URL)
+  --api-url TEXT        Applicationsservice base URL (all analysis traffic is proxied here)
   --format [json|yaml]  Output format
   --config FILE         Path to configuration file
   --frameworks TEXT     Comma-separated framework hints
@@ -192,6 +244,10 @@ Options:
   --timeout INTEGER     Analysis timeout in seconds
   --dry-run             Analyze and print a summary; write/upload nothing
   --stdout              Write manifest JSON to stdout (for pipelines)
+  --detect-monorepo / --no-detect-monorepo
+                        Detect monorepo sub-project boundaries and upload one
+                        Application per sub-project (default: on; see
+                        "Monorepo support" below)
 ```
 
 ### auth
@@ -302,6 +358,48 @@ ruff check .
 ruff format --check .
 ```
 
+### Publishing a release (maintainers)
+
+The CLI is published to [PyPI](https://pypi.org/project/apisec-code-bolt/) by the
+**Publish to PyPI** GitHub Action. **Merging to `build` does NOT publish** — the
+workflow only runs on `workflow_dispatch` or a published GitHub Release, and it
+builds from whatever ref it runs on.
+
+Prerequisites (one-time): the `PYPI_API_TOKEN` repository secret must be set
+(Settings → Secrets and variables → Actions).
+
+1. **Bump the version.** Edit `version` in `pyproject.toml` (single source of
+   truth; `--version` reads it via package metadata). PyPI **rejects re-uploads**
+   of an existing version, so the number must be higher than the current PyPI
+   release. Open a PR and merge it to `build`.
+
+2. **Publish** — dispatch the workflow (the standard path we use):
+   Actions → *Publish to PyPI* → **Run workflow** → select branch **`build`**.
+
+   ```bash
+   gh workflow run "Publish to PyPI" --ref build
+   ```
+
+   <details><summary>Alternative: publish via a GitHub Release</summary>
+
+   New release → create tag `vX.Y.Z` → set **Target: `build`** (it defaults to
+   the default branch; only `build` has the bumped version) → Publish. This
+   fires the same workflow via `release: [published]`.
+
+   ```bash
+   gh release create vX.Y.Z --target build --title "vX.Y.Z" --notes "…"
+   ```
+   </details>
+
+3. **Verify.** Confirm the new version appears on
+   [PyPI](https://pypi.org/project/apisec-code-bolt/), then upgrade an install:
+   ```bash
+   uv tool upgrade apisec-code-bolt   # or: pipx upgrade apisec-code-bolt
+   ```
+
+> Always release from `build` after the version bump has merged there — releasing
+> from a ref that still carries the old version will fail the PyPI upload.
+
 ## Privacy
 
 apisec-code-bolt is designed with privacy as a core principle:
@@ -314,3 +412,4 @@ apisec-code-bolt is designed with privacy as a core principle:
 ## License
 
 Proprietary. Copyright © APIsec.
+

{apisec_code_bolt-0.1.8 → apisec_code_bolt-0.1.10}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "apisec-code-bolt"
-version = "0.1.8"
+version = "0.1.10"
 description = "Static analysis probe for extracting architectural metadata from codebases"
 readme = "README.md"
 license = {text = "Proprietary"}
@@ -44,9 +44,17 @@ dependencies = [
     # Ruby parsing
     "tree-sitter-ruby>=0.23",            # Ruby grammar for tree-sitter
 
+    # Python taint analysis
+    "tree-sitter-python>=0.23",          # Python grammar for tree-sitter
+    "tree-sitter-java>=0.23",             # Java grammar for tree-sitter
+
     # Graph operations
     "networkx>=3.2",                    # Call graph, data flow graphs
-    
+
+    # Dependency version/marker parsing (tree_resolver, version_resolver, pkgindex)
+    "packaging>=23.0",
+
+
     # Data validation and serialization
     "pydantic>=2.5.0",                  # Schema validation, settings
     "pydantic-settings>=2.1.0",         # Configuration from env