Amazon non CodeCatalyst è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta Come migrare da CodeCatalyst.
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 repository di pacchetti pubblicandole direttamente, estraendole da un repository upstream o importandole da un repository pubblico esterno tramite un gateway. Se consenti l'aggiunta di versioni di un pacchetto tramite pubblicazione diretta e importazione da repository 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 sull'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 diversi pacchetti provengano sia da fonti interne, come la pubblicazione diretta, sia da fonti esterne, come i repository 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 al repository.
Impostazioni di controllo dell'origine del pacchetto
Con i controlli sull'origine dei pacchetti, puoi configurare in che modo le versioni dei pacchetti possono essere aggiunte a un repository. I seguenti elenchi 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.
CONSENTI: le versioni dei pacchetti possono essere pubblicate direttamente.
BLOCCA: le versioni dei pacchetti non possono essere pubblicate direttamente.
A monte
Questa impostazione configura se le versioni dei pacchetti possono essere importate da repository pubblici esterni o conservate dai repository upstream quando richiesto da un gestore di pacchetti.
ALLOW: qualsiasi versione del pacchetto può essere conservata da altri CodeCatalyst repository configurati come repository upstream o importata da una fonte pubblica con una connessione esterna.
BLOCCO: le versioni dei pacchetti non possono essere conservate da altri CodeCatalyst repository configurati come repository upstream o importati da una fonte pubblica con una connessione esterna.
Impostazioni predefinite per il controllo dell'origine dei pacchetti
I controlli di origine dei pacchetti predefiniti per un pacchetto si baseranno sul modo in cui la prima versione di quel pacchetto viene aggiunta al repository 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 acquisita 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 in cui una versione del pacchetto viene aggiunta a un repository di CodeCatalyst pacchetti. Le impostazioni di controllo dell'origine dei pacchetti sono impostate per i nuovi pacchetti in base a come viene aggiunta la prima versione del pacchetto.
Nei seguenti scenari, un pacchetto interno viene pubblicato direttamente da un gestore di pacchetti nel tuo repository, ad esempio un pacchetto che gestisci. Un pacchetto esterno è un pacchetto presente in un repository pubblico che può essere inserito nel repository tramite un repository gateway a monte.
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 repository di pacchetti. CodeCatalyst Poiché questa è la prima versione del pacchetto, le impostazioni di controllo dell'origine del pacchetto vengono impostate automaticamente su Publish: Allow e Upstream: Block. Dopo che il pacchetto è stato pubblicato nel tuo repository, un pacchetto con lo stesso nome viene pubblicato in un repository pubblico connesso al tuo CodeCatalyst repository di pacchetti. Potrebbe trattarsi di un tentativo di attacco di sostituzione delle dipendenze contro il pacchetto interno o potrebbe essere una coincidenza. Indipendentemente da ciò, i controlli sull'origine dei pacchetti sono configurati per bloccare l'importazione della nuova versione esterna per proteggersi da un potenziale attacco.
Nell'immagine seguente, RePoA è l'archivio dei 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 nel repository pubblico. Normalmente, RePoA acquisisce la versione 3.0 dopo che il pacchetto è stato richiesto da un gestore di pacchetti. Poiché l'importazione dei pacchetti è impostata su Blocca, la versione 3.0 non viene inserita nel repository dei pacchetti e non è disponibile per i gestori di CodeCatalyst pacchetti ad essa 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 che hai collegato al tuo 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: BLOCK e Upstream: ALLOW. Successivamente, provi a pubblicare una versione con lo stesso nome di pacchetto nel repository. Potresti non essere a conoscenza del pacchetto pubblico e provare a pubblicare un pacchetto non correlato con lo stesso nome, oppure potresti provare a pubblicare una versione con patch o potresti provare a pubblicare direttamente la versione esatta del pacchetto che già esiste esternamente. CodeCatalyst rifiuta la versione che stai tentando di pubblicare, ma puoi sovrascrivere esplicitamente il rifiuto e pubblicare la versione, se necessario.
Nell'immagine seguente, RePoA è l'archivio dei 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 Blocca, 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 repository pubblico che hai connesso al tuo repository di pacchetti. 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: BLOCK e Upstream: ALLOW. Il tuo team decide di pubblicare le versioni patchate 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 tuo repository e inserite da repository 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 del pacchetto viene aggiunta al repository dei pacchetti. Per ulteriori informazioni, consulta Impostazioni predefinite per il controllo dell'origine dei pacchetti. Per aggiungere o modificare i controlli di origine del pacchetto per un pacchetto in un repository di CodeCatalyst pacchetti, esegui i passaggi della procedura seguente.
Per aggiungere o modificare i controlli di origine del pacchetto
-
Nel riquadro di navigazione scegliere Pacchetti.
-
Scegli il repository dei pacchetti che contiene il pacchetto che desideri modificare.
-
Nella tabella Pacchetti, cercate e scegliete il pacchetto che desiderate modificare.
-
Dalla pagina di riepilogo del pacchetto, scegli Origin controls.
-
Nei controlli Origin, 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 del pacchetto, scegli Blocca.
-
Per consentire l'inserimento di pacchetti da repository esterni e il prelievo di pacchetti da repository upstream, nei sorgenti upstream, scegli Consenti. Per bloccare l'acquisizione e l'estrazione delle versioni dei pacchetti da repository esterni e upstream, scegli Blocca.
-
-
Selezionare Salva.
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 e myrepo di disporre di un repository upstream con una myrepo connessione esterna lodash@1.0 a npmjs.com. Considerate i seguenti scenari.
Le impostazioni di controllo dell'origine del pacchetto
lodashsono Publish: ALLOW e Upstream: ALLOW. Selodash@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.1Le impostazioni di controllo dell'origine del pacchetto
lodashsono Publish: ALLOW e Upstream: BLOCK. Puoi pubblicare nel tuo repository qualsiasi versione che non esiste già perché le versioni del pacchetto non sono raggiungibili.lodashLe impostazioni di controllo dell'origine del pacchetto
lodashsono Publish: BLOCK e Upstream: ALLOW. Non puoi pubblicare alcuna versione del pacchetto direttamente nel tuo repository.
Attacchi di sostituzione delle dipendenze
I gestori di pacchetti semplificano il processo di impacchettamento 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 open source, sviluppati all'esterno di un'organizzazione e distribuiti da archivi di pacchetti pubblici. Quando richiedono pacchetti, gli sviluppatori si affidano al loro gestore di pacchetti per recuperare nuove versioni delle loro dipendenze. Gli attacchi di sostituzione delle dipendenze, noti anche come attacchi di 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 di sostituzione delle dipendenze può colpire chiunque utilizzi sia pacchetti sviluppati internamente sia pacchetti recuperati da archivi pubblici. Gli aggressori identificano i nomi dei pacchetti interni e quindi inseriscono strategicamente il codice dannoso con lo stesso nome negli archivi di pacchetti pubblici. 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 fornisce controlli sull'origine dei pacchetti. CodeCatalyst I controlli sull'origine dei pacchetti sono impostazioni che controllano il modo in cui i pacchetti possono essere aggiunti ai tuoi 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 pubblicate direttamente nel repository e inserite da fonti pubbliche, proteggendoti dagli attacchi di sostituzione delle dipendenze. Per ulteriori informazioni sui controlli di origine dei pacchetti e su come modificarli, vedere. Modifica dei controlli di origine dei pacchetti