Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md). 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à. # Pubblicazione e modifica di pacchetti Un *pacchetto* in CodeCatalyst è un insieme di software e metadati necessari per risolvere le dipendenze e installare il software. Per un elenco dei formati di pacchetto supportati in CodeCatalyst, vedere. [Pubblica e condividi pacchetti software in CodeCatalyst](packages.md) Questa sezione fornisce informazioni sulla pubblicazione, la visualizzazione, l'eliminazione dei pacchetti e l'aggiornamento dello stato di una versione del pacchetto. **Topics** + [Pubblicazione di pacchetti in un archivio di CodeCatalyst pacchetti](package-publishing.md) + [Visualizzazione dei dettagli della versione del pacchetto](working-with-packages-view.md) + [Eliminazione di una versione del pacchetto](working-with-packages-delete.md) + [Aggiornamento dello stato di una versione del pacchetto](working-with-packages-update-version-status.md) + [Modifica dei controlli di origine dei pacchetti](package-origin-controls.md) # Pubblicazione di pacchetti in un archivio di CodeCatalyst pacchetti È possibile pubblicare versioni di qualsiasi tipo di pacchetto supportato in un archivio di CodeCatalyst pacchetti utilizzando gli strumenti di gestione dei pacchetti. I passaggi per pubblicare una versione del pacchetto sono i seguenti: **Per pubblicare una versione del pacchetto in un archivio di CodeCatalyst pacchetti** 1. In caso contrario, [crea un archivio di pacchetti](packages-repositories-create.md). 1. Connect il gestore di pacchetti al repository dei pacchetti. Per istruzioni su come connettere il gestore di pacchetti npm a un repository di CodeCatalyst pacchetti, vedi. [Configurazione e utilizzo di npm](packages-npm-use.md) 1. Usa il tuo gestore di pacchetti connesso per pubblicare le versioni dei pacchetti. **Contents** + [Pubblicazione e repository upstream](#package-publishing-upstreams) + [Pacchetti privati e archivi pubblici](#package-publishing-upstreams-direct) + [Sovrascrivere le risorse del](#package-publishing-overwrite-assets) ## Pubblicazione e repository 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 di pacchetti e di essere connesso a npmjs.com tramite un repository `myrepo` gateway configurato come repository upstream. `lodash@1.0` `myrepo` Se `lodash@1.0` è presente nel repository upstream o in npmjs.com, rifiuta qualsiasi tentativo di pubblicazione su di esso emettendo un errore di conflitto 409. CodeCatalyst `myrepo` Ciò consente di evitare la pubblicazione accidentale di un pacchetto con lo stesso nome e la stessa versione di un pacchetto in un repository upstream, il che può causare un comportamento imprevisto. È comunque possibile pubblicare versioni diverse del nome di pacchetto che esistono in un repository upstream. Ad esempio, se `lodash@1.0` è presente in un repository upstream ma non lo è, `lodash@1.1` è possibile pubblicarlo `lodash@1.1` nel repository downstream. ## Pacchetti privati e archivi pubblici CodeCatalyst non pubblica i pacchetti archiviati negli CodeCatalyst archivi in archivi pubblici, come npmjs.com o Maven Central. CodeCatalyst importa pacchetti da repository pubblici in un CodeCatalyst repository, ma non sposta i pacchetti nella direzione opposta. I pacchetti pubblicati CodeCatalyst nei repository rimangono privati e sono disponibili solo per il CodeCatalyst progetto a cui appartiene il repository. ## Sovrascrivere le risorse del Non è possibile ripubblicare una risorsa del pacchetto già esistente con contenuti diversi. Ad esempio, supponete di aver già pubblicato un pacchetto Maven con una risorsa JAR. `mypackage-1.0.jar` Puoi pubblicare nuovamente quella risorsa solo se il checksum delle risorse vecchie e nuove è identico. Per ripubblicare la stessa risorsa con nuovi contenuti, eliminate prima la versione del pacchetto. Il tentativo di ripubblicare lo stesso nome di risorsa con contenuti diversi genererà un errore di conflitto HTTP 409. Per i formati di pacchetto che supportano più risorse (Python e Maven), puoi aggiungere nuove risorse con nomi diversi a una versione del pacchetto esistente in qualsiasi momento, supponendo che tu disponga delle autorizzazioni richieste. Poiché npm supporta NuGet solo una singola risorsa per versione del pacchetto, per modificare una versione del pacchetto pubblicata devi prima eliminarla. Se provate a ripubblicare una risorsa già esistente (ad esempio`mypackage-1.0.jar`) e il contenuto della risorsa pubblicata e della nuova risorsa sono identici, l'operazione avrà successo perché l'operazione è idempotente. # Visualizzazione dei dettagli della versione del pacchetto È possibile utilizzare la CodeCatalyst console per visualizzare i dettagli su una versione specifica del pacchetto. **Per visualizzare i dettagli della versione del pacchetto** 1. Nel riquadro di navigazione scegliere **Pacchetti**. 1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto di cui desideri visualizzare i dettagli. 1. Cerca la versione del pacchetto nella tabella **Pacchetti**. È possibile utilizzare la barra di ricerca per filtrare i pacchetti in base al nome e al formato del pacchetto. Scegli il pacchetto dall'elenco. 1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni**, quindi scegli la versione che desideri visualizzare. # Eliminazione di una versione del pacchetto È possibile eliminare una versione del pacchetto dalla pagina dei **dettagli della versione del pacchetto** nella CodeCatalyst console. **Per eliminare una versione del pacchetto** 1. Nel riquadro di navigazione scegliere **Pacchetti**. 1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto che desideri eliminare. 1. Cerca e scegli il pacchetto dalla tabella. 1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni** e scegli la versione che desideri eliminare. 1. Nella pagina dei **dettagli della versione del Package**, scegli **Azioni versione**, quindi scegli **Elimina**. 1. Inserisci *delete* nel campo di testo e scegli **Elimina**. # Aggiornamento dello stato di una versione del pacchetto Ogni versione del pacchetto in CodeCatalyst ha uno stato che descrive lo stato attuale e la disponibilità della versione del pacchetto. È possibile modificare lo stato della versione del pacchetto nella CodeCatalyst console. Per ulteriori informazioni sui possibili valori di stato delle versioni dei pacchetti e sui relativi significati, vedere[Stato della versione del pacchetto](#package-version-status). **Per aggiornare lo stato di una versione del pacchetto** 1. Nel riquadro di navigazione scegliere **Pacchetti**. 1. Nella pagina **Package repository**, scegli il repository che contiene la versione del pacchetto di cui vuoi aggiornare lo stato. 1. Cerca e scegli il pacchetto dalla tabella. 1. Nella pagina dei **dettagli del pacchetto**, scegli **Versioni**, quindi scegli la versione che desideri visualizzare. 1. Nella pagina dei **dettagli della versione del Package**, scegli **Azioni**, quindi scegli **Rimuovi dalla lista**, **Archivia** o **Elimina**. Per informazioni sullo stato di ogni versione del pacchetto, consulta. [Stato della versione del pacchetto](#package-version-status) 1. Inserisci il testo di conferma nel campo di testo, quindi scegli Rimuovi **dalla lista**, **Archivia** o **Elimina**, a seconda dello stato a cui stai effettuando l'aggiornamento. ## Stato della versione del pacchetto Di seguito sono riportati i valori possibili per lo stato della versione del pacchetto. È possibile modificare lo stato della versione del pacchetto nella console. Per ulteriori informazioni, consulta [Aggiornamento dello stato di una versione del pacchetto](#working-with-packages-update-version-status). + **Pubblicato**: la versione del pacchetto è stata pubblicata correttamente e può essere richiesta da un gestore di pacchetti. La versione del pacchetto verrà inclusa negli elenchi delle versioni dei pacchetti restituiti ai gestori di pacchetti; ad esempio, nell'output di`npm view versions`. Tutte le risorse della versione del pacchetto sono disponibili nel repository. + **Non completato**: l’ultimo tentativo di pubblicazione non è stato completato. **Attualmente solo le versioni dei pacchetti Maven possono avere lo stato Incompiuto.** Ciò può verificarsi quando il client carica una o più risorse per una versione del pacchetto ma non pubblica un `maven-metadata.xml` file per il pacchetto che include quella versione. + **Non in elenco**: gli asset della versione del pacchetto possono essere scaricati dal repository, ma la versione del pacchetto non è inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Ad esempio, per un pacchetto npm, l'output di `npm view versions` non include la versione del pacchetto. Ciò significa che la logica di risoluzione delle dipendenze di npm non seleziona la versione del pacchetto perché la versione non compare nell'elenco delle versioni disponibili. Tuttavia, se la versione del pacchetto **Unlisted** è già referenziata in un `npm package-lock.json` file, può comunque essere scaricata e installata; ad esempio, durante l'esecuzione. `npm ci` + **Archiviato: gli** asset della versione del pacchetto non possono essere scaricati. La versione del pacchetto non verrà inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Poiché gli asset non sono disponibili, il consumo della versione del pacchetto da parte dei client è bloccato. Se la compilazione dell'applicazione dipende da una versione aggiornata a **Archived**, la compilazione avrà esito negativo, a meno che la versione del pacchetto non sia stata memorizzata nella cache locale. Non puoi utilizzare un gestore di pacchetti o uno strumento di compilazione per ripubblicare una versione del pacchetto **archiviato** perché è ancora presente nel repository. Tuttavia, puoi modificare lo stato della versione del pacchetto riportandolo a **Non in elenco** o **Pubblicato** nella console. + **Eliminata**: la versione del pacchetto non viene visualizzata negli elenchi e le risorse non possono essere scaricate dal repository. La differenza fondamentale tra **Disposed** e **Archived** è che con lo stato **Disposed**, le risorse della versione del pacchetto vengono eliminate definitivamente da. CodeCatalyst ****Per questo motivo, non è possibile spostare una versione del pacchetto da **Disposed** a **Archiviata, Non elencata** o Pubblicata.**** La versione del pacchetto non può essere utilizzata perché le risorse sono state eliminate. Quando una versione del pacchetto è contrassegnata come **Disposta**, non vi viene addebitata alcuna fattura per l'archiviazione delle risorse del pacchetto. Oltre agli stati nell'elenco precedente, è possibile eliminare anche una versione del pacchetto. Una volta eliminata, la versione del pacchetto non è più presente nell'archivio ed è possibile ripubblicare liberamente quella versione del pacchetto utilizzando un gestore di pacchetti o uno strumento di compilazione. ## Nome del pacchetto, versione del pacchetto e normalizzazione del nome dell'asset CodeCatalyst normalizza i nomi dei pacchetti, le versioni dei pacchetti e i nomi delle risorse prima di archiviarli, il che significa che i nomi o le versioni CodeCatalyst possono essere diversi dal nome o dalla versione forniti al momento della pubblicazione del pacchetto. Per ulteriori informazioni su come vengono normalizzati i nomi e le versioni CodeCatalyst per ogni tipo di pacchetto, consultate la seguente documentazione. + [Normalizzazione dei nomi dei pacchetti in Python](python-name-normalization.md) + [NuGet normalizzazione del nome del pacchetto, della versione e del nome dell'asset](nuget-name-normalization.md) CodeCatalyst non esegue la normalizzazione su altri formati di pacchetti. # 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](#dependency-substitution-attacks). 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. + **ALLOW**: le versioni dei Package possono essere pubblicate direttamente. + **BLOCK**: Le versioni dei pacchetti non possono essere pubblicate direttamente. **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. + **CONSENTI**: qualsiasi versione del pacchetto può essere conservata da altri CodeCatalyst repository configurati come archivi upstream o importata da una fonte pubblica con una connessione esterna. + **BLOCK**: le versioni dei pacchetti non possono essere conservate da altri CodeCatalyst repository configurati come repository upstream o importate da una fonte pubblica con una connessione esterna. ### 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. + Se la prima versione del pacchetto viene pubblicata direttamente da un gestore di pacchetti, le impostazioni saranno **Publish: ALLOW e **Upstream**: BLOCK**. + **Se la prima versione del pacchetto viene importata da una fonte pubblica, le impostazioni saranno **Publish: BLOCK e Upstream:** ALLOW.** ## 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. ![\[Grafica semplice che mostra una nuova versione esterna del pacchetto bloccata da un archivio pubblico.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png) **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 repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: 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. ![\[Grafica semplice che mostra la pubblicazione dei pacchetti bloccata.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png) **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 repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: 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**: BLOCK e Upstream: 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](#default-package-origin-control-settings). 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. **Per aggiungere o modificare i controlli di origine del pacchetto** 1. Nel riquadro di navigazione scegliere **Pacchetti**. 1. Scegliete l'archivio del pacchetto che contiene il pacchetto che desiderate modificare. 1. Nella tabella **Pacchetti**, cercate e scegliete il pacchetto che desiderate modificare. 1. Dalla pagina di riepilogo del pacchetto, scegli **Origin controls**. 1. In **Origin controls**, scegli i controlli di origine del pacchetto che desideri impostare per questo pacchetto. Entrambe le impostazioni di controllo dell'origine del pacchetto, **Publish** e **Upstream**, devono essere impostate contemporaneamente. + Per consentire la pubblicazione diretta delle versioni dei pacchetti, in **Pubblica**, scegli **Consenti**. Per bloccare la pubblicazione delle versioni dei pacchetti, scegli **Blocca**. + ****Per consentire l'inserimento di pacchetti da repository esterni e l'estrazione di pacchetti da repository upstream, in Origini upstream, scegli Consenti.**** **Per bloccare tutte le importazioni e l'estrazione di versioni di pacchetti da repository esterni e upstream, scegliete Blocca.** 1. Scegli **Save** (Salva). ## 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. 1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: ALLOW** e **Upstream: ALLOW**. Se `lodash@1.0` è presente nel repository upstream o in npmjs.com, CodeCatalyst rifiuta qualsiasi tentativo di pubblicazione su di esso generando un errore di conflitto 409. `myrepo` È comunque possibile pubblicare una versione diversa, ad esempio. `lodash@1.1` 1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: ALLOW** e **Upstream: BLOCK**. Puoi pubblicare nel tuo repository qualsiasi versione `lodash` di che non esista già perché le versioni del pacchetto non sono raggiungibili. 1. Le impostazioni di controllo dell'origine del pacchetto `lodash` sono **Publish: BLOCK** e **Upstream**: ALLOW. Non puoi pubblicare alcuna versione del pacchetto direttamente nel tuo repository. ## 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](#package-origin-controls)