Description
The README documents two distinct local dev paths: "Simple Local Dev" (manual uvicorn ... --host 127.0.0.1 --port 8000, explicitly bound to localhost only) versus "Docker Compose Stack" (docker compose up --build, exposing the backend on port 8081). Docker's default networking behavior for exposed ports (ports: "8081:8000" style mappings) binds to 0.0.0.0 on the host unless explicitly restricted to 127.0.0.1:8081:8000 — meaning, unlike the manual dev path which is deliberately localhost-only, the Docker Compose path may expose the entire scan-triggering API (which can kick off recon/web/cloud/container scans per the documented plugin categories) to any device on the same local network or, in a misconfigured cloud/VM deployment, to the broader internet.
This is a meaningfully different risk profile for a project whose own README states: "Local-first: scan data stays on infrastructure you control" and whose Responsible Use section says "Do not use it against systems you do not own or explicitly have permission to assess" — an unintentionally network-exposed scan-trigger API undermines both of these stated goals if a contributor spins up the Docker stack on a shared or cloud machine without realizing the difference from the manual dev path.
Impact
Directly contradicts the project's own stated "local-first" and "responsible use" design principles if the Compose path silently exposes more than the manual path does.
A contributor unfamiliar with Docker's default port-binding behavior could unknowingly expose a scan-orchestration API to their local network.
Proposed Solution
Audit docker-compose.yml's port mappings for backend (and frontend, if applicable) and explicitly bind to 127.0.0.1 (e.g., "127.0.0.1:8081:8000") unless a network-accessible deployment is an intentional, documented use case.
If network-wide access is sometimes desired (e.g., team-shared scanning infra), add a clearly separate docker-compose.network.yml override file for that use case, keeping the default docker-compose.yml localhost-only.
Document this explicitly in the README's "Option 2: Docker Compose Stack" section so contributors understand the network exposure implications either way.
Acceptance Criteria
Default docker-compose.yml binds backend/frontend ports to 127.0.0.1 only
Any network-wide-access configuration is opt-in via a separate, clearly named override file
README documents the network exposure behavior explicitly for both dev paths
Description
The README documents two distinct local dev paths: "Simple Local Dev" (manual uvicorn ... --host 127.0.0.1 --port 8000, explicitly bound to localhost only) versus "Docker Compose Stack" (docker compose up --build, exposing the backend on port 8081). Docker's default networking behavior for exposed ports (ports: "8081:8000" style mappings) binds to 0.0.0.0 on the host unless explicitly restricted to 127.0.0.1:8081:8000 — meaning, unlike the manual dev path which is deliberately localhost-only, the Docker Compose path may expose the entire scan-triggering API (which can kick off recon/web/cloud/container scans per the documented plugin categories) to any device on the same local network or, in a misconfigured cloud/VM deployment, to the broader internet.
This is a meaningfully different risk profile for a project whose own README states: "Local-first: scan data stays on infrastructure you control" and whose Responsible Use section says "Do not use it against systems you do not own or explicitly have permission to assess" — an unintentionally network-exposed scan-trigger API undermines both of these stated goals if a contributor spins up the Docker stack on a shared or cloud machine without realizing the difference from the manual dev path.
Impact
Directly contradicts the project's own stated "local-first" and "responsible use" design principles if the Compose path silently exposes more than the manual path does.
A contributor unfamiliar with Docker's default port-binding behavior could unknowingly expose a scan-orchestration API to their local network.
Proposed Solution
Audit docker-compose.yml's port mappings for backend (and frontend, if applicable) and explicitly bind to 127.0.0.1 (e.g., "127.0.0.1:8081:8000") unless a network-accessible deployment is an intentional, documented use case.
If network-wide access is sometimes desired (e.g., team-shared scanning infra), add a clearly separate docker-compose.network.yml override file for that use case, keeping the default docker-compose.yml localhost-only.
Document this explicitly in the README's "Option 2: Docker Compose Stack" section so contributors understand the network exposure implications either way.
Acceptance Criteria
Default docker-compose.yml binds backend/frontend ports to 127.0.0.1 only
Any network-wide-access configuration is opt-in via a separate, clearly named override file
README documents the network exposure behavior explicitly for both dev paths