GitHub rileva i segreti Starlink e riduce gli allarmi fuorvianti

GitHub riconosce ora i segreti delle API pubbliche Starlink v2, mentre SpaceX entra nel programma di partner per la scansione delle credenziali. L’aggiornamento del 5 novembre rende anche più selettivi diversi rilevatori esistenti per ridurre i falsi positivi. Sono due aspetti dello stesso problema: trovare le vere esposizioni senza sommergere chi mantiene il codice di stringhe soltanto simili a credenziali.

Il nuovo tipo rilevato si chiama starlink_public_api_v2_secret. Quando un segreto supportato viene trovato in un repository pubblico, GitHub può informare il servizio che lo ha emesso, consentendogli di intervenire con revoca o rotazione. L’annuncio non dimostra che ogni rilevamento sia già stato revocato, né copre automaticamente ogni possibile formato di credenziale Starlink.

Una stringa plausibile non è sempre una chiave

Alcuni interventi riguardano il contesto del valore individuato. Il rilevatore OpenVSX gestisce più attentamente i token precedenti, evitando di scambiare UUID non pertinenti per credenziali. Quello di Logfire segue con maggiore precisione lunghezza e caratteri documentati, escludendo valori di esempio e token pubblici del browser.

Per alcuni formati Alibaba, AWS e Google vengono soppressi risultati isolati quando i filtri eliminano il valore complementare necessario a rendere significativa la coppia. Il controllo Tencent richiede lettere e numeri dopo il prefisso, evitando identificatori alfabetici come i nomi delle funzioni.

Gli esempi chiariscono perché la scansione non possa limitarsi a cercare testo lungo e apparentemente casuale. Molti identificatori legittimi hanno proprio quell’aspetto. Anche la documentazione contiene esempi simili a chiavi. Il rilevatore deve combinare formato e contesto, senza diventare tanto restrittivo da perdere le esposizioni reali.

Ridurre il rumore aiuta a riconoscere l’avviso importante

Un falso positivo consuma attenzione anche se non provoca un incidente. Qualcuno deve aprire il risultato, capire il codice circostante e stabilire se quel valore conceda davvero accesso. Una lunga sequenza di segnalazioni inutili può rendere più facile rimandare la successiva.

L’aggiornamento non pubblica una percentuale universale di riduzione, quindi non sarebbe corretto attribuirgli un miglioramento misurato su tutti i repository. Identifica però casi concreti in cui la selezione è stata affinata. È una spiegazione più utile della generica promessa di uno scanner più intelligente.

La documentazione GitHub raccomanda la rotazione della credenziale esposta. Cancellare la stringa dall’ultima versione del file non rende invalida una copia già ottenuta da altri. Cronologia del repository e validità dell’accesso sono problemi collegati ma distinti.

Notifica al partner e avviso nel repository non coincidono

GitHub distingue le segnalazioni inviate al servizio emittente dagli avvisi destinati agli utenti del repository. Il programma partner raggiunge chi può revocare la credenziale; gli avvisi sostengono l’indagine di chi mantiene il progetto. Le funzioni disponibili dipendono anche dal tipo di repository e dal piano.

La documentazione indica la scansione automatica gratuita per i repository pubblici, mentre quelli privati delle organizzazioni richiedono la configurazione Secret Protection prevista. Descrive inoltre il controllo della cronologia Git sui branch e nuove scansioni quando vengono aggiunti tipi supportati. Un rilevatore nuovo può quindi essere utile anche per codice pubblicato prima della sua introduzione.

L’aggiunta Starlink accorcia il percorso tra un token supportato esposto e chi può disabilitarlo. I filtri migliorati aiutano l’altra parte del percorso: riconoscere quando una segnalazione merita attenzione. Uno scanner diventa affidabile quando trova la stringa giusta e la risposta elimina davvero l’accesso che quella stringa consentiva.