Argumento nº 1: A desaceleração
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.
Como o DevSecOps acelera o processo de desenvolvimento de aplicativos? Quando o senhor cria um aplicativo e espera até o final para integrar os elementos de segurança, precisa encontrar uma maneira de encaixar esses componentes vitais na infraestrutura existente. É como construir uma torre e, depois de pronta, tentar inserir uma viga no centro. Talvez seja possível, mas o senhor terá que interromper tudo o que já fez. Se, por outro lado, o senhor optar por mudar para a esquerda e criar segurança à medida que avança, acabará com um sistema mais forte e com peças que se encaixam perfeitamente.
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
Mudanças nas práticas comerciais podem ser caras. Quer o senhor esteja fazendo a transição de um conjunto de programas mais antigos ou mudando as linguagens de codificação, qualquer mudança significativa pode paralisar os negócios e fazer com que sua empresa perca contratos e lucros. Isso também é verdade quando se trata de mudar para DevSecOps? Embora, no curto prazo, apoiar os membros da equipe no aprendizado de novos sistemas possa atrasar as coisas, em um período de tempo mais longo, o DevSecOps pode maximizar o ROI.
Como uma abordagem DevSecOps pode tornar sua empresa mais lucrativa? Certamente, é financeiramente vantajoso evitar os principais problemas de segurança antes que eles aconteçam e poder agir rapidamente quando estiver sob ataque, mas esse não é o único motivo. Lembre-se do argumento acima de que o DevSecOps na verdade cria um sistema mais ágil, que é lançado e atualizado mais rapidamente do que seria possível com uma abordagem de DevOps. O suporte especializado também pode ajudar as empresas a automatizar sua infraestrutura de segurança, simplificando um processo demorado e altamente técnico.
Argumento nº 4: Silos de 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.
Em geral, os desenvolvedores de aplicativos e os profissionais de segurança trabalharam em projetos separadamente, porque os recursos de segurança foram adicionados ao aplicativo mais tarde no processo de codificação. No entanto, quando os recursos básicos de desenvolvimento e segurança são criados simultaneamente, essas equipes, antes isoladas, precisam se unir. Para fazer isso com sucesso, a liderança precisa facilitar a comunicação entre as equipes e incentivar o treinamento cruzado. Os especialistas em segurança podem não ser programadores profissionais, mas podem fornecer orientação para os desenvolvedores. E, por outro lado, os desenvolvedores precisam reconhecer que a segurança é uma prioridade funcional.
Aumentar a comunicação entre os desenvolvedores e os profissionais de segurança é especialmente importante porque a tendência atual de isolar as informações em silos é responsável por muitas violações de segurança de nuvem. De fato, pesquisas recentes sugerem que 60% das violações ocorrem na nuvem pública - o lado do usuário do aplicativo - devido à implantação inadequada. Os desenvolvedores simplesmente não tomam boas decisões de configuração quando se trata de implantação de nuvem, pelo menos não sem suporte, e isso deixa as empresas expostas a ataques. A mudança para uma perspectiva DevSecOps preenche essa lacuna, mas também pode levantar as defesas dos desenvolvedores que acham que já estão usando as práticas recomendadas.
Como chegar ao 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.
Opinião