Abbiamo assistito recentemente alla backdoor e all'enorme problema di sicurezza introdotto nella libreria XZ utils. Questo genere di attacco si definisce "supply chain attack" e non è importante quanto tempo ci si metta per realizzarlo, ma l'effetto devastante che avrà. Questo può anche rientrare nella categoria del repo-jacking, in quanto si utilizza un repository particolarmente utilizzato, per esempio nel mondo open source, per iniettare malware, o comunque un qualsiasi genere di contenuto malevolo, che poi andrà a cambiare il comportamento originale del software di quel repository, causando danni agli utilizzatori finali.
In GitHub, per esempio, è molto probabile che facciamo uso di GitHub Actions create da terze parti. Alcune sono più affidabili di altre, in quanto hanno il "bollino" di verified creator rilasciato direttamente da GitHub (es. GitHub stesso, Microsoft, AWS etc.), poiché subiscono un processo di revisione molto stringente, in quanto devono appunto dare qualità. Altre, invece, sono semplicemente open source e di rado ci prendiamo del tempo per fare i dovuti check di sicurezza per validare quel software. Anche avendo persone dedicate, sarebbe opportuno fare dei controlli su base regolare, per verificare ogni singolo aggiornamento delle GitHub Actions e, questo, è sempre più complesso e porta via sempre più tempo.
Tuttavia, se vogliamo stare un po' più tranquilli, possiamo sfruttare una sintassi molto particolare delle GitHub Actions che ci permettono di fare locking su uno specifico commit:
steps: - name: My Action uses: actions/javascript-action@4be183afbd08ddadedcf09f17e8e112326894107
Infatti, anziché usare un numero di versione (come ad esempio solo la major o il classico SemVer a tre cifre), GitHub Actions supporta anche la reference diretta sul commit SHA. Sebbene per un qualche tipo di attacco specifico sia possibile fare tampering dello SHA-1, è un caso estremamente raro. Usare questo meccanismo di linking sui commit ci garantisce una sicurezza in più, in quanto la GitHub Actions non cambierà ad ogni singola run del workflow, ma rimarrà su una versione che abbiamo avuto modo di verificare in modo opportuno con i nostri sistemi o con dei tool appositi.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Ottenere un token di accesso per una GitHub App
Generare velocemente pagine CRUD in Blazor con QuickGrid
Cancellare una run di un workflow di GitHub
Recuperare l'ultima versione di una release di GitHub
Managed deployment strategy in Azure DevOps
.NET Aspire per applicazioni distribuite
Filtering sulle colonne in una QuickGrid di Blazor
Gestione file Javascript in Blazor con .NET 9
Generare la software bill of material (SBOM) in GitHub
Creare una custom property in GitHub
Utilizzare l'espressione if inline in una pipeline di Azure DevOps
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub
I più letti di oggi
- Organizzare i moduli sfruttando CommonJS in Javascript
- .NET Aspire per applicazioni distribuite
- Animare la rotazione di un'immagine dentro un canvas in HTML5
- Importare un file JavaScript in un web worker
- .NET Conference Italia 2024 - Milano
- La nostra prova su strada di Windows Phone 7
- Utilizzare Hybrid Cache in .NET 9
- Autenticazione di git tramite Microsoft Entra ID in Azure DevOps