¿Por qué las empresas han tardado tanto en adoptar DevSecOps?

How does your business approach application development? If you’re like many companies, DevOps is your watchword, and with good reason. Historically, a strong DevOps program allowed for agile operations, shortened the development lifecycle, and gave customers consistent access to the immediate solutions they demand. DevOps has been a powerful solution for tech companies of all sizes – but the problem is that it’s not enough.

Over the last several years, industry experts have encouraged businesses to shift left, taking a DevSecOps approach to application development. Security, these experts argue, needs to be part of the initial development process if applications are actually going to be secure. Why, then, are so many companies hesitant to deploy a DevSecOps approach? It’s a complicated problem, but one that, with proper examination, can be solved to everyone’s advantage.

Descargar informe Guía de seguridad en la nube DevSecOps

Argumento #1: La desaceleración

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.

 

¿Cómo acelera DevSecOps el proceso de desarrollo de aplicaciones? Cuando se construye una aplicación y se espera hasta el final para integrar los elementos de seguridad, hay que encontrar la manera de encajar estos componentes vitales en la infraestructura existente. Es como construir una torre y luego tratar de insertar una viga en el centro después de que esté hecho. Puede ser posible, pero tendrás que interrumpir todo lo que ya has hecho. Si, por otro lado, opta por desplazarse a la izquierda e incorporar seguridad a medida que avanza, termina con un sistema más fuerte y piezas que encajan perfectamente.

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

Los cambios en las prácticas comerciales pueden ser costosos. Ya sea que esté haciendo la transición de un conjunto de programas más antiguo o cambiando los lenguajes de codificación, cualquier cambio significativo puede poner el negocio en espera y hacer que su negocio pierda contratos y ganancias. ¿Es esto también cierto cuando se trata de pasar a DevSecOps? Mientras que, a corto plazo, apoyar a los miembros del equipo en el aprendizaje de nuevos sistemas puede retrasar las cosas, a largo plazo, DevSecOps puede maximizar su ROI.

 

¿Cómo puede un enfoque DevSecOps hacer que su empresa sea más rentable? Ciertamente, es financieramente beneficioso prevenir problemas de seguridad importantes antes de que ocurran y poder actuar rápidamente cuando se está bajo ataque, pero esa no es la única razón. Recordemos el argumento anterior de que DevSecOps crea en realidad un sistema más ágil, que se lanza y actualiza más rápidamente de lo que sería posible con un enfoque DevOps. El soporte experto también puede ayudar a las empresas a automatizar su infraestructura de seguridad, simplificando un proceso altamente técnico y que requiere mucho tiempo.

Argumento #4: Silos de proceso

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.

 

Por lo general, los desarrolladores de aplicaciones y los profesionales de la seguridad han trabajado en proyectos por separado, ya que las funciones de seguridad se añadían a la aplicación más tarde en el proceso de codificación. Sin embargo, cuando las funciones básicas de desarrollo y seguridad se crean simultáneamente, estos equipos previamente aislados deben unirse. Para hacer esto con éxito, el liderazgo debe facilitar la comunicación entre los equipos y fomentar la capacitación cruzada. Es posible que los expertos en seguridad no sean programadores profesionales, pero pueden proporcionar orientación a los desarrolladores. Y, a la inversa, los desarrolladores deben reconocer que la seguridad es una prioridad funcional.

 

Aumentar la comunicación entre los desarrolladores y los profesionales de la seguridad es especialmente importante porque la tendencia actual a aislar la información en silos es responsable de muchas de las brechas de seguridad en la nube. De hecho, investigaciones recientes sugieren que el 60% de las brechas se producen en la nube pública -el lado del usuario de la aplicación- debido a una implementación inadecuada. Los desarrolladores simplemente no toman buenas decisiones de configuración cuando se trata de implementar la nube, al menos no sin apoyo, y eso deja a las empresas expuestas a los ataques. Cambiar a una perspectiva DevSecOps salva esa distancia, pero también puede levantar las defensas de los desarrolladores que piensan que ya están utilizando las mejores prácticas.

Cómo llegar 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.

x
  Comentarios
Este sitio web utiliza cookies para optimizar su funcionalidad y para fines de análisis y marketing.Al seguir usando este sitio web, usted acepta el uso de cookies.Para obtener más información, lea nuestro Aviso de cookies.