Best practice

Quando si implementa un nuovo DevSecOps meccanismo, è fondamentale considerare le varie fonti di creazione del codice e il modo in cui verranno potenziate o potenzialmente bloccate. Spesso, gli ingegneri possono interfacciarsi solo con una di queste fonti. Tuttavia, l'introduzione di un nuovo meccanismo può portare nuove fonti d'autore in primo piano o evidenziare sfide provenienti da fonti non prese in considerazione in precedenza. Esploriamo ciascuno dei seguenti aspetti in modo più dettagliato:

• Sviluppatori del team applicativo: si tratta degli sviluppatori responsabili del codice applicativo di base. Devono avere il potere di apportare modifiche e aggiornamenti al codice dell'applicazione secondo necessità, ma il loro lavoro deve anche essere in linea con il nuovo DevSecOps meccanismo.

• Sviluppatori di infrastrutture centrali: questo team è responsabile dell'infrastruttura principale dell'organizzazione, come le risorse cloud, il networking e la sicurezza. Devono essere coinvolti nella definizione dell'infrastruttura come codice (IaC) e nei processi di implementazione per assicurarsi che il nuovo meccanismo sia integrato senza problemi.

• Basi di codice open source e di terze parti: l'uso di librerie di terze parti e componenti open source è comune. Tuttavia, queste fonti devono essere gestite e protette con cura nell'ambito del nuovo DevSecOps meccanismo.

• Codice e artefatti riutilizzabili: promuovere la creazione e l'uso di codice e artefatti riutilizzabili può migliorare l'efficienza e la coerenza, ma la proprietà e la governance di queste risorse condivise devono essere chiaramente definite.

• Archivi e contributi condivisi: consentire la creazione collaborativa del codice tramite archivi condivisi può essere utile, ma richiede una gestione attenta degli accessi, delle politiche di fusione e delle revisioni del codice per mantenere la qualità e la sicurezza.

• Strategie di ramificazione per IaC — La metodologia Git non è direttamente compatibile con i modelli di progettazione dell'infrastruttura comuni. Potrebbe essere necessario adattare le strategie di ramificazione tradizionali per IaC per far fronte alle sfide uniche della gestione dell'infrastruttura. Ciò potrebbe comportare lo sviluppo di flussi di lavoro specializzati che tengano conto della natura statica dell'infrastruttura, del potenziale di deriva e di un attento coordinamento quando si apportano modifiche agli ambienti live.

• Gestione statale: la gestione dello stato dell'infrastruttura è fondamentale in IaC. Una corretta gestione dello stato garantisce che l'infrastruttura effettiva sia allineata al codice definito e previene conflitti o modifiche non intenzionali. L'implementazione di solide pratiche di gestione dello stato, come l'utilizzo di meccanismi di archiviazione remota dello stato e blocco dello stato, è essenziale per mantenere la coerenza e prevenire i conflitti in ambienti multiutente.

• Sicurezza - Nel contesto di IaC and DevSecOps, la sicurezza deve essere integrata in ogni fase del ciclo di vita dell'infrastruttura. Ciò include la protezione della stessa base di codice IaC, l'implementazione di controlli di accesso con privilegi minimi, la crittografia dei dati sensibili e la scansione regolare delle vulnerabilità sia nel codice dell'infrastruttura che nelle risorse distribuite che ne derivano. I controlli di sicurezza automatizzati e le convalide di conformità devono essere incorporati nella pipeline di integrazione continua e distribuzione continua (CI/CD) per garantire che le migliori pratiche di sicurezza vengano applicate in modo coerente.

La progettazione di un DevSecOps meccanismo che consenta e supporti efficacemente diversi team richiede l'identificazione di tutte le potenziali fonti di paternità del codice e la comprensione delle loro esigenze e sfide. Questo approccio aiuta a garantire un'implementazione e un'adozione fluide del nuovo meccanismo in tutta l'organizzazione.

La progettazione DevSecOps dei meccanismi va ben oltre i semplici aspetti tecnici. La progettazione e l'implementazione dei DevSecOps meccanismi hanno implicazioni di vasta portata. Il team responsabile deve considerare attentamente i fattori culturali, organizzativi e umani. Questa considerazione aiuta a garantire che la soluzione non solo soddisfi i requisiti tecnici, ma promuova anche un ambiente di lavoro positivo, produttivo e coinvolgente per tutte le parti interessate. Trovare il giusto equilibrio è fondamentale per il successo a lungo termine e la soddisfazione dei dipendenti.

Considerate i seguenti scenari relativi alla progettazione e all'implementazione dei DevSecOps meccanismi:

• Amplificazione della disparità tra sviluppatori e manutentori: l'implementazione di un sistema che consenta agli sviluppatori desiderosi di fornire rapidamente soluzioni può inavvertitamente evidenziare l'apparente mancanza di lavoro dei manutentori. I manutentori sono individui con titoli di sviluppatore, ma le loro responsabilità sono passate al supporto e alla stabilità delle applicazioni esistenti. day-to-day La mancanza di nuovi contributi da parte dei manutentori potrebbe essere stata storicamente meno visibile. Questa situazione potrebbe portare l'organizzazione a sottovalutare le conoscenze e le competenze fondamentali di questi addetti alla manutenzione, causando potenzialmente risentimento e un calo del morale.

• Respingere gli sviluppatori con una soluzione troppo regolamentata: la creazione di una soluzione altamente gestita e scomoda da usare per gli sviluppatori DevSecOps desiderosi può attirare i manutentori. Tuttavia, la soluzione potrebbe allontanare le persone di cui l'organizzazione ha bisogno per promuovere l'innovazione. Costringere gli sviluppatori ad apprendere un meccanismo CI/CD proprietario in aggiunta ai loro linguaggi applicativi e di programmazione può essere un ostacolo significativo all'adozione. Una DevSecOps soluzione altamente regolamentata potrebbe diventare un disincentivo per gli sviluppatori di talento.

• Rischio di incompatibilità e sconvolgimento culturale: l'implementazione di un DevSecOps meccanismo culturalmente incompatibile con le modalità di lavoro esistenti dell'organizzazione può creare attriti e resistenze significativi. Se l'approccio del meccanismo (ad esempio, prescrittivo rispetto a quello consultivo) non è in linea con la cultura dell'organizzazione, probabilmente non verrà adottato. Di conseguenza, alcune parti interessate potrebbero sentirsi frustrate e credere che l'organizzazione si stia orientando verso una burocrazia non necessaria.