fabriziosalmi
diff --git a/‎.github/workflows/ci.yml‎
Lines changed: 109 additions & 0 deletions b/‎.github/workflows/ci.yml‎
Lines changed: 109 additions & 0 deletions
diff --git a/‎README.md‎
Lines changed: 18 additions & 16 deletions b/‎README.md‎
Lines changed: 18 additions & 16 deletions
diff --git a/‎docs/privacy.md‎
Lines changed: 3 additions & 2 deletions b/‎docs/privacy.md‎
Lines changed: 3 additions & 2 deletions
diff --git a/‎infra/docker/Caddyfile‎
Lines changed: 34 additions & 7 deletions b/‎infra/docker/Caddyfile‎
Lines changed: 34 additions & 7 deletions
diff --git a/‎packages/api/app/config.py‎
Lines changed: 18 additions & 0 deletions b/‎packages/api/app/config.py‎
Lines changed: 18 additions & 0 deletions
diff --git a/‎packages/api/app/dependencies.py‎
Lines changed: 54 additions & 10 deletions b/‎packages/api/app/dependencies.py‎
Lines changed: 54 additions & 10 deletions
@@ -122,6 +122,115 @@ jobs:
       - name: Run integration tests
         run: cd packages/api && python -m pytest tests/test_integration.py -v --tb=short
 
+  # -----------------------------------------------------------------------
+  # E2E Live Tests — full API stack (Postgres + Redis) in CI
+  #
+  # test_e2e_live.py is skipped automatically when E2E_LIVE_BASE_URL is
+  # not set (plain `pytest` stays green). This job provides the
+  # environment the test file expects: a real API server reachable over
+  # HTTP, backed by real Postgres and Redis.
+  #
+  # Architecture: we start postgres and redis as GHA services, run
+  # Alembic migrations, then launch the FastAPI app with uvicorn in the
+  # background. A polling loop waits until GET /api/v1/health returns 200
+  # before running the test suite. No docker-compose is needed — GHA
+  # services and `run: uvicorn &` give us the same isolation more cheaply.
+  #
+  # A dedicated E2E user is created (not a real admin account) so the
+  # tests don't depend on pre-seeded data and can run against a clean DB.
+  # -----------------------------------------------------------------------
+  e2e-tests:
+    name: E2E Live Tests
+    runs-on: ubuntu-latest
+    services:
+      postgres:
+        image: postgres:16-alpine
+        env:
+          POSTGRES_USER: nis2
+          POSTGRES_PASSWORD: nis2secret
+          POSTGRES_DB: nis2_e2e
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U nis2"
+          --health-interval 5s
+          --health-timeout 3s
+          --health-retries 10
+      redis:
+        image: redis:7-alpine
+        ports:
+          - 6379:6379
+        options: >-
+          --health-cmd "redis-cli ping"
+          --health-interval 5s
+          --health-timeout 3s
+          --health-retries 10
+    env:
+      ENVIRONMENT: development
+      DATABASE_URL: postgresql+asyncpg://nis2:nis2secret@localhost:5432/nis2_e2e
+      DATABASE_URL_SYNC: postgresql://nis2:nis2secret@localhost:5432/nis2_e2e
+      REDIS_URL: redis://localhost:6379/0
+      CELERY_BROKER_URL: redis://localhost:6379/1
+      CELERY_RESULT_BACKEND: redis://localhost:6379/2
+      JWT_SECRET: e2e-test-jwt-secret-must-be-at-least-32-chars-yes
+      CORS_ORIGINS: http://localhost:3000
+      # Credentials used both to register the E2E user and to run the suite.
+      E2E_LIVE_BASE_URL: http://localhost:8000
+      E2E_LIVE_EMAIL: e2e-ci@nis2.local
+      E2E_LIVE_PASSWORD: E2eC!password99
+    steps:
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
+      - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5
+        with:
+          python-version: ${{ env.PYTHON_VERSION }}
+
+      - name: Install dependencies
+        run: |
+          pip install -e packages/scanner
+          pip install -e packages/api
+          pip install pytest pytest-asyncio httpx slowapi uvicorn[standard] alembic
+
+      - name: Run Alembic migrations
+        run: cd packages/api && alembic upgrade head
+
+      - name: Start API server (background)
+        run: |
+          cd packages/api
+          uvicorn app.main:app --host 0.0.0.0 --port 8000 \
+            --log-level warning &
+          echo "API PID: $!"
+
+      - name: Wait for API to be healthy
+        run: |
+          for i in $(seq 1 30); do
+            if curl -sf http://localhost:8000/api/v1/health > /dev/null 2>&1; then
+              echo "API is up after ${i}s"
+              exit 0
+            fi
+            sleep 1
+          done
+          echo "ERROR: API did not start within 30 s"
+          exit 1
+
+      - name: Seed E2E user
+        run: |
+          # Register the E2E account via the public registration endpoint.
+          # Idempotent: a 409 (already exists) is also acceptable.
+          HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
+            -X POST http://localhost:8000/api/v1/auth/register \
+            -H "Content-Type: application/json" \
+            -d "{\"email\":\"${E2E_LIVE_EMAIL}\",\"password\":\"${E2E_LIVE_PASSWORD}\",\"full_name\":\"E2E CI User\"}")
+          if [ "$HTTP_CODE" != "201" ] && [ "$HTTP_CODE" != "409" ]; then
+            echo "ERROR: Registration returned HTTP $HTTP_CODE"
+            exit 1
+          fi
+          echo "Seed user ready (HTTP $HTTP_CODE)"
+
+      - name: Run E2E tests
+        run: |
+          cd packages/api
+          python -m pytest tests/test_e2e_live.py -v --tb=short
+
   # -----------------------------------------------------------------------
   # Web Build Check
   # -----------------------------------------------------------------------
 
