Sviluppo sicuro e gestione del cambiamento presso CrowdHandler

CrowdHandler segue procedure rigorose per la gestione delle modifiche e l'implementazione di nuove funzionalità in modo sicuro e conforme alle normative. Le nostre moderne politiche includono:

di programmazione sicura#

Ci atteniamo alle linee guida OWASP e ad altre best practice di programmazione sicura, tra cui:

  • Esecuzione di analisi statiche e dinamiche del codice per individuare le vulnerabilità
  • Formazione per gli sviluppatori sui rischi più comuni, quali XSS, attacchi di tipo “injection”, configurazioni non sicure, ecc.
  • Mantenere aggiornate le dipendenze per applicare le patch alle vulnerabilità CVE note
  • Archiviazione sicura dei dati sensibili con accesso limitato
  • Effettuare revisioni del codice tra pari per tutte le nuove funzionalità/modifiche
  • Utilizzo di ambienti distinti per lo sviluppo, il collaudo, lo staging e la produzione al fine di isolare le modifiche

Test automatizzati e continua#

Utilizziamo test automatizzati e pipeline CI/CD, tra cui:

  • Test unitari - Test automatizzati a livello di codice per verificare la funzionalità e gestire i casi limite.
  • Test di integrazione - Test automatizzati volti a verificare l'interoperabilità tra sistemi, API e componenti.
  • Pipeline di distribuzione - Le modifiche avanzano automaticamente attraverso le fasi di compilazione, test e distribuzione. Le pipeline si interrompono in qualsiasi fase in cui i test falliscono, richiedendo correzioni prima di poter procedere.
  • Test canary - Dopo l'implementazione, una percentuale del traffico effettivo viene deviata verso la nuova versione per monitorarne gli effetti prima del lancio completo.

di gestione del cambiamento#

Le modifiche e le nuove funzionalità seguono un processo ben definito:

  1. Documentazione dei requisiti, dei rischi e delle fasi in un registro delle modifiche. Modifiche classificate in base al rischio.
  2. Revisione del progetto basata sulla valutazione dei rischi e sui requisiti di conformità.
  3. Per il merge nel ramo principale è necessario che lo sviluppo avvenga in rami di funzionalità, con revisione del codice da parte dei colleghi e test automatizzati.
  4. Le modifiche vengono distribuite nell'ambiente di staging per l'UAT e, una volta superati i test, vengono sottoposte ad approvazione definitiva.
  5. Implementazione durante la finestra temporale approvata, con notifica in caso di eventuali tempi di inattività previsti. È richiesta una verifica dopo l'implementazione.
  6. Mantenere una traccia di controllo per tutte le modifiche apportate alla produzione.

Le politiche di CrowdHandler riducono al minimo i rischi derivanti da problemi software o da modifiche non adeguatamente testate. L'automazione, i test, le revisioni tra pari e la tracciabilità migliorano la sicurezza e la conformità della nostra applicazione. Le modifiche passano attraverso diversi ambienti e controlli prima di essere distribuite in produzione.