A grandes rasgos,
DevSecOps es una metodología que incorpora
la seguridad a los procesos de desarrollo (Dev) y operaciones (Ops).
En términos sencillos,
esto significa que la seguridad
de la tecnología se evalúa durante su desarrollo,
pero también que la seguridad es responsabilidad de todos.

Probablemente te has dado cuenta
que la metodología DevSecOps
se está adoptando cada vez más.
En 2021, en un
estudio sobre DevSecOps
a nivel mundial realizado por GitLab,
cerca del 36% de los encuestados afirmó que sus equipos
desarrollan software utilizando DevOps o DevSecOps.
Y seguramente querrás saber qué significa DevSecOps.
En este blog post,
te daremos todos los conceptos básicos sobre esta metodología.
Después de leerlo,
no olvides echar un vistazo a nuestra serie de posts sobre
DevSecOps.

DevOps vs. DevSecOps

DevSecOps
ha sido llamado
“la extensión natural de DevOps”.
Por lo tanto,
debemos explicar cuál es la diferencia
entre DevOps y DevSecOps.

DevOps

DevOps quizá un concepto tan conocido como DevSecOps,
se define como una metodología de desarrollo que busca reducir la brecha
entre el desarrollo y las operaciones.
Para ello,
hace énfasis en la comunicación entre desarrolladores y operadores
y en la responsabilidad compartida de garantizar la calidad.

Una de las principales características de DevOps es la velocidad.
De hecho,
aquí es donde destacan dos procesos,
ya que casi nunca están ausentes cuando se habla de DevOps.
Uno de ellos es la integración continua (CI, por su nombre en inglés).
Un proceso en el que los desarrolladores integran
el código en el que trabajan en un repositorio compartido varias veces al día,
todos los días.
Junto con la CI está el despliegue continuo
(CD, por su nombre en inglés),
que significa trasladar el software al ambiente de producción,
proporcionando una respuesta rápida a las modificaciones
y una retroalimentación constante.
He aquí un resultado positivo:
En la
encuesta de 2021,
de GitLab antes mencionada,
casi el 60% de los desarrolladores afirmaron que liberaban código
el doble de rápido gracias a DevOps.

DevSecOps

Aunque DevOps suene muy bien,
no tiene sentido que un lanzamiento sea rápido
si el producto está plagado de errores.
Los equipos intentan evitar esto
implementando DevSecOps,
lo que significa que adoptan una cultura
en la que todos son responsables de la seguridad
y cada desarrollador evalúa su propio código
con herramientas automatizadas o técnicas manuales de pruebas de seguridad.
Algo que hacen durante todo
el ciclo de vida de desarrollo de software (SDLC).
Así es: desde el principio hasta el final.

Significado de DevSecOps

Hace un tiempo publicamos un post sobre DevOps.
Al final del mismo,
nos preguntábamos sobre la inclusión de la seguridad
en esta metodología de integración y despliegue continuos.
A raíz de ello,
hacíamos referencia al surgimiento del concepto
DevSecOps
Si buscamos en la Internet una definición breve,
encontramos lo que se dice en el glosario de Gartner:

DevSecOps es la integración de la seguridad en la TI ágil emergente
el desarrollo y DevOps de la forma más transparente y fluida posible.
Idealmente, esto se hace sin reducir la agilidad o la velocidad
de los desarrolladores ni exigirles que abandonen su entorno
de cadena de herramientas de desarrollo.

Ok, esta información puede ser suficiente. ¡Nos vemos en el próximo post!

¡Es broma! Hablemos al respecto.

Entonces,
¿qué significa DevSecOps?
Como dijimos en el post sobre DevOps,
el elemento Sec,
en referencia a la seguridad,
se añade a DevOps.
Pero para que quede claro,
no lo añadimos en cualquier parte,
lo añadimos en el medio: DevSecOps.
Se espera entonces que la seguridad desempeñe un papel importante
junto a los procesos de desarrollo (Dev) y operaciones (Ops).
DevSecOps es una evolución de DevOps
en la que la seguridad es entendida e implementada.
Ahora bien, ¿por qué se incluye la seguridad en esta metodología?
¿Por qué es importante DevSecOps?

