La vostra automazione riceve un segreto, lo conserva e poi lo invia a GitHub per leggere un deposito. Funzionava ieri, ma un valore più lungo ora viene troncato nel passaggio. I diritti possono essere corretti e la richiesta può comunque fallire. La fine del deployment dei nuovi token di installazione GitHub Apps, annunciata il 2 ottobre 2026, invita a seguire questo segreto in tutto il suo percorso.
Identificare il segreto interessato prima di cercare ovunque
Una GitHub App è un'applicazione alla quale concedete permessi su un insieme di repository. La sua installazione ha un contesto di accesso proprio. Il token di installazione serve per le chiamate effettuate in questo contesto; si distingue dal segreto di un utente e dalla chiave privata dell'applicazione.
La documentazione GitHub separa l’autenticazione dell’applicazione e la generazione di un token per la sua installazione. Prima del vostro audit, trovate quindi il componente che ottiene effettivamente quest’ultimo. Una configurazione che porta semplicemente il nome « token GitHub » non basta per identificare la sua famiglia. Documentazione dei token di installazione.
Il 2 ottobre, GitHub ha annunciato la fine del dispiegamento iniziato il 27 aprile: i nuovi token di installazione utilizzano per default un formato stateless. Mantengono il prefisso ghs_ e contano circa 520 caratteri, rispetto ai 40 precedenti. I permessi, il perimetro dei depositi, la scadenza di un’ora e l’endpoint restano invariati. L’intestazione temporanea X-GitHub-Stateless-S2S-Token sarà deprecata il 30 novembre 2026. Annuncio di fine del dispiegamento.
Stateless descrive qui il nuovo formato del fornitore. Non avete bisogno di comprenderne l'interno per trasmettere correttamente il segreto. Il valore deve rimanere opaco: la vostra applicazione lo trasporta, ma non costruisce le sue regole di accesso decodificando ciò che pensa di riconoscervi. L'ordine di grandezza pubblicato non è una nuova lunghezza esatta da imporre in un modulo.
Disegnare il percorso reale, dal fornitore alla richiesta
Il nostro esempio fittizio è uno strumento interno che consulta lo stato dei depositi. Un servizio ottiene il token, una memoria lo conserva brevemente, un processo di lavoro lo carica e un client HTTP lo invia. Un'interfaccia di amministrazione e una raccolta di errori possono anch'essi manipolarlo. Ognuno di questi passaggi può conservare un'ipotesi vecchia.
Iniziate dai nomi delle variabili, delle proprietà e dei parametri che trasportano il valore. Cercate poi le restrizioni sulla loro lunghezza e le trasformazioni applicate: taglio della stringa, rimozione di caratteri, codifica o copia in un campo diverso. Una restrizione può derivare dal codice, da uno schema di base o da un componente esterno.
Una colonna troppo corta può provocare un errore esplicito, ma alcuni percorsi possono troncare silenziosamente. Un campo dell'interfaccia può rifiutare l'immissione prima ancora della chiamata di rete. Una maschera del registro può riconoscere solo il vecchio segreto e lasciare che parte del nuovo appaia. Non riducete quindi l'audit alla riga che costruisce l'intestazione di autenticazione.
| Componente da esaminare | Domanda utile | Prova attesa |
|---|---|---|
| Servizio di ottenimento | La risposta è copiata interamente? | Uguaglianza su un valore fittizio |
| Stoccaggio | La capacità e i controlli sono adeguati? | Lettura dopo scrittura senza perdita |
| Caricamento | Il valore viene modificato durante il trasporto? | Confronto prima e dopo il passaggio |
| Client di rete | L'intestazione contiene il valore corretto? | Cattura in un trasporto simulato |
| Giornali ed errori | Una parte del segreto appare? | Ricerca negativa nelle uscite |
Questa griglia è una proposta Partitech. Aggiungete un responsabile per riga, poiché un test positivo sul codice applicativo non valida necessariamente il proxy o lo strumento di archiviazione gestito da un altro team.
Testare una proprietà, piuttosto che un esempio di formato
La proprietà ricercata è semplice: il valore che entra deve essere identico a quello che raggiunge il trasporto previsto. Una stringa di test non ha bisogno di assomigliare a un vero segreto. Scegliete un prefisso esplicito, per esempio FAUX_SECRET_TEST_, e dimensioni varie, di cui una superiore all'ordine di grandezza annunciato. Questi valori non devono mai consentire un'autenticazione.
Potete includere una stringa corta, una più lunga e un valore contenente i caratteri che il vostro componente accetta secondo il suo contratto. Le dimensioni sono parametri di test locali, non una stima dei futuri token GitHub. Conservate limiti ragionevoli contro gli ingressi abusivi; evitate soltanto un vincolo derivante da un formato antico senza giustificazione tecnica.
Pseudocodice del controllo proposto, non eseguito qui:
pour chaque valeur factice du jeu de test
écrire dans le stockage de test
relire par le chemin de chargement réel
envoyer au client HTTP simulé
vérifier l'égalité avec la valeur de départ
provoquer une erreur de transport simulée
vérifier l'absence de la valeur dans toutes les sorties
Aggiungete un caso che superi volontariamente la capacità definita del vostro componente. L'errore deve essere chiaro e non deve né troncare e poi continuare, né mostrare il contenuto ricevuto. Questo test verifica la qualità del rifiuto; non vi chiede di accettare stringhe di dimensioni infinite.
Per il mascheramento, cercate il segreto completo ma anche i segmenti riconoscibili che potrebbero essere esposti. Una regola che nasconde l’inizio e mostra la fine rimane una perdita. Ispezionate la risposta di errore, la console, i log strutturati e eventuali allegati di diagnostica. Fate questo con valori fittizi, affinché l’indagine stessa non diventi un’esposizione.
Correggere il confine errato senza ampliare i diritti
Se l'archiviazione tronca, correggete la sua capacità secondo le convenzioni della vostra applicazione. Se un'espressione regolare richiede esattamente la vecchia lunghezza, sostituite questa ipotesi con un controllo coerente con l'uso reale. Se uno strumento di diagnostica riconosce solo un vecchio schema, è preferibile rimuovere la proprietà segreta dalla raccolta piuttosto che cercare di indovinare tutte le sue forme future.
Un errore di formato non giustifica l’aggiunta di permessi all’applicazione. Nel nostro strumento fittizio, la lettura dei repository rimane una lettura dei repository, anche dopo la correzione dello storage. Controllate separatamente i permessi effettivamente necessari; non confondete un rifiuto locale con un rifiuto di autorizzazione remoto.
Quando è necessaria una modifica dello schema, preparatela con il meccanismo di migrazione esistente. Verificate l’ordine di distribuzione tra il database e il codice, le vecchie istanze ancora attive e il modo in cui leggono i nuovi dati. Una scrittura correttamente estesa può sempre essere letta erroneamente da un’istanza che conserva la vecchia validazione.
Evitate di conservare ulteriori segreti per facilitare il confronto. La vostra prova può registrare « uguaglianza verificata » e il nome dello scenario di test, senza conservare il valore. Una memorizzazione temporanea deve mantenere la sua scadenza e i suoi controlli di accesso. Il lavoro riguarda il trasporto fedele, non la moltiplicazione delle copie.
Preparare il 30 novembre e la sorveglianza
L'annuncio del 15 maggio presentava un'intestazione temporanea che permetteva di scegliere il comportamento di generazione durante la transizione. Rimane un contesto storico, distinto dalla fine del dispiegamento annunciata in ottobre. Annuncio dell'intestazione di transizione.
Elencate i componenti che utilizzano ancora questa intestazione. Assegnate la rimozione a una versione di consegna, con un responsabile e un test di compatibilità. La scadenza del 30 novembre annunciata da GitHub deve figurare nel vostro monitoraggio: un'opzione di transizione non è un meccanismo permanente di retrocessione.
Dopo i test locali, una qualificazione autorizzata su un ambiente GitHub di test può verificare l’ottenimento e l’uso del token, con i diritti minimi necessari. Deve mantenere i segreti fuori dalle catture. Distinguete nel vostro bilancio ciò che il trasporto simulato ha dimostrato da ciò che questa chiamata reale ha confermato.
Per la sorveglianza, seguite gli errori per componente e per fase: ottenimento, stoccaggio, caricamento, richiesta. Confrontate le tendenze prima e dopo la consegna, senza associare un incidente a un formato solo perché appare nella stessa data. Una risposta di rifiuto può avere diverse cause; il vostro inventario permette di testare l'ipotesi corretta.
Scegliere un ritorno indietro che rimanga compatibile
Un ritorno a una versione precedente che tronca i nuovi token reintrodurrebbe il problema. Preparate quindi una versione di riserva che mantenga la correzione di compatibilità, o un piano di ritiro della modifica funzionale che non ripristini il vincolo precedente. Documentate questo punto prima di avviare la consegna.
Il compito può essere considerato qualificato quando i passaggi reali hanno un responsabile, i test fittizi preservano integralmente il valore, gli errori rimangono senza segreto e la rimozione dell’intestazione temporanea è pianificata. Non viene rivendicato alcun test eseguito su un’integrazione Partitech in questo articolo.
Per la vostra prossima revisione tecnica, scegliete un solo percorso di token di installazione e applicate la griglia dall’inizio alla fine. Otterrete un perimetro di correzione concreto, invece di una riscrittura generale dell’autenticazione. La robustezza utile dipende dalla fedeltà del trasporto e dalla discrezione delle diagnosi, indipendentemente dalla forma attuale del segreto.
Fonti e data di verifica
Fonti aperte il 6 ottobre 2026: fine del dispiegamento, intestazione temporanea di maggio e documentazione GitHub Apps. I test descritti costituiscono un protocollo proposto, senza alcun segreto funzionale né risultato artificiale.