Argomento #1: Il rallentamento
When the concept of DevSecOps was first introduced, one of the first arguments that companies offered against it was that, instead of encouraging agility, foregrounding security would slow application development down. This can happen, but only if companies don’t sufficiently automate the security code review process. As long as that happens, though, DevSecOps doesn’t actually make application development and deployment slower. It can even be faster than the older DevOps model.
In che modo DevSecOps accelera il processo di sviluppo dell'applicazione? Quando crei un'applicazione e poi aspetti fino alla fine per integrare gli elementi di sicurezza, devi trovare un modo per adattare questi componenti vitali all'infrastruttura esistente. È come costruire una torre e poi cercare di inserire una trave al centro dopo che è stata fatta. Potrebbe essere possibile, ma dovrai interrompere tutto ciò che hai già fatto. Se, d'altra parte, si sceglie di spostarsi a sinistra e di aumentare la sicurezza man mano che si procede, si finisce per avere un sistema più forte e pezzi che si incastrano perfettamente.
Argument #2: More Breaches
It may sound ridiculous, but if you talk to some DevOps-focused businesses, you’ll occasionally hear people say that a DevSecOps approach leads to more security breaches, not fewer. Like other assertions about DevSecOps, though, this one is also rooted in serious misunderstandings of the practice. While top DevSecOps users report more breaches than their DevOps counterparts, experts agree that this is only because they’re aware of those breaches, not because they actually experience more of them. DevOps-based companies simply can’t detect security breaches.
Obviously, it’s better for businesses to be aware of potential or actual security risks because that enables them to actually address and remedy their weaknesses, but many businesses are hesitant to admit that they’re at risk. It’s important for companies to acknowledge that DevSecOps enables risk detection, and that acknowledging breaches is less likely to damage a company than being oblivious to digital attacks.
Argument #3: Expensive Implementation
I cambiamenti nelle pratiche commerciali possono essere costosi. Sia che tu stia passando da un vecchio set di programmi o cambiando linguaggi di programmazione, qualsiasi cambiamento significativo può mettere in pausa l'attività e far perdere contratti e profitti. Questo vale anche per il passaggio a DevSecOps? Mentre, nel breve termine, supportare i membri del team nell'apprendimento di nuovi sistemi può rallentare il processo, nel lungo periodo DevSecOps può massimizzare il ROI.
In che modo un approccio DevSecOps può rendere la tua azienda più redditizia? Certamente, è finanziariamente vantaggioso prevenire gravi problemi di sicurezza prima che si verifichino ed essere in grado di agire rapidamente quando si è sotto attacco, ma non è l'unica ragione. Ricordiamo l'argomentazione di cui sopra secondo cui DevSecOps crea effettivamente un sistema più agile, che si avvia e si aggiorna più rapidamente di quanto sarebbe possibile con un approccio DevOps. Il supporto di esperti può anche aiutare le aziende ad automatizzare la propria infrastruttura di sicurezza, semplificando un processo altamente tecnico e dispendioso in termini di tempo.
Argomento #4: Silos di processo
DevOps highlights two main elements of the application creation process – the development side and the operations, or customer-facing, side – but despite the shorthand conjunction of the two, it doesn’t really connect them. A DevOps approach still allows professionals to work within their familiar siloes. Developers build apps that enable smoother operations, and operations teams may provide guidance and feedback, but they don’t really have to work together. That all changes when companies shift-left to DevSecOps, and that’s a key reason why businesses have been reticent to make the change.
In genere, gli sviluppatori dell'applicazione e i professionisti della sicurezza hanno lavorato sui progetti separatamente, poiché le funzionalità di sicurezza sono state aggiunte all'applicazione in una fase successiva del processo di codifica. Tuttavia, quando le funzionalità di base per lo sviluppo e la sicurezza vengono create contemporaneamente, questi team precedentemente isolati devono riunirsi. Per farlo con successo, la leadership deve facilitare la comunicazione tra i team e incoraggiare la formazione incrociata. Gli esperti di sicurezza potrebbero non essere programmatori professionisti, ma possono fornire indicazioni agli sviluppatori. E, al contrario, gli sviluppatori devono riconoscere che la sicurezza è una priorità funzionale.
Aumentare le comunicazioni tra sviluppatori e professionisti della sicurezza è particolarmente importante perché l’attuale tendenza a isolare le informazioni in silos è responsabile di molte violazioni Cloud Security . Infatti, una recente ricerca suggerisce che il 60% delle violazioni si verifica nel cloud pubblico (il lato utente dell'applicazione) a causa di deployment impropria. Gli sviluppatori semplicemente non prendono buone decisioni di configurazione quando si tratta di deployment del cloud, almeno non senza supporto, e questo lascia le aziende esposte agli attacchi. Il passaggio a una prospettiva DevSecOps colma questa lacuna, ma può anche aumentare le difese degli sviluppatori che pensano di utilizzare già le migliori pratiche.
Arrivare a DevSecOps
These four arguments are just some of the reasons that businesses have been slow to shift-left and adopt a DevSecOps approach, but they’re hardly the only ones. Like so many other changes, companies are resistant to change, even when it’s in their best interest. The problem is that sometimes you have to let go of the old ways in order to be successful.
If your business is stuck in the old DevOps mentality, it’s time to move forward – and Check Point can help. Contact us today for a free security assessment and to learn more about how DevSecOps can benefit your company. Making a big change isn’t easy, but with the right support, you’ll see big improvements.
Feedback