¿Por qué necesitamos DevSecOps?

Muchos siguen ignorando la seguridad en la ingeniería de software.
Otros siguen viéndola como un obstáculo
que retrasa el proceso de producción.
Pero muchos otros han llegado a ver la seguridad
como una necesidad en un espacio virtual ampliamente compartido,
donde las intenciones de muchos resultan no ser las mejores.
Los más atentos a esta cuestión han sido aquellos
que desean mantener el prestigio de sus empresas,
las cuales pueden estar manejando datos personales
de enormes cantidades de usuarios.

Debemos ser conscientes
que los datos de los usuarios
y la funcionalidad de las aplicaciones
pueden ponerse en riesgo por la presencia de vulnerabilidades.
Así que,
para evitar debilidades y posteriores ataques a los productos,
hay que implementar medidas de seguridad
desde las primeras fases del SDLC.
Por lo general,
las pruebas de seguridad se han llevado a cabo
justo antes del despliegue de las aplicaciones
en el ambiente de producción.
Pero para muchos,
este método de evaluación ha sido engorroso.
¿Qué ocurre con aquellos que, dentro de la cultura DevOps,
están continuamente creando funcionalidades en sus aplicaciones?
¿Están invirtiendo tiempo
y esfuerzo en encontrar o detectar deficiencias en su código
justo antes de cada despliegue?

Si ya están dentro de la metodología DevSecOps,
la respuesta es no.
Cuando hablamos de implementación en las etapas iniciales,
como se muestra en la figura siguiente,
el elemento de seguridad tiene que cubrir
el ciclo desde el inicio hasta su fin.

¿Cómo funciona DevSecOps?

En este modelo,
las compañías tienen que establecer requisitos de seguridad
que deben cumplir durante el SDLC.
Estos requisitos pueden basarse en evaluaciones
de la infraestructura del sistema. Estas evaluaciones,
realizadas manualmente y desde el punto de vista del atacante,
detectan posibles problemas de seguridad.
En otras palabras,
estas evaluaciones pretenden responder a preguntas como:
¿Dónde pueden atacarnos los hackers?
¿Cuáles son las áreas y la información que más debemos proteger?
¿Cuáles son las brechas que no debemos permitir en nuestras aplicaciones?
¿Cuál serán las contramedidas y soluciones que debemos establecer?

Siguiendo esos requisitos de seguridad,
e realizan continuamente pruebas de seguridad para encontrar vulnerabilidades.
Estas pruebas se llevan a cabo mediante herramientas automáticas combinadas
con equipos de expertos en seguridad
que utilizan sus conocimientos para detectar deficiencias,
manteniendo el ritmo de DevOps.
El uso de estas herramientas
y de capacidades humanas integradas en los pipelines, empleando
pruebas de seguridad de aplicaciones estáticas
y pruebas de seguridad de aplicaciones dinámicas
permite minimizar el número de vulnerabilidades.
Estos puntos débiles pueden detectarse de forma temprana,
mientras el código está en construcción,
y su remediación puede hacerse con prontitud.
La actuación oportuna de los expertos y las herramientas DevSecOps,
que deberían generar un registro continuo de información
y una retroalimentación inmediata,
permite a las empresas ir un paso por delante de los atacantes
y mantener los controles de seguridad.
Por eso son importantes las prácticas DevSecOps.

Precaución:
(a) Depender excesivamente de las herramientas y de su trabajo automático
puede dar lugar a altas tasas de falsos positivos y negativos.
Por esta razón,
el papel de los expertos es fundamental para lograr precisión
y evitar que los desarrolladores pierdan tiempo confirmando
si las vulnerabilidades son reales.
El principal riesgo es la existencia de falsos negativos o escapes.
Las organizaciones pueden desconocer ciertas vulnerabilidades de seguridad
que la tecnología actual no logra identificar.
(b) Realiza las verificaciones de seguridad de forma gradual,
empezando por las áreas de mayor prioridad,
intentando no sobrecargar de trabajo a los desarrolladores,
que suelen ser los responsables de subsanar las deficiencias.

