Problem Statement:
The README positions SecuScan as "local-first" ("scan data stays on infrastructure you control"), and the default setup binds the backend to 127.0.0.1:8000 (Simple Local Dev) or 127.0.0.1:8081 (Docker Compose). However, there's no mention anywhere in the README, Tech Stack, or Repository Map of any authentication/authorization layer on the FastAPI backend's scan-orchestration endpoints.
Why this matters:
"Local-first by default" is not the same as "safe to ever expose." The Docker Compose path in particular is a common source of accidental exposure — a contributor deploying this on a shared dev server, a cloud VM, or behind a reverse proxy for team demo purposes (a very plausible GSSoC/hackathon scenario) could unknowingly expose an unauthenticated API capable of triggering recon/cloud/container scans against arbitrary targets, with zero access control. Given the tool's own SECURITY.md and "Responsible Use" policy already show security-consciousness, this is a real gap relative to that stated intent.
Proposed Solution:
Add a minimal API-key or bearer-token check on all scan-triggering endpoints (backend/secuscan), configurable via an environment variable so local dev remains frictionless (e.g., defaults to a generated key printed on startup, or an explicit opt-out flag for local-only use).
Document this clearly in the README's Quick Start and in SECURITY.md, explicitly warning against exposing the API to non-localhost networks without enabling auth.
Add a test asserting scan-trigger endpoints reject requests without a valid key when auth is enabled.
Impact: Directly reinforces the project's own stated "local-first, safety-aware" design goal with an actual enforcement mechanism instead of relying on network topology alone.
Problem Statement:
The README positions SecuScan as "local-first" ("scan data stays on infrastructure you control"), and the default setup binds the backend to 127.0.0.1:8000 (Simple Local Dev) or 127.0.0.1:8081 (Docker Compose). However, there's no mention anywhere in the README, Tech Stack, or Repository Map of any authentication/authorization layer on the FastAPI backend's scan-orchestration endpoints.
Why this matters:
"Local-first by default" is not the same as "safe to ever expose." The Docker Compose path in particular is a common source of accidental exposure — a contributor deploying this on a shared dev server, a cloud VM, or behind a reverse proxy for team demo purposes (a very plausible GSSoC/hackathon scenario) could unknowingly expose an unauthenticated API capable of triggering recon/cloud/container scans against arbitrary targets, with zero access control. Given the tool's own SECURITY.md and "Responsible Use" policy already show security-consciousness, this is a real gap relative to that stated intent.
Proposed Solution:
Add a minimal API-key or bearer-token check on all scan-triggering endpoints (backend/secuscan), configurable via an environment variable so local dev remains frictionless (e.g., defaults to a generated key printed on startup, or an explicit opt-out flag for local-only use).
Document this clearly in the README's Quick Start and in SECURITY.md, explicitly warning against exposing the API to non-localhost networks without enabling auth.
Add a test asserting scan-trigger endpoints reject requests without a valid key when auth is enabled.
Impact: Directly reinforces the project's own stated "local-first, safety-aware" design goal with an actual enforcement mechanism instead of relying on network topology alone.