Diagnostica (Pro)

Diagnostica è un registro unico di ogni tentativo che DefectDojo effettua per comunicare con qualcosa al di fuori di sé stesso — e dei tentativi che altri sistemi effettuano per comunicare con esso. Quando un ticket non è mai comparso, una scansione non è mai stata importata o un utente non è riuscito ad accedere, questa è la pagina che indica cosa è successo, quando, con quale configurazione e chi lo ha provocato.

Diagnostica è una funzionalità di DefectDojo Pro. La trovi in Connect > Diagnostics.

Cosa viene registrato#

Viene scritta una riga per ogni tentativo, da ogni sottosistema che comunica con l’esterno di DefectDojo:

Le righe vengono scritte insieme al sottosistema, mai al suo posto. Ogni adapter è collegato al record di origine ed è deliberatamente fail-safe: se la scrittura di una riga diagnostica genera un errore, l’errore viene ignorato e l’operazione originale prosegue. Diagnostica non può quindi mai essere la causa del fallimento di un invio, di un’importazione o di un accesso.

Poiché le righe sono associate al record che le ha generate, salvare di nuovo un record di origine aggiorna la riga diagnostica esistente invece di aggiungerne una duplicata. Un tentativo corrisponde a una riga per tutta la sua durata, da Queued a Running fino al suo esito.

Campi di una riga#

Le quattro viste#

Le schede sopra la tabella sono punti di partenza salvati, non filtri da ricostruire ogni volta:

• Errors — errori e timeout. La prima da aprire.
• Successes — la prova che un’integrazione funzionante sta funzionando, utile quando qualcuno segnala che “non si sta sincronizzando nulla”.
• Never completed — tentativi ancora Queued o Running ben oltre il momento in cui avrebbero dovuto concludersi. Sono i casi silenziosi: nulla è fallito, quindi nulla è stato segnalato, ma nulla è nemmeno arrivato.
• All events — tutto, senza filtri.

La vista attiva fa parte dell’URL della pagina, quindi una vista è collegabile tramite link e sopravvive a un aggiornamento.

Restringere l’elenco#

• Time range — 24 ore, 7 giorni, 30 giorni o 90 giorni, dai pulsanti nell’intestazione.
• Conteggi per origine — i conteggi colorati sotto le schede di riepilogo sono anche filtri rapidi. Fai clic su uno per mostrare solo quell’origine; fai clic di nuovo (oppure su Clear source filter) per tornare indietro. Ne è attivo uno o nessuno alla volta.
• Filtri e ordinamento per colonna — ogni colonna filtra e ordina, incluse Severity e Source. Severity ordina in base alla gravità (Critical → Info) anziché alfabeticamente, e Source ordina in base all’etichetta visualizzata anziché al valore memorizzato sottostante.
• Keyword Search — cerca contemporaneamente in tutti i campi di testo.
• Preferenze di colonna — il selettore di colonne e i suoi layout salvati si comportano come in ogni altro elenco di Pro.

Fai clic sulla lente d’ingrandimento all’inizio di una riga per aprire l’intero tentativo:

Le credenziali vengono rimosse prima che la riga venga scritta#

Gli errori di integrazione citano la richiesta che è fallita, e queste citazioni contengono segreti: un header Authorization, un token in una query string, una password all’interno di un URL di connessione. Diagnostica li elimina in ingresso, così il valore originale non raggiunge mai il database e nessun ripensamento successivo può esporlo.

Vengono ripulite due cose:

• I valori sotto chiavi dalla forma di credenziale — qualsiasi cosa la cui chiave assomigli a un segreto (password, token, secret, api_key, authorization, private_key e simili, in qualsiasi combinazione di maiuscole/minuscole o con trattini o spazi). Un piccolo insieme di chiavi è esente perché conta solo la loro presenza, mai il loro contenuto.
• I valori che sembrano credenziali ovunque compaiano — header di autorizzazione bearer e basic, JWT, credenziali incorporate negli URL (https://user:pass@host), prefissi di token dei vendor riconoscibili e blocchi PEM.

Ognuno viene sostituito con [redacted]. Il messaggio circostante viene mantenuto, così l’errore resta leggibile:

401 Unauthorized: Authorization: [redacted]
upload rejected: https://svc:[redacted]@sftp.example/out/…

I valori lunghi vengono troncati e il contesto profondamente annidato viene appiattito, così un payload enorme non può gonfiare la tabella.

Quando qualcosa è stato rimosso da una riga, la riga lo segnala, invece di lasciarti chiedere se il campo fosse vuoto o svuotato.

La redazione è best-effort per design. Il meccanismo di pulizia riconosce le forme delle credenziali. Un segreto che assomiglia a prosa comune, sotto una chiave che non sembra sensibile, può comunque essere registrato. Considera Diagnostica come un log operativo, non come un luogo in cui i segreti sono garantiti assenti — e mantieni il dettaglio tecnico riservato a chi ne ha bisogno.

Chi vede cosa#

Diagnostica è organizzata su livelli, perché il riepilogo di un errore è utile per il proprietario di un prodotto, mentre la richiesta grezza che ne sta dietro no.

Un utente non superuser vede che un dettaglio esiste e viene nascosto, invece di un campo vuoto che sembra un dato mancante. Le righe a livello di istanza — SSO, SAML, LDAP e altre attività che non appartengono a nessun prodotto — sono riservate ai superuser, poiché non esiste alcuna appartenenza a un prodotto che potrebbe concedere l’accesso a esse.

Per quanto tempo vengono conservati i record#

Un’attività pianificata riduce il registro affinché non possa crescere senza limiti:

Entrambe le finestre sono configurabili con le impostazioni DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS e DIAGNOSTIC_EVENT_RETENTION_DAYS. L’eliminazione viene eseguita a lotti, così una grande cancellazione non mantiene aperta una transazione lunga.

API#

Il registro è di sola lettura tramite API, all’indirizzo /api/v2/diagnostic_events/:

Parametri utili:

Si applicano le stesse regole di accesso: un utente non superuser ottiene righe limitate ai propri prodotti, con i campi riservati nascosti.

Capire cosa è andato storto#

• Un ticket non è mai comparso. Filtra Source sull’integratore (o su Jira), quindi leggi Status. Failed fornisce il motivo in Summary; Queued molto tempo dopo il fatto significa che il job non è mai stato eseguito, il che è un problema di worker o di pianificazione più che di credenziali.
• Un utente non riesce ad accedere. Filtra Source su SSO, SAML o LDAP e leggi l’errore per il suo tentativo — una firma di asserzione errata, un bind rifiutato, un attributo non corrispondente. Queste righe sono a livello di istanza, quindi sono riservate ai superuser.
• Una scansione non è comparsa. Filtra Source su Import / Reimport. Guarda Trigger per distinguere un caricamento pianificato non presidiato da uno manuale di qualcuno, e Triggered by per sapere a chi chiedere.
• Qualcosa continua a riprovare all’infinito. Ordina per Correlation ID, o filtra su uno specifico, per vedere insieme ogni tentativo della stessa operazione logica.
• “Non funziona niente.” Apri prima Successes per la stessa finestra temporale. Un elenco sano lì trasforma un’interruzione vaga in una specifica.

Correlati#

• Feature Flags — attivare e disattivare le funzionalità Pro opzionali
• Connectors — importare i riscontri
• Pro Integrations — esportare i riscontri
• Single Sign-On — i provider di identità i cui tentativi di accesso compaiono qui