Beneficios de DevSecOps

El informe de Forrester de 2021
sobre el estado de la seguridad de las aplicaciones
mostró
que el 30% de los encargados de tomar decisiones relacionadas
con seguridad encuestados en 2020,
cuyas empresas sufrieron una brecha,
dijeron que el ataque había sido posible
debido a vulnerabilidades en su software.
DevSecOps tiene como objetivo evitar esto.
Como los cambios en el código se revisan para detectar vulnerabilidades,
es posible descubrir estas antes de que el usuario final
reciba un software defectuoso.

Otra tendencia preocupante
es la de los ataques a las cadenas de suministro.
Los equipos suelen utilizar componentes
de terceros para desarrollar su software.
Además,
si ellos mismos construyeron los componentes,
es probable que otros equipos los utilicen.
Si los atacantes encuentran una vulnerabilidad
que les permita alterar el código,
los componentes, los servicios en la nube, etc.,
comunes a varios proyectos de software,
terminan comprometiendo toda la cadena de suministro.
Las prácticas DevSecOps pretenden proteger el software
de los riesgos heredados de la cadena y evitar
que los equipos generen riesgos heredables a la cadena.

Y, como mencionamos más adelante,
DevSecOps también puede permitir que tu equipo ahorre en costos de remediación.

Cómo pasar de DevOps a DevSecOps

“¡Me apunto! ¿Cómo puedo arrancar?”
¡Qué bien que lo preguntes!
Afortunadamente,
tenemos un post donde ofrecemos una guía completa
sobre cómo implementar DevSecOps.
Aquí,
te daremos un consejo sencillo
sobre cómo pasar de DevOps a DevSecOps.

Puedes empezar por decidir
ampliar la responsabilidad compartida y el sentido de pertenencia
del software para también incluir su seguridad.
En su mayor parte,
esto se consigue creando la posibilidad
de colaboración entre los equipos de desarrollo,
operaciones y seguridad.
Lo que pretendemos aquí es que la gente adopte
una cultura y una mentalidad DevSecOps.

También puedes proceder
a especificar las verificaciones de seguridad
que necesitan ser implementadas en tus procesos DevOps.
Lo ideal sería automatizar la mayoría de ellas.
Sin embargo,
es necesario hacer un esfuerzo para formar
a los desarrolladores en codificación segura,
revisando el código en busca de vulnerabilidades
tan pronto como se realice un cambio.
Además, no importa si no son desarrolladores,
ingenieros o lo que sea; cada uno de los empleados
de tu compañía debe ser consciente de los nuevos requisitos
de seguridad establecidos
y saber cómo aplicarlos en su trabajo diario.

En este proceso,
deben surgir algunos roles y responsabilidades DevSecOps.
Hay una persona cuyo trabajo consiste en definir acciones,
dirigir los controles de seguridad (por ejemplo,
realizar evaluaciones de riesgos y modelos de amenazas)
y supervisar las prácticas en el proceso DevSecOps.
Hablamos del ingeniero DevSecOps.
Ya en este blog hemos dedicado
un post a este rol,
en el que incluso mencionamos cómo convertirse en un ingeniero DevSecOps.
Te invitamos a visitarlo.

Las mejores prácticas de DevSecOps

Es fundamental mostrar un compromiso con la seguridad
y mejorar las capacidades de DevSecOps.
Ya hemos identificado un conjunto de las mejores prácticas,
de las cuales hablamos ampliamente en
una otro post.
Aquí te ofrecemos un breve resumen:

• Colaboración:
  Fomentar una comunicación rápida
  y hacer posible que todo el equipo
  del proyecto conozca dónde están las vulnerabilidades en el código,
  quiénes las introdujeron,
  qué se ha hecho al respecto
  y cuáles son sus estados de remediación.

