## Problema La scansione di sicurezza ha rilevato **1 vulnerabilità confermate e azionabili** (1 low) nel repository `opencity-labs/go-cron`. Questa issue le porta nel planning dello sprint, con triage già eseguito. ## Vulnerabilità da risolvere > Legenda triage: *Vulnerabilità reale* = sfruttabile nel contesto; *Rafforzamento* = debolezza reale ma non direttamente sfruttabile, fix comunque consigliato. | Severità | Fonte | Posizione | Descrizione | Triage | |---|---|---|---|---| | LOW | `semgrep/gosec.G114-1` | `httpserver.go:28` | Allocation of resources without limits or throttling | Rafforzamento (debolezza reale, non direttamente sfruttabile nel contesto) — http.ListenAndServe senza timeout di lettura/scrittura può lasciare connessioni pendenti a tempo indeterminato, ma l'endpoint espone solo un payload di health-check in sola lettura e tipicamente è raggiungibile solo dall'interno del cluster. | ## Approccio suggerito **Hardening del server HTTP (finding unico)** In `httpserver.go:28` la chiamata `http.ListenAndServe` non configura timeout di lettura né di scrittura: un client che apre la connessione e non invia o non consuma dati può tenere occupate goroutine e file-descriptor a tempo indeterminato. Strategia: sostituire `http.ListenAndServe` con un'istanza esplicita di `http.Server` valorizzando almeno `ReadTimeout` e `WriteTimeout` (valori indicativi: 5–15 s, calibrati sul contratto atteso dell'health-check e sui probe del cluster). Questo è un **intervento di solo hardening nel codice** (nessun aggiornamento di dipendenza richiesto): richiede giudizio nella scelta dei valori di timeout per non disconnettere client legittimi o far scattare i liveness probe del deployment. ## Ambito e vincoli - **In-scope**: aggiornare le dipendenze alle versioni con fix indicate in tabella; per i finding di codice, l'intervento localizzato descritto nell'approccio. - **Out-of-scope**: aggiornamenti *major* non richiesti, refactoring non correlato, modifiche ad aree non toccate dai finding. - **Non toccare** codice o dipendenze non elencati in questa issue. ## Probabili falsi positivi 1 finding che il triage ritiene non rischiosi nel contesto: non entrano nella issue e vengono ri-valutati a ogni run, quindi **non serve fare nulla**. Se però uno **ricorre** ed è rumore, per sopprimerlo in modo stabile aggiungi la regola già pronta (nel blocco sotto) nel file **`.gitlab/security-fp-rules.yaml` di questo repository** — è opzionale, crealo se non esiste, mettendo le voci sotto la chiave `rules:`. Il file è mantenuto dal team del repo. Se invece è una vulnerabilità vera mal-classificata, correggila. <details><summary>Mostra i 1 probabili falsi positivi e le regole pronte per `.gitlab/security-fp-rules.yaml`</summary> | Severità | Fonte | Posizione | Descrizione | |---|---|---|---| | HIGH | `semgrep/gosec.G204-1` | `go-cron.go:50` | Improper neutralization of special elements used in an OS command ('OS Command Injection') | ```yaml rules: - rule_id: "gosec.G204-1" source: "semgrep" path: "go-cron.go" reason: "CONFERMARE FP: exec.Command riceve command e args come slice separata (nessuna shell interposta) e i valori provengono esclusivamente da os.Args controllati dall'operatore che avvia il binario, non da input esterno non fidato." ``` </details> ## Criteri di accettazione - Il server HTTP definito in `httpserver.go` espone valori espliciti e maggiori di zero per `ReadTimeout` e `WriteTimeout`: connessioni che non completano la fase di lettura o scrittura entro quei limiti vengono chiuse dal server, senza mantenere goroutine o descrittori di file occupati a tempo indeterminato. ## Test **Comando di verifica:** `go test ./...` ### Fatto (automatizzabile) - [ ] `go test ./...` passa senza regressioni dopo la modifica. - [ ] Aggiungere un test (es. in `httpserver_test.go`) che verifichi il comportamento di timeout: dato un client che apre la connessione TCP verso il server ma non invia dati entro il `ReadTimeout` configurato, la connessione deve essere chiusa dal server entro l'intervallo atteso; il test deve passare. Implementazione suggerita: avviare il server su porta effimera con `httptest` o direttamente, aprire una `net.Conn` senza scrivere nulla, attendere leggermente oltre il timeout e verificare che la connessione risulti chiusa (es. lettura restituisce `io.EOF` o errore di rete). - [ ] I campi `ReadTimeout` e `WriteTimeout` della struct `http.Server` sono valorizzati con valori > 0, verificabile nell'asserzione del test o con ispezione statica. ### Gate umano / staging - [ ] Verificare in staging che l'endpoint di health-check risponda correttamente a chiamate legittime dopo l'introduzione dei timeout (area funzionale: liveness/readiness probe del cluster). - [ ] Confermare che gli intervalli di probe configurati nel manifesto di deployment (Kubernetes o equivalente) siano inferiori ai timeout impostati, per evitare riavvii indesiderati del pod. - [ ] Link all'ambiente di staging: _(da compilare dall'assegnatario)_ **Ambiente di test:** _da inserire prima della chiusura — link diretto allo staging che punta alla funzionalità toccata dal fix (richiesto da ISSUES.md per le issue chiuse in sprint)._ <details><summary>Dati per automazione (per un agente — non serve all'umano)</summary> ```json [ { "key": "semgrep:gosec.G114-1:httpserver.go:28", "source": "semgrep", "rule_id": "gosec.G114-1", "severity": "low", "package": null, "current_version": null, "fix_version": null, "manifest_paths": [], "pin_style": null, "build_flow": null, "dep_location": null, "transitive": null, "file": "httpserver.go", "line": 28, "classification": "hardening" } ] ``` </details> --- *Issue generata automaticamente da [security-sprint-agent](https://gitlab.com/opencity-labs/product/-/blob/main/.gitlab/ci/security_sprint_agent/SECURITY_SPRINT_AGENT.md).* <!-- security-sprint-agent repo=opencity-labs/go-cron iteration=3825551 findings=ffab9b6fd552 --> <!-- ssa-keys semgrep:gosec.G114-1:httpserver.go:28 --> <!-- ssa-candidates -->