@@ -41,30 +41,32 @@ The scanner is the technical probe. The governance framework is where the substa
 
 The compliance matrix references all ten sub-paragraphs (a) through (j). Several of them — by design of the directive itself — cannot be evaluated by an automated scanner and are tracked through the governance checklist (status: *manual verification required*). What the platform automates vs. what stays manual:
 
-| Sub-paragraph | Scope | How the platform supports it |
-|---------------|-------|------------------------------|
-| (a) Risk analysis policies | Methodology, periodic updates | Governance checklist (manual) |
-| (b) Incident handling | Detection, response, CSIRT notification | Incident module + Art. 23 lifecycle |
-| (c) Business continuity | BCP, DRP, backup, periodic testing | BIA module (RTO/RPO/MTPD) |
-| (d) Supply chain security | Vendor assessment, contracts, monitoring | Vendor Risk module (Art. 18) |
-| (e) Secure acquisition and development | SDLC, code review, vulnerability management | Governance checklist (manual) |
-| (f) Effectiveness assessment | Internal audits, KPIs, penetration testing | Technical validation engine + checklist |
-| (g) Cyber hygiene and training | Awareness, phishing simulation | Governance checklist (manual) |
-| (h) Cryptography | Crypto policy, key management | Technical validation (TLS/cert) + checklist |
-| (i) Human resources security | Onboarding/offboarding, screening, PAM | Governance checklist (manual) |
-| (j) Authentication and access control | MFA, RBAC, PAM, SSO, access logging | Governance checklist (manual) |
+| Sub-paragraph | Scope | Implementation status | How the platform supports it |
+|---------------|-------|-----------------------|------------------------------|
+| (a) Risk analysis policies | Methodology, periodic updates | **Partial** — automated bridge from scanner findings | Governance checklist + `POST /governance/sync-risk` automatically escalates checklist items when HIGH/CRITICAL scanner findings are open; risk summary via `GET /governance/risk-summary` |
+| (b) Incident handling | Detection, response, CSIRT notification | **Implemented** — automated deadline enforcement | Incident module + Art. 23 lifecycle + Celery beat task checks every 15 min and dispatches alerts (email/webhook/Slack) at 24 h / 72 h / 1-month thresholds with Redis-backed dedup |
+| (c) Business continuity | BCP, DRP, backup, periodic testing | **Implemented** — manual verification | BIA module (RTO/RPO/MTPD), impact scoring, gap detection |
+| (d) Supply chain security | Vendor assessment, contracts, monitoring | **Implemented** — transparent scoring formula | Vendor Risk module (Art. 18) with documented 100-point scoring formula (certification, data access, audit recency, geography, security clauses); auditor-facing `GET /vendors/score-formula` |
+| (e) Secure acquisition and development | SDLC, code review, vulnerability management | **Partial** — scanner automates surface checks | Technical validation engine (TLS, headers, secrets, ports) + governance checklist for organisational controls |
+| (f) Effectiveness assessment | Internal audits, KPIs, penetration testing | **Partial** — scan-driven | Technical validation engine + checklist |
+| (g) Cyber hygiene and training | Awareness, phishing simulation | **Manual** | Governance checklist (human verification required by design) |
+| (h) Cryptography | Crypto policy, key management | **Partial** — automated for public-facing TLS | Technical validation (TLS version, cipher suites, cert expiry, HSTS) + checklist for key-management policy |
+| (i) Human resources security | Onboarding/offboarding, screening, PAM | **Manual** | Governance checklist (human verification required by design) |
+| (j) Authentication and access control | MFA, RBAC, PAM, SSO, access logging | **Partial** — RBAC + audit log implemented; TOTP MFA planned | Role-based access (owner/admin/auditor/viewer), API key scopes, dual-auth, per-request audit log; TOTP MFA tracked in [#86](https://github.com/fabriziosalmi/nis2-public/issues/86) |
+
+**Legend**: *Implemented* = fully automated with no manual step required. *Partial* = automated checks cover the technically observable surface; organisational controls require human verification. *Manual* = the directive explicitly requires human judgement — automation cannot substitute.
 
 ### Art. 23 — Incident reporting (CSIRT)
 
 Incident lifecycle aligned with the legal deadlines:
 
 | Phase | Deadline | Platform support |
 |-------|----------|------------------|
-| Early Warning | 24 hours | "Red Button" — generates a CSIRT-ready Early Warning JSON from 3 fields plus the latest asset inventory |
-| Incident Notification | 72 hours | Structured form with taxonomy, IOCs, timeline |
-| Final Report | 1 month | Aggregated data, impact assessment, lessons learned |
+| Early Warning | 24 hours | "Red Button" generates a CSIRT-ready Early Warning JSON + **automated alert 2 h before / on breach** via email, webhook (HMAC-SHA256 signed), or Slack |
+| Incident Notification | 72 hours | Structured form with taxonomy, IOCs, timeline + **automated alert 2 h before / on breach** |
+| Final Report | 1 month | Aggregated data, impact assessment, lessons learned + **automated alert 2 h before / on breach** |
 
-> Note: The platform produces the artefacts and tracks the deadlines. **Submission to CSIRT Italia is a manual step** through `csirt.gov.it`. There is no automated push.
+> Note: The platform produces the artefacts, tracks the deadlines, and dispatches alerts automatically via configured notification channels. **Submission to CSIRT Italia is a manual step** through `csirt.gov.it`. There is no automated push to the CSIRT portal.
 
 ### Art. 18 — Supply chain (Vendor Risk Management)
 
 
@@ -118,8 +118,9 @@ When you `git clone` and `make prod` on your own infrastructure, **you become th
 Every successful state-changing request (Pre-`AuditMiddleware` v2.4.x) writes an `audit_logs` row that includes the originating **IP address** and **User-Agent**. Both are personal data when they relate to an identifiable person.
 
 - **Legal basis** — Art. 6(1)(f) legitimate interest in maintaining a forensic trail of administrative actions on tenant data, with a documented retention ceiling. Art. 32 GDPR (security of processing) makes this trail expected for any system processing organisational compliance data.
-- **Pseudonymisation on erasure** — when a user invokes `DELETE /api/v1/auth/me`, their `audit_logs` rows are not deleted (the audit trail is the controller's legitimate interest under Art. 89(1)). Instead `user_id` is nulled, `ip_address` is replaced with `127.0.0.1`, and `user_agent` is replaced with `[erased]`. The action / resource columns survive so the audit chain remains intact.
-- **Retention** — default 90 days. Set `AUDIT_LOG_RETENTION_DAYS` to your own jurisdiction's requirement.
+- **Pseudonymisation on erasure** — when a user invokes `DELETE /api/v1/auth/me`, their `audit_logs` rows are not deleted (the audit trail is the controller's legitimate interest under Art. 89(1)). Instead: `user_id` is set to NULL, `ip_address` is replaced with `127.0.0.1`, `user_agent` is replaced with `[erased]`, and `details` (a JSONB field that may contain linkable UUIDs such as org or resource IDs) is set to NULL. The `action`, `resource_type`, `resource_id`, and `created_at` columns survive so the event chain remains intact for forensic purposes without attributing the event to the erased subject.
+- **Retention** — default 90 days. Set `AUDIT_LOG_RETENTION_DAYS` to your own jurisdiction's requirement. A daily Celery beat job (`cleanup_expired_auth_records`) prunes rows — including pseudonymised ones — once their `created_at` age exceeds the ceiling.
+- **GDPR Art. 17 vs NIS2 Art. 21 explicit resolution** — the platform resolves the tension between the right to erasure and the NIS2 audit-trail obligation through pseudonymisation: the event is retained in unlinkable form, satisfying both the GDPR storage-limitation principle (Art. 5(1)(e)) and the NIS2 requirement that audit evidence be available during the retention window. Operators using the platform for security-incident management should raise `AUDIT_LOG_RETENTION_DAYS` to ≥ 365 (NIS2 Art. 21 recommends evidence retention of at least 12 months); this does not conflict with GDPR because the retained rows are pseudonymised post-erasure.
 
 ### 7.3 Outbound network calls during scans
 
 
@@ -1,18 +1,45 @@
 {$DOMAIN:localhost} {
+    # Common security headers applied to every response regardless of handler.
+    # CSP is set per-handler below because the API (JSON) and the frontend
+    # (Next.js SPA) need different policies.
+    header {
+        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
+        X-Content-Type-Options    "nosniff"
+        X-Frame-Options           "DENY"
+        Referrer-Policy           "strict-origin-when-cross-origin"
+        X-XSS-Protection          "1; mode=block"
+        Permissions-Policy        "geolocation=(), camera=(), microphone=(), payment=()"
+        # Prevent the Caddy default Server header from leaking version info.
+        -Server
+    }
+
+    # API handler — strict CSP: the backend only returns JSON, so no
+    # scripts, styles, frames, or embedded resources are ever needed.
     handle /api/* {
         reverse_proxy api:8000
+
+        header {
+            # default-src 'none' blocks all resource loads. The API does not
+            # serve HTML, so this is safe and maximally restrictive.
+            Content-Security-Policy "default-src 'none'; frame-ancestors 'none'"
+        }
     }
 
+    # Frontend handler — Next.js App Router SPA.
+    #
+    # 'unsafe-inline' is required for:
+    #   - Script: Next.js injects inline chunks during hydration
+    #   - Style:  Tailwind CSS and shadcn/ui use inline style attributes
+    #
+    # TODO: migrate to nonce-based CSP via Next.js middleware once
+    # the frontend implements generateStaticParams / nonce injection,
+    # which would allow removing 'unsafe-inline' from script-src.
     handle {
         reverse_proxy web:3000
-    }
 
-    header {
-        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
-        X-Content-Type-Options "nosniff"
-        X-Frame-Options "DENY"
-        Referrer-Policy "strict-origin-when-cross-origin"
-        X-XSS-Protection "1; mode=block"
+        header {
+            Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; connect-src 'self'; font-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'"
+        }
     }
 
     encode gzip zstd
 
@@ -63,6 +63,24 @@ class Settings(BaseSettings):
     # enough that the disk doesn't grow unbounded.
     report_ttl_days: int = 30
 
+    # GDPR Art. 5(1)(e) storage limitation for audit logs.
+    # The privacy notice (docs/privacy.md §7.2) advertises 90 days as the
+    # default. Set AUDIT_LOG_RETENTION_DAYS in .env to match your own
+    # jurisdiction's audit-trail obligation (NIS2 Art. 21 recommends ≥ 12
+    # months for incident evidence; raise this on instances that handle
+    # security incidents). The cleanup_tasks beat job prunes rows daily.
+    audit_log_retention_days: int = 90
+
+    # Maximum number of report-generation Celery tasks that a single
+    # organisation may have running concurrently. Each task consumes one
+    # Celery worker slot and can be CPU/disk intensive (a 50k-finding
+    # scan takes ~30 s). The 5/min/IP rate limit on POST /reports/generate
+    # already caps the burst rate; this cap prevents a single org from
+    # monopolising the entire worker pool across multiple scans and formats.
+    # Raise on instances with many workers and trusted users; lower on
+    # shared / multi-tenant setups. Default 3.
+    max_concurrent_reports_per_org: int = 3
+
     model_config = {"env_file": ".env", "env_file_encoding": "utf-8", "extra": "ignore"}
 
     @model_validator(mode="after")
 
@@ -308,6 +308,56 @@ async def get_api_key_org(
     return api_key, api_key.organization_id
 
 
+async def _resolve_dual_auth(
+    request: Request,
+    credentials: HTTPAuthorizationCredentials | None,
+    db: AsyncSession,
+    required_scope: str | None,
+) -> uuid.UUID:
+    """Core logic shared by get_org_id_dual_auth and dual_auth_with_scope."""
+    raw = credentials.credentials if credentials else None
+    has_cookie = request.cookies.get("access_token") is not None
+
+    if raw and raw.startswith("nis2_") and not has_cookie:
+        api_key, org_id = await get_api_key_org(db=db, credentials=credentials)
+        if (
+            required_scope is not None
+            and api_key.scopes is not None
+            and required_scope not in api_key.scopes
+        ):
+            raise HTTPException(
+                status_code=status.HTTP_403_FORBIDDEN,
+                detail=f"API key missing required scope: {required_scope}",
+            )
+        return org_id
+
+    user = await get_current_user(request=request, credentials=credentials, db=db)
+    _, membership = await get_current_org(request=request, current_user=user)
+    return membership.organization_id
+
+
+def dual_auth_with_scope(required_scope: str):
+    """Dependency factory: authenticate via JWT session OR API key, enforcing a scope.
+
+    When the caller presents an API key (Bearer `nis2_*` with no cookie),
+    the key's scope list must contain `required_scope` — otherwise 403.
+    Keys with `scopes=None` (legacy, pre-2.4.26) pass through unrestricted.
+
+    JWT sessions are not scope-constrained (role-based access handles that).
+
+    Usage:
+        org_id: uuid.UUID = Depends(dual_auth_with_scope("scan:read"))
+    """
+    async def _dep(
+        request: Request,
+        credentials: HTTPAuthorizationCredentials | None = Depends(bearer_scheme),
+        db: AsyncSession = Depends(get_db),
+    ) -> uuid.UUID:
+        return await _resolve_dual_auth(request, credentials, db, required_scope)
+
+    return _dep
+
+
 async def get_org_id_dual_auth(
     request: Request,
     credentials: HTTPAuthorizationCredentials | None = Depends(bearer_scheme),
@@ -334,14 +384,8 @@ async def get_org_id_dual_auth(
 
     Returns the organization_id only — read endpoints just need it for
     RLS scoping; they don't need the user's identity.
-    """
-    raw = credentials.credentials if credentials else None
-    has_cookie = request.cookies.get("access_token") is not None
-
-    if raw and raw.startswith("nis2_") and not has_cookie:
-        _, org_id = await get_api_key_org(db=db, credentials=credentials)
-        return org_id
 
-    user = await get_current_user(request=request, credentials=credentials, db=db)
-    _, membership = await get_current_org(request=request, current_user=user)
-    return membership.organization_id
+    Prefer dual_auth_with_scope(required_scope) for new endpoints so
+    scope enforcement is explicit at the call site.
+    """
+    return await _resolve_dual_auth(request, credentials, db, required_scope=None)