• Sensibilización sobre ciberseguridad:
  Informar regularmente a los empleados
  sobre las políticas de seguridad de toda
  la empresa (vital para mantener una conciencia activa en ciberseguridad);
  educarlos para que incorporen prácticas de seguridad
  en su trabajo diario (por ejemplo, pruebas y revisión del código);
  y hacerles responsables “de evaluar y mantener la seguridad de su trabajo.”

• Velocidad:
  Lanzar pequeños cambios de código de forma rápida y segura.

• Pruebas a la izquierda:
  Disponer de escaneos de seguridad integrados
  en el flujo de trabajo de los desarrolladores
  en las primeras fases del SDLC
  para buscar vulnerabilidades conocidas que ellos
  pudieron haber acabado de generar en el código;
  de esta forma pueden corregirlas antes
  de que el equipo de seguridad revise los resultados del análisis.

• Automatización combinada con pentesting manual:
  Integrar con éxito la seguridad en el SDLC,
  de modo que cada cambio en el código sea escaneado automáticamente,
  hacer un inventario continuo de las dependencias y manterlas actualizadas,
  y crear automáticamente issues/tickets
  o romper el build (según la política de la organización)
  en caso de encontrar una vulnerabilidad.
  Además hacer esto continuamente
  y en conjunto con las pruebas de seguridad manuales.

• Estándares de seguridad:
  Automatizar el uso de estándares de seguridad,
  evaluados y establecidos por el equipo de seguridad,
  y evaluar continuamente el cumplimiento
  y la integridad de los componentes físicos de los sistemas,
  la seguridad de la red y el comportamiento de los empleados.

• Auditorías de seguridad continuas en lugar de periódicas:
  Identificar toda la superficie de ataque,
  y los posibles vectores de ataque
  para los sistemas de información,
  lo que suele ser parte de las evaluaciones
  de riesgos y la modelización de amenazas.

• Pruebas de penetración continuas:
  Disponer de hackers éticos
  que evalúen la seguridad de tus sistemas
  a lo largo de todo el SDLC,
  en lugar de realizar únicamente pruebas
  de penetración esporádicas que dejarían márgenes
  de tiempo durante los cuales los atacantes podrían invadir los sistemas.

• Romper el build:
  Impedir que el código vulnerable llegue a producción
  y repararlo rápidamente,
  reduciendo así el tiempo de remediación
  hasta en un 30%.

¿Y cuáles son las fases de la implementación de DevSecOps?
Idealmente,
las prácticas anteriores deberías iniciarlas de forma gradual.
Algunas de ellas,
como la automatización,
pueden volverse más sofisticadas a medida
que adquieres experiencia en DevSecOps.
Para una guía detallada de DevSecOps,
consulta el blog post correspondiente.

Seguridad a la izquierda

La importancia de iniciar las pruebas de seguridad
desde el principio del desarrollo de software es fundamental.
Visualiza el SDLC en una línea recta horizontal,
con la planificación del proyecto situada
en el punto más a la izquierda y el despliegue
a producción en el punto más a la
derecha: Lo que te pedimos es que desplaces las pruebas
de seguridad siempre hacia la izquierda.

La idea en torno a las pruebas desplazadas
a la izquierda es identificar y abordar los problemas
de seguridad en el software desde las primeras fases del desarrollo.
Es decir,
no hasta bien iniciada la fase tradicional de pruebas del SDLC,
sino mucho antes, incluso cuando se están definiendo sus requisitos
(por ejemplo, lo que debe hacer y los recursos necesarios).

Desplazar las pruebas hacia la izquierda
puede ayudarte a producir software
más seguro y ahorrar dinero.
Se ha argumentado que la remediación
en las primeras fases del desarrollo
es menos costosa
que en la fase de despliegue a producción.

Automatización de DevSecOps acompañada de técnicas manuales

