npm evolve le configurazioni di pubblicazione attendibile mentre GitHub aggiunge una condizione di merge legata ai segreti esposti. Questi due annunci non costituiscono un unico blocco: occorre esaminare separatamente i diritti di merge, le identità di pubblicazione e l'approvazione della pubblicazione.
Due annunci, due punti decisionali
Il 3 settembre 2026 npm ha annunciato la disponibilità generale di più configurazioni di pubblicazione attendibile per pacchetto. Sono indipendenti e additive: la corrispondenza con una di esse può essere sufficiente, senza un ordine di valutazione garantito. La messa in attesa è proposta per impostazione predefinita; la pubblicazione diretta è un'opzione specifica di ciascuna configurazione. L'approvazione di un pacchetto in attesa diventa possibile dopo la fine dell'analisi di software dannoso. Questa analisi esisteva già. [annuncio npm]
Il 9 settembre GitHub ha presentato in anteprima pubblica una regola per i clienti GitHub Secret Protection o GitHub Advanced Security: prima del merge, l'analisi del commit di testa deve essere terminata e nessun avviso pertinente introdotto dai commit della pull request deve restare aperto. Le categorie rilevate sono configurabili e i diritti di aggiramento devono essere esaminati. Questa regola completa la protezione al momento dell'invio del codice, senza sostituirla. [annuncio GitHub]
Descrivere ogni diritto prima della catena di distribuzione
CI/CD indica l'integrazione e la distribuzione continue: la catena che costruisce, controlla e distribuisce un software. Una pull request è una proposta di modifica; un workflow è un insieme di passaggi automatizzati. OIDC, OpenID Connect, permette qui di identificare il workflow mediante un token di breve durata. Questa identità non descrive da sola tutte le autorizzazioni del team.
La revisione proposta da Partitech inizia dai percorsi possibili: repository, workflow, ambiente, responsabile e possibilità di pubblicazione diretta. Una configurazione aggiuntiva deve avere un proprietario e una giustificazione. Conservate anche gli account e i meccanismi che possono aggirare il percorso nominale, invece di limitare l'inventario al file di automazione più visibile.
| Percorso o azione | Identità / repository / workflow | Ambiente e criteri | Pubblicazione diretta o eccezione | Proprietario e prova |
|---|---|---|---|---|
| Merge GitHub | Da inventariare | Da rilevare | Aggiramento da esaminare | Da designare / allegare |
| Configurazione stable | Da inventariare | Da rilevare | Da verificare | Da designare / allegare |
| Configurazione prepublication | Da inventariare | Da rilevare | Da verificare | Da designare / allegare |
| Approvazione del pacchetto in attesa | Da inventariare | Da rilevare | Da documentare | Da designare / allegare |
Un modello OR tra configurazioni, non una doppia validazione
In questo esempio fittizio, A indica la configurazione del workflow stable e B quella di prepublication. La tabella illustra soltanto la corrispondenza del token OIDC con le configurazioni. Non sostituisce gli altri controlli e non significa che il pacchetto diventi immediatamente pubblico.
| Configurazione A soddisfatta | Configurazione B soddisfatta | Percorso OIDC corrispondente |
|---|---|---|
| No | No | No |
| Sì | No | Sì |
| No | Sì | Sì |
| Sì | Sì | Sì |
L'approvazione umana del pacchetto messo in attesa è un passaggio distinto: non è il secondo termine di questa condizione OR. Durante la revisione, chiedete per ciascun percorso quali prove siano conservate, chi possa modificarne i criteri e quale decisione giustifichi un'eventuale pubblicazione diretta.
Collegare le prove senza confondere i controlli
Un avviso chiuso non attesta la revoca di un segreto. A seconda del fornitore interessato, documentate la revoca o la rotazione, verificate gli utilizzi coinvolti e conservate la decisione di trattamento. L'assenza di un avviso significa soltanto che nessun avviso pertinente è aperto nel perimetro controllato; non prova un rilevamento esaustivo.
La progettazione proposta separa revisione della modifica, analisi dei segreti, test dell'applicazione, identità npm, messa in attesa e approvazione. Ogni fase conserva il proprio responsabile e la propria prova. Non si presume alcuna sequenza atomica tra merge e pubblicazione. Il principio di fiducia esplicita si collega al nostro articolo sulle scritture degli agenti e il loro ambiente isolato, ma i diritti studiati qui sono quelli della distribuzione GitHub/npm.
Per un pilota autorizzato e isolato, preparate identità fittizie e un pacchetto dimostrativo: nessuna configurazione corrispondente, una corrispondenza, più corrispondenze, analisi ancora in corso ed eccezione di merge. Definite ciò che dovrebbe essere accettato o rifiutato in ogni fase, poi raccogliete i risultati realmente ottenuti. Nessuno di questi scenari è stato eseguito per questo articolo; per la preparazione documentaria non sono necessari né segreti reali né pacchetti di produzione.
Il risultato della revisione è la matrice dei percorsi, accompagnata da responsabili, eccezioni e prove mancanti. Riesaminatela dopo ogni modifica del workflow. L'anteprima GitHub, i limiti di rilevamento e le autorizzazioni residue restano punti da monitorare; il numero di controlli non misura da solo la sicurezza della distribuzione.