Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modifica dei controlli di origine dei pacchetti

In Amazon CodeCatalyst, le versioni dei pacchetti possono essere aggiunte a un archivio di pacchetti pubblicandole direttamente, estraendole da un repository upstream o importandole da un archivio pubblico esterno tramite un gateway. Se consenti l'aggiunta di versioni di un pacchetto sia tramite pubblicazione diretta che tramite acquisizione da archivi pubblici, sei vulnerabile a un attacco di sostituzione delle dipendenze. Per ulteriori informazioni, consulta Attacchi di sostituzione delle dipendenze. Per proteggerti da un attacco di sostituzione delle dipendenze, configura i controlli di origine dei pacchetti su un pacchetto in un repository per limitare il modo in cui le versioni di quel pacchetto possono essere aggiunte al repository.

Dovresti prendere in considerazione la possibilità di configurare i controlli di origine dei pacchetti per fare in modo che le nuove versioni di pacchetti diversi provengano sia da fonti interne, come la pubblicazione diretta, sia da fonti esterne, come gli archivi pubblici. Per impostazione predefinita, i controlli di origine dei pacchetti sono configurati in base al modo in cui la prima versione di un pacchetto viene aggiunta all'archivio.

Impostazioni di controllo dell'origine del pacchetto

Con i controlli sull'origine dei pacchetti, è possibile configurare il modo in cui le versioni dei pacchetti possono essere aggiunte a un repository. Gli elenchi seguenti includono le impostazioni e i valori disponibili per il controllo dell'origine dei pacchetti.

Pubblicare

Questa impostazione configura se le versioni dei pacchetti possono essere pubblicate direttamente nel repository utilizzando gestori di pacchetti o strumenti simili.

A monte

Questa impostazione configura se le versioni dei pacchetti possono essere importate da archivi pubblici esterni o conservate dagli archivi upstream quando richiesto da un gestore di pacchetti.

Impostazioni predefinite per il controllo dell'origine dei pacchetti

I controlli di origine del pacchetto predefiniti per un pacchetto si baseranno su come la prima versione di quel pacchetto viene aggiunta all'archivio dei pacchetti.

Scenari comuni di controllo dell'accesso ai pacchetti

Questa sezione descrive alcuni scenari comuni di aggiunta di una versione del pacchetto a un repository di CodeCatalyst pacchetti. Le impostazioni di controllo dell'origine dei pacchetti vengono impostate per i nuovi pacchetti a seconda di come viene aggiunta la prima versione del pacchetto.

Nei seguenti scenari, un pacchetto interno viene pubblicato direttamente da un gestore di pacchetti nel repository, ad esempio un pacchetto gestito dall'utente. Un pacchetto esterno è un pacchetto esistente in un archivio pubblico che può essere inserito nel repository dell'utente tramite un repository gateway upstream.

Viene pubblicata una versione esterna del pacchetto per un pacchetto interno esistente

In questo scenario, si consideri un pacchetto interno, PackageA. Il tuo team pubblica la prima versione del pacchetto per PackageA in un archivio di pacchetti. CodeCatalyst Poiché questa è la prima versione del pacchetto, le impostazioni di controllo dell'origine del pacchetto vengono impostate automaticamente su Pubblica: Consenti e Upstream: Block. Dopo la pubblicazione del pacchetto nel repository, un pacchetto con lo stesso nome viene pubblicato in un archivio pubblico collegato all'archivio dei pacchetti. CodeCatalyst Potrebbe trattarsi di un tentativo di attacco di sostituzione delle dipendenze contro il pacchetto interno o potrebbe essere una coincidenza. In ogni caso, i controlli di origine dei pacchetti sono configurati per bloccare l'ingestione della nuova versione esterna per proteggersi da un potenziale attacco.

Nell'immagine seguente, RePoA è il tuo repository di CodeCatalyst pacchetti con una connessione upstream al repository. npm-public-registry-gateway Il tuo repository contiene le versioni 1.1 e 2.1 di PackageA, ma la versione 3.0 è pubblicata nell'archivio pubblico. Normalmente, RePoA inserisce la versione 3.0 dopo che il pacchetto è stato richiesto da un gestore di pacchetti. Poiché l'ingestione dei pacchetti è impostata su Block, la versione 3.0 non viene inserita nell'archivio dei pacchetti e non è disponibile per i gestori di CodeCatalyst pacchetti ad esso collegati.

Viene pubblicata una versione interna del pacchetto per un pacchetto esterno esistente

In questo scenario, un pacchetto, PackageB, esiste esternamente in un repository pubblico collegato al repository. Quando un gestore di pacchetti connesso al tuo repository richiede PackageB, la versione del pacchetto viene inserita nel tuo repository dal repository pubblico. Poiché questa è la prima versione del pacchetto di PackageB aggiunta al tuo repository, le impostazioni di origine del pacchetto sono configurate su Publish: e Upstream:. BLOCK ALLOW Successivamente, si tenta di pubblicare una versione con lo stesso nome di pacchetto nel repository. È possibile che non siate a conoscenza del pacchetto pubblico e stiate cercando di pubblicare un pacchetto non correlato con lo stesso nome, oppure state tentando di pubblicare una versione con patch o forse state tentando di pubblicare direttamente la versione esatta del pacchetto che già esiste esternamente. CodeCatalyst rifiuta la versione che state tentando di pubblicare, ma potete ignorare esplicitamente il rifiuto e pubblicare la versione, se necessario.