Como hemos mencionado antes,
lo ideal es tener controles de seguridad automatizados.
Esto incluye aspectos esenciales como tener herramientas
de pruebas de seguridad automatizadas
(por ejemplo, SAST,
DAST y SCA)
en ejecución en tu SDLC.
Sin embargo,
estas herramientas pueden generar falsos positivos
y falsos negativos,
por lo que una estrategia aún mejor es tener personas
expertas que utilicen técnicas manuales
para encontrar vulnerabilidades en tu software.
De hecho,
nuestros hackers éticos
detectaron alrededor del 81%
de las vulnerabilidades de alta y crítica severidad
reportadas en sistemas durante un periodo de análisis en el 2020.
En resumen,
la automatización de procesos te ahorra tiempo,
pero es necesaria una intervención manual para lograr precisión.

DevSecOps como servicio

Algunas organizaciones pueden considerar necesario
contratar servicios externos de DevSecOps.
Cuando lo hacen,
esperan que se les proporcione una solución
que aproveche los conocimientos y la experiencia práctica
de profesionales certificados en DevSecOps.
El proveedor de DevSecOps como servicio es responsable
de integrar metodologías y herramientas de seguridad
(como las herramientas para ejecutar
comprobaciones de seguridad en los pipelines CI/CD)
en todo el SDLC.
Además, debe evaluar las vulnerabilidades actuales
y las potencialess del sistema y ayudar a aplicar
las mejores prácticas de ciberseguridad
más allá de la codificación segura.

En Fluid Attacks ofrecemos la implementación de
DevSecOps
como parte de nuestra solución de
Continuous Hacking
Como se mencionó anteriormente,
entendemos que el uso de técnicas manuales para las pruebas
de seguridad tiene beneficios evidentes
sobre las herramientas de pruebas de seguridad automatizadas.
Así que,
nosotros ayudamos a las organizaciones a implementar DevSecOps
ofreciendo las habilidades de nuestros hackers éticos
(además de las herramientas automatizadas)
para encontrar vulnerabilidades en todo el SDLC.
Mediante la realización de
pruebas de pentesting continuas,
las organizaciones pueden validar la seguridad
de su tecnología y probarla frente a nuevas técnicas utilizadas
por los atacantes y, por lo tanto,
no incluidas en el alcance de las herramientas automatizadas.

¿Cómo se relaciona DevSecOps con los red teams?

Puede que entonces quieras que tu sistema sea evaluado
para detectar vulnerabilidades de la forma más realista posible.
Es decir, que hackers éticos realicen ataques reales.
Red teaming puede hacerlo por ti.
Su relación con DevSecOps
es que puedes conseguir un mejor entendimiento de la seguridad
de tu sistema si los hackers éticos prueban continuamente
las versiones del sistema tal y como lo harían los atacantes maliciosos.
Esto implica que
solo algunas personas
de tu organización deben conocer
el acuerdo contractual con el red team;
el resto del equipo deberá responder a los ataques,
que se llevarán a cabo sin previo aviso.
La seguridad debería consistir en estar preparados
para ataques reales en cualquier momento,
y así es como DevSecOps se relaciona con los red teams.

Un modo consecuente en el que el red teaming
puede mejorar
tu implementación de DevSecOps es desafiando
una mentalidad perniciosa: Que las vulnerabilidades pueden ser aceptadas,
ya que hay pocas posibilidades de que sean explotadas.
Así, cuando tienes pruebas reales de que los hackers
han explotado una vulnerabilidad en tu software,
no te queda más remedio que priorizar su remediación en lugar
de centrarte en desplegar nuevas funcionalidades.

DevSecOps con Fluid Attacks

Ahora,
para tener una idea más clara del rol de la seguridad en DevOps,
vamos a resumir brevemente lo que Óscar Prado,
analista de ciberseguridad,
compartió con nosotros sobre lo que Fluid Attacks hace por sus clientes.
Nuestra empresa ofrece servicios de hacking continuo,
una búsqueda constante de vulnerabilidades en sistemas informáticos.
Pero aunque se utilizan algunas herramientas en este proceso,
en Fluid Attacks, confiamos en las herramientas
solo como apoyo a las operaciones de nuestros hackers,
contrario a lo que hacen otras compañías.
Aquí damos más valor a los conocimientos
y habilidades de los hackers éticos para garantizar
una mayor precisión en las pruebas.
Su trabajo puede iniciar
“desde el momento en que los desarrolladores suben el primer commit“,
revisando cada nuevo cambio.
Ese trabajo puede continuar después de que la aplicación
se haya desplegado a producción.

Cuando se detecta una vulnerabilidad en el código del cliente,
un miembro de nuestro equipo puede desarrollar un script personalizado,
llamado exploit, asociado al hallazgo.
Ese exploit “comprueba automáticamente
si el hallazgo del analista persiste”.
Por lo tanto,
“si el cliente quiere hacer nuevos cambios en su producto,
debe arreglar primero el hallazgo”,
porque si no lo hace,
el exploit seguirá reportando la presencia de la vulnerabilidad.
Entonces,
según una configuración del equipo del cliente,
el agente DevSecOps de Fluid Attacks romperá el build,
y el proceso de despliegue se detendrá automáticamente.
“De esta forma, se prioriza la seguridad,
y nuestras pruebas de detección de vulnerabilidades
se integran en el SDLC del cliente”, concluye Óscar.

Bonus: Fluid Attacks está convencido
de que la velocidad sin precisión es inútil.
Por eso, hemos combinado lo mejor de cada uno:
Tecnología y conocimiento producen un buen equilibrio.
Tecnología y conocimiento producen un buen equilibrio.
Muchas empresas de ciberseguridad ofrecen herramientas rápidas
y automatizadas que son muy propensas a falsos positivos
y falsos negativos en la búsqueda de vulnerabilidades.
Fluid Attacks ha reconocido que debe haber trabajo humano
en estos procesos para garantizar la precisión y la eficiencia.
Fluid Attacks no ha olvidado el valor de la rapidez,
sino que siempre la ha mantenido en paralelo
con pruebas de alta calidad y excelentes resultados. Por ello,
invitamos a las organizaciones a automatizar las herramientas
y los procesos cuando sea posible y a confiar en hackers éticos
para realizar pruebas de seguridad sofisticadas.
De esta forma podrán alcanzar sus objetivos de DevSecOps.

¿SecDevOps?

Curiosamente,
cuando hablamos con Óscar,
él no utilizó el nombre DevSecOps,
sino SecDevOps.
Trasladó la seguridad a la izquierda.
Con SecDevOps,
quizás se pone más énfasis en establecer inicialmente
unos requisitos de seguridad a seguir a través
de los procesos de pruebas llevados a cabo continuamente en el SDLC.

Independientemente del nombre que demos a la inclusión
de la seguridad en la metodología DevOps,
dentro de esta nueva cultura empresarial,
se espera que la seguridad juegue un papel esencial
en la producción y mantenimiento de software desde el principio.
Se pretende que todos los implicados en los proyectos conozcan
y apliquen la seguridad;
por eso necesitan formación.
Hay que tener en cuenta que, al igual que en DevOps,
no debería haber equipos separados por funciones,
sino por productos.
Al final, todos deben ser responsables de la seguridad.

Las empresas que decidan implementar
el enfoque DevSecOps
(o, quizás mejor dicho, SecDevOps)
conseguirán importantes beneficios,
especialmente en la calidad
y seguridad de sus procesos y productos.
¿Quieres recibir asesoría sobre cómo hacerlo?

En Fluid Attacks te ayudamos a aplicar las prácticas DevSecOps:
Puedes incorporar a tus pipelines nuestro
agente DevSecOps
y configurarlo para que
rompa el build
si nuestras herramientas SAST o DAST
encuentran una vulnerabilidad abierta en tu software.
Además,
puedes preguntarnos por nuestro Plan Squad,
que incluye hackers éticos
que evalúan la seguridad de tu tecnología.
Para obtener más información
y resolver todas tus dudas sobre DevSecOps,
¡contáctanos!