Nell'immagine seguente, RePoA è il tuo repository di CodeCatalyst pacchetti con una connessione upstream al repository. npm-public-registry-gateway L'archivio dei pacchetti contiene la versione 3.0 che ha acquisito dal repository pubblico. Vuoi pubblicare la versione 1.2 nel tuo repository di pacchetti. In genere, è possibile pubblicare la versione 1.2 su RePoA, ma poiché la pubblicazione è impostata su Block, la versione 1.2 non può essere pubblicata.

Pubblicazione di una versione patchata di un pacchetto esterno esistente

In questo scenario, un pacchetto, PackageB, esiste esternamente in un archivio pubblico collegato all'archivio dei pacchetti. Quando un gestore di pacchetti collegato al tuo repository richiede PackageB, la versione del pacchetto viene inserita nel tuo repository dal repository pubblico. Poiché questa è la prima versione del pacchetto di PackageB aggiunta al tuo repository, le impostazioni di origine del pacchetto sono configurate su Publish: e Upstream:. BLOCK ALLOW Il tuo team decide di pubblicare le versioni del pacchetto con patch di questo pacchetto nel repository. Per poter pubblicare direttamente le versioni dei pacchetti, il team modifica le impostazioni di controllo dell'origine del pacchetto in Publish: ALLOW e Upstream:. BLOCK Le versioni di questo pacchetto possono ora essere pubblicate direttamente nel repository e importate da archivi pubblici. Dopo che il team ha pubblicato le versioni del pacchetto con patch, ripristina le impostazioni di origine del pacchetto su Publish: e Upstream:. BLOCK ALLOW

Modifica dei controlli di origine dei pacchetti

I controlli di origine dei pacchetti vengono configurati automaticamente in base al modo in cui la prima versione di un pacchetto viene aggiunta all'archivio dei pacchetti. Per ulteriori informazioni, consulta Impostazioni predefinite per il controllo dell'origine dei pacchetti. Per aggiungere o modificare i controlli di origine dei pacchetti per un pacchetto in un archivio dei CodeCatalyst pacchetti, effettuate i passaggi indicati nella procedura seguente.

Archiviazione e archivi upstream

In CodeCatalyst, non è possibile pubblicare versioni di pacchetti presenti in repository upstream raggiungibili o in repository pubblici. Ad esempio, supponiamo di voler pubblicare un pacchetto npm in un repository e myrepo di disporre di un repository upstream con una myrepo connessione esterna lodash@1.0 a npmjs.com. Considerate i seguenti scenari.

Attacchi di sostituzione delle dipendenze

I Package Manager semplificano il processo di imballaggio e condivisione del codice riutilizzabile. Questi pacchetti possono essere pacchetti privati sviluppati da un'organizzazione per essere utilizzati nelle proprie applicazioni, oppure possono essere pacchetti pubblici, in genere pacchetti open source sviluppati all'esterno di un'organizzazione e distribuiti da archivi di pacchetti pubblici. Quando richiedono pacchetti, gli sviluppatori si affidano al proprio gestore di pacchetti per recuperare nuove versioni delle proprie dipendenze. Gli attacchi di sostituzione delle dipendenze, noti anche come attacchi basati sulla confusione delle dipendenze, sfruttano il fatto che un gestore di pacchetti in genere non ha modo di distinguere le versioni legittime di un pacchetto da quelle dannose.

Gli attacchi di sostituzione delle dipendenze appartengono a un sottoinsieme di attacchi noti come attacchi alla catena di fornitura del software. Un attacco alla catena di fornitura del software è un attacco che sfrutta le vulnerabilità in qualsiasi punto della catena di fornitura del software.

Un attacco basato sulla sostituzione delle dipendenze può colpire chiunque utilizzi sia pacchetti sviluppati internamente sia pacchetti recuperati da archivi pubblici. Gli aggressori identificano i nomi interni dei pacchetti e quindi posizionano strategicamente il codice dannoso con lo stesso nome negli archivi pubblici dei pacchetti. In genere, il codice dannoso viene pubblicato in un pacchetto con un numero di versione elevato. I gestori di pacchetti recuperano il codice dannoso da questi feed pubblici perché ritengono che i pacchetti dannosi siano le versioni più recenti del pacchetto. Ciò causa una «confusione» o una «sostituzione» tra il pacchetto desiderato e il pacchetto dannoso, con conseguente compromissione del codice.

Per prevenire attacchi di sostituzione delle dipendenze, Amazon CodeCatalyst fornisce controlli sull'origine dei pacchetti. I controlli di origine dei pacchetti sono impostazioni che controllano il modo in cui i pacchetti possono essere aggiunti ai repository. I controlli vengono configurati automaticamente quando la prima versione del pacchetto di un nuovo pacchetto viene aggiunta a un CodeCatalyst repository. I controlli possono garantire che le versioni dei pacchetti non possano essere sia pubblicate direttamente nel repository sia importate da fonti pubbliche, proteggendo così l'utente dagli attacchi di sostituzione delle dipendenze. Per ulteriori informazioni sui controlli di origine dei pacchetti e su come modificarli, consulta. Modifica dei controlli di origine dei pacchetti