Un método integrado

para incorporar la
seguridad a DevOps
Una guía de mejores prácticas

Software SEGURIDAD

1
Contenido
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Breve resumen de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Cada solución AST detecta distintas vulnerabilidades de software . . . . . . . . . . . . . . . . . . . . . . . . 5

Dónde integrar las soluciones AST a DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Un programa de concientización sobre AppSec es lo más lógico  . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Disponer de una capa de integración y organización del SDLC es crucial . . . . . . . . . . . . . . . . . . 10

La automatización de las soluciones AST dentro de las herramientas

de DevOps es de suma importancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Administrar y reducir los riesgos de seguridad a escala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Definir las políticas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Automatizar e integrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Identificar vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Correlacionar los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Resolver vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Administrar y supervisar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Acerca de Checkmarx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Introducción
Las organizaciones están adoptando DevOps como un modelo operativo y de desarrollo
destinado a facilitar las prácticas de automatización de la entrega y la implementación de
software. Con este cambio, los responsables de seguridad y desarrollo se están dando cuenta de
que sus métodos tradicionales para abordar la seguridad de software no se pueden adaptar a
este nuevo modelo, y la seguridad suele considerarse como un obstáculo para DevOps.
Pero esto no tiene por qué ser así. Si se dispone de las herramientas, servicios y procesos
adecuados, la seguridad puede integrarse perfectamente a un entorno de DevOps. En esta guía
explicaremos el mejor método que existe para integrar análisis automáticos de seguridad a
DevOps.

3
Breve manual sobre DevOps
El movimiento DevOps generó una cultura y un entorno en el que el desarrollo, las pruebas y la entrega de
software tenían como objetivo realizarse de forma rápida, periódica y con mayor confiabilidad. Este cambio
cultural llevó a la formulación de los principios básicos de integración continua (CI) y entrega continua (CD),
que forman parte de los pilares actuales de DevOps, tal como se muestra en la figura 1 a continuación.

DESARROLLO CI CD PROMOCIÓN
Figura 1

Los pilares de DevOps

Básicamente, DevOps trata de los procesos, las conexiones, la automatización y las herramientas durante
las fases de desarrollo, evaluación y entrega. Pero lo que es aún más importante, DevOps trata de la
"automatización de las herramientas" y de las distintas "herramientas" asociadas a la creación de software.
Sin embargo, algo que los principios básicos de DevOps no han logrado solucionar por sí solos, es dónde se
debe integrar la seguridad del software a todo el ecosistema de desarrollo. Las organizaciones que desean
crear un software más seguro se ven obligadas a utilizar varias soluciones de pruebas de seguridad de
aplicaciones (AST) dentro de DevOps para abordar las vulnerabilidades detectadas en el código sin compilar,
el código en ejecución y los componentes de código abierto. Analicemos ahora por qué se hace así, mientras
estudiamos varias soluciones AST actualmente disponibles en el mercado.

4
Cada solución AST encuentra distintas
vulnerabilidades del software
Las soluciones de pruebas de seguridad de aplicaciones
estáticas (SAST) se utilizan para analizar (evaluar) de manera
incremental el código sin compilar a fin de detectar vulnerabilidades
durante el proceso de desarrollo del software propiamente dicho
dentro de DevOps. El código sigue estando en su estado sin
compilar y las pruebas estáticas fueron diseñadas para detectar más
fácilmente fallas como inyección de código SQL. Las soluciones SAST
son excelentes para indicar a nivel de código dónde se encuentran
las vulnerabilidades en el código fuente y cómo rectificarlas. SAST
se adapta bien a los entornos de desarrollo integrado (IDE), los
rastreadores de problemas y las herramientas de compilación para
respaldar los flujos de trabajo CI/CD. SAST se integra bien a DevOps,
ya que no introduce retrasos importantes.
Las soluciones de pruebas de seguridad de aplicaciones
interactivas (IAST) son más adecuadas para detectar fallas
en la configuración de la implementación de aplicaciones en
proceso de ejecución identificadas durante las pruebas de
funcionamiento, antes de comenzar a utilizar dicha aplicación.
Sería arriesgado asumir que las aplicaciones no tendrán ninguna
vulnerabilidad después de la fase de desarrollo, o que el código
en tiempo de ejecución no necesite someterse a pruebas. IAST
sabe cómo colaboran y funcionan todos los elementos de una
aplicación durante el tiempo de ejecución, así que puede detectar
vulnerabilidades en aplicaciones en ejecución que los atacantes
podrían explotar.
IAST se adapta bien a DevOps, ya que no introduce retrasos
más allá del tiempo necesario para realizar las pruebas de
funcionamiento.
Las soluciones de análisis de composición del software (SCA)
ofrecen a los equipos de desarrollo, seguridad y operaciones los
conocimientos necesarios para abordar con eficiencia los riesgos
relacionados con el software de código abierto dentro de las
aplicaciones que dichos equipos crean, implementan y mantienen.
El análisis y la gestión de los componentes de código abierto
en uso garantiza que los elementos vulnerables se eliminen o
sustituyan antes de que se conviertan en problemas. SCA se
adapta bien a DevOps, ya que no introduce retrasos importantes.
Las herramientas de pruebas de seguridad de aplicaciones
dinámicas (DAST) detectan vulnerabilidades en las aplicaciones
en ejecución atacándolas externamente. La cobertura de DAST se
limita a las vulnerabilidades por reflexión, ya que las soluciones
DAST básicamente son incapaces de ver lo que ocurre dentro de
una aplicación. Los resultados de las pruebas DAST no ofrecen
ninguna orientación a nivel de código sobre el lugar donde se
localizan las vulnerabilidades, lo que dificulta la labor de los
desarrolladores para rectificar fácilmente tales vulnerabilidades.
Las herramientas DAST no logran cumplir con eficiencia los
rápidos plazos exigidos por DevOps.
5
Los métodos de pruebas de penetración (pentests) también deben
abordarse aquí aunque, en general, este tipo de pruebas suele
quedar fuera de las soluciones AST. Muchas organizaciones adoptan
este enfoque como una manera de garantizar que sus aplicaciones
estén libres de vulnerabilidades, pero lo aplican muy tarde en el
SDLC, incluso después de usar las soluciones DAST. Este método
suele resultar de la necesidad de "marcar una casilla", por así
decirlo, y los resultados de estas pruebas difícilmente indican a los
desarrolladores qué es lo que necesita rectificarse.
Atacar la aplicación desde el exterior da
Dentro de la mentalidad de compuertas de seguridad, los plazos
entre las pruebas de penetración suelen ser muy largos, y este tipo
como resultado la detección de muchos
de pruebas no se realiza de forma repetitiva durante el desarrollo verdaderos positivos, pero no ayuda a los
del software, sino que suele hacerse cuando las aplicaciones están
listas para su uso o después de que entran en funcionamiento. desarrolladores a localizar en qué lugar de
Atacar la aplicación desde el exterior da como resultado la
su código están los problemas.
detección de muchos verdaderos positivos, pero no ayuda a los
desarrolladores a localizar en qué lugar de su código están los
problemas.

Ahora que hemos hablado de varias soluciones AST, a continuación

veremos dónde se deben integrar dentro de DevOps.

6
Dónde integrar las soluciones AST
en DevOps
Más adelante, en la figura 2, se muestran a la izquierda las distintas
soluciones AST anteriormente indicadas dentro de Dev y, a la
derecha, dichas soluciones incorporadas a Ops. Esta figura debería
ayudar a las organizaciones a ver dónde se integran las distintas
soluciones AST dentro de las etapas de DevOps.
Figura 2
Como se puede ver en la figura 2, las soluciones AST deben
integrarse dentro de las etapas de Dev, a la vez que se incorporan
a Ops. Las soluciones AST correctas para cada etapa de Dev se
resaltan con líneas verdes delgadas alrededor de las distintas
etapas. En la lista siguiente se resalta la etapa (o etapas) concreta
en la que mejor se integran también las soluciones AST dentro de
Dev:
• SAST funciona en todas las etapas de CÓDIGO, CHECK-IN,
COMPILACIÓN y EVALUACIÓN/QA.
• IAST funciona durante la etapa de EVALUACIÓN/QA.
• SCA funciona durante las etapas de COMPILACIÓN y
EVALUACIÓN/QA.
• DAST funciona durante la etapa de EVALUACIÓN/QA, pero
tiene las limitaciones anteriormente indicadas.
• Las pruebas de penetración funcionan principalmente
fuera del ciclo de desarrollo del software.
7
Aunque aún no se les ha mencionado, en la figura 2 los servicios
AppSec (la línea verde externa) permiten a las organizaciones
externalizar algunos de sus requisitos a un tercero que ayude
a introducir e implementar procesos de seguridad a las
aplicaciones, prácticas de programación segura, pruebas de
seguridad y resolución de vulnerabilidades. Esto también puede
incluir programas de puesta en marcha destinados a ayudar a
implementar e integrar, entre otras muchas cosas, soluciones de
seguridad al SLDC, consultas sobre los resultados de seguridad,
instrucciones sobre cómo reducir falsos positivos, formación
y modelado de amenazas. Las organizaciones que carecen de
recursos y experiencia internos durante las primeras fases de
DevSecOps pueden aprovechar estos servicios.

Los servicios profesionales de AppSec pueden adaptarse y

ajustarse a los requisitos técnicos y comerciales estratégicos
exclusivos de cada organización. También fueron diseñados
Los servicios profesionales de AppSec
para mejorar iniciativas de DevOps seguras y para consolidar
las posiciones de seguridad de las aplicaciones, acelerar la pueden adaptarse y ajustarse a los requisitos
incorporación y la implementación para obtener beneficios más
temprano, y perfeccionar los procesos y las configuraciones de técnicos y comerciales estratégicos exclusivos
evaluación.
de cada organización.
Además, en la figura 2, se añadió un nuevo término, SCE, que
aún no se ha explicado. SCE son las siglas en inglés de educación
sobre programación segura (también conocida como formación
en programación segura), algo que funciona dentro a las etapas de
CÓDIGO de DevOps. En la siguiente sección se explica brevemente
la SCE en el contexto de un programa general de concientización
sobre AppSec.

8
Un programa de concientización
sobre AppSec es lo más lógico
Convertirse en un desarrollador centrado en la seguridad no se
limita a la educación o formación sobre una programación segura.
Tiene que ver más con una concientización operativa, en la que
todos los miembros de la organización comprendan la importancia
de la seguridad. Cuando los desarrolladores comienzan a escribir
código deben tener muy presente la seguridad. Los equipos de
AppSec ya no deberían ser los únicos responsables de la seguridad.
En su lugar, los desarrolladores también deben responsabilizarse
de la seguridad y, como resultado, podrán escribir un código más
seguro. Cuando en la actualidad todo se está pasando al código
(p.ej., infraestructura como código), todo el mundo debe tener muy
presente la seguridad, desde la dirección hasta los desarrolladores,
pasando por los equipos de AppSec e incluso los equipos de TI.
Sin embargo, la realidad es que un porcentaje importante de
desarrolladores no confían en la seguridad de sus propias
aplicaciones o apenas conocen sus vulnerabilidades y cómo se
originan. Este problema se produce porque a los desarrolladores se
les juzga por su velocidad y el número de errores de funcionamiento
en su código, no por el número de vulnerabilidades de seguridad
que introducen.
Para solucionarlo, las organizaciones comprenden ahora que
necesitan ofrecer a sus desarrolladores SCE (dentro del contexto
de un programa de concientización sobre AppSec) e incorporarla a
sus IDE. Mediante el uso de soluciones de capacitación oportuna,
comunicación constante y fomento de la participación, los
responsables de la seguridad crean una cultura de seguridad de
software que capacita a los desarrolladores para pensar y actuar
de forma segura durante sus labores diarias. Los desarrolladores
que piensan y actúan con seguridad pueden aumentar de forma
cuantificable la seguridad de su software, reducir los errores
repetitivos de programación y disminuir considerablemente el
número de vulnerabilidades de software que deben analizarse y
rectificarse.
En comparación, el problema que existe con los métodos
tradicionales de educación y formación sobre programación
segura, como los tutoriales en video, capacitación periódica
en aulas y cursos en línea obligatorios, es que no suelen lograr
unas prácticas de programación segura, ya que se basan en
tareas rutinarias, fuera de contexto y sin interactividad. La
concientización sobre AppSec en su conjunto consiste en mejorar
la madurez de los desarrolladores en materia de seguridad y debe
instituirse como objetivo de la organización.
Puesto que DevSecOps significa mucho más que la simple
integración de soluciones AST en los procesos de DevOps, veamos
algunas de las principales áreas de trabajo relacionadas con la
importancia de la automatización en DevOps.
9
Disponer de una capa de
integración y organización del SDLC
es crucial
Añadir una capa de administración y organización del SDLC a
las soluciones AST anteriormente indicadas ayuda a unificar las
soluciones en una plataforma integrada y fácil de usar, diseñada
para ofrecer a las organizaciones una visión global de sus
vulnerabilidades de software a escala y simplificar la automatización
AST. Como resultado, las organizaciones pueden seguir, administrar
y resolver fácilmente los riesgos de seguridad a escala. Esta capa
es muy necesaria para simplificar y administrar centralmente el
flujo de administración y automatización integral, desde el análisis
hasta la administración de incidencias. Cuando se considera la
implementación de soluciones AST, se debe comprobar que estas
incluyan una capa de integración y administración del SDLC.
Cuando se considera la implementación de soluciones
AST, se debe comprobar que estas incluyan una capa de
integración y administración del SDLC.
La automatización de las soluciones
AST dentro de las herramientas de
DevOps es de suma importancia
Obtener DevSecOps requiere que las organizaciones incorporen
automáticamente soluciones AST durante todo el proceso
de DevOps para eliminar las evaluaciones manuales que en
el pasado quizás ocasionaban retrasos. Estas soluciones AST
deben ser lo más transparentes posible para los equipos de
desarrolladores y seguridad sin obstaculizar la agilidad de
DevOps. La automatización es la clave para ayudar a cumplir
con los requisitos normativos, además de administrar los
riesgos en general. Para lograr este objetivo, las soluciones AST
deben poder ser automatizadas completamente dentro de las
herramientas que normalmente se utilizan en DevOps. Más allá
de la automatización y las herramientas, en la próxima sección
se explican más detalladamente las actividades necesarias
para administrar y reducir los riesgos de seguridad a escala.
Estudiemos este tema ahora.
10
Administrar y reducir los riesgos de
seguridad a escala

La cuestión de dónde integrar la seguridad

en DevOps para lograr DevSecOps abarca
varios aspectos que van, en cierto modo,
DEFINIR
más allá de las evaluaciones de seguridad
de la aplicación en general, mientras que
otros están directamente relacionados con
ellas. En la figura 3 se indican las actividades
RESOLVER AUTOMATIZAR
que deben llevarse a cabo para administrar
PLATAFORMA DE y reducir completamente los riesgos de
SEGURIDAD DE
seguridad a escala. Comenzando desde
SOFTWARE
arriba y en dirección de las agujas del reloj,
ADMINISTRAR IDENTIFICAR veamos ahora cada uno de estos conceptos.

CORRELACIONAR

Figura 3

11
Definir las políticas de seguridad
Aquí es donde las organizaciones definen sus políticas de seguridad
de las aplicaciones (AppSec) en relación con los riesgos que aceptan
asumir o no. Las aplicaciones siempre presentarán vulnerabilidades
y ninguna organización conseguirá nunca cero vulnerabilidades y
cero errores de funcionamiento. Definir los riesgos aceptables, y los
que no lo son, es esencial en esta etapa. Y el objetivo es determinar
qué infracción(es) a las políticas hará que una organización
interrumpa el proceso de compilación.
La política de seguridad definida también sirve como un
pseudocontrato entre los equipos de AppSec y los desarrolladores,
para que ambos comprendan plenamente qué se espera de ellos
en materia de seguridad. Asimismo, esta política funciona como
una directriz para determinar las vulnerabilidades que se deben
resolver primero como resultado de una evaluación de seguridad. La
definición de las políticas de seguridad está estrechamente ligada a
DevSecOps, y estas políticas resultan esenciales para medir el éxito
total de sus iniciativas de DevSecOps.
Automatizar e integrar
Aquí es donde las organizaciones realizan la actividad de integrar
sus soluciones de evaluación SAST, IAST y SCA en sus entornos
de compilación/desarrollo, asegurándose de que los análisis AST
estén completamente automatizados. Sin automatización las
organizaciones no pueden escalar. Cada organización debe elegir
a qué grado desea automatizarse, ya que esto puede hacerse de
muchas maneras. Pero al final lo que se pretende es garantizar
que las aplicaciones se analicen de forma coherente. La mejor
forma de hacerlo es automatizar los análisis dentro del entorno
de compilación, el entorno de desarrollo o ambos.
Por ejemplo, debe asegurarse de automatizar sus soluciones
AST cuando las compilaciones se ejecuten en el entorno de
compilación o cuando los desarrolladores realicen acciones
de code commit o pull request, etc. En el último caso, esta
automatización tiene lugar primero en el entorno de desarrollo.
Cuando las soluciones AST se automatizan en la fase de
programación, los equipos de desarrollo utilizan el autoservicio
para automatizar los análisis a través de plataformas de
programación colaborativa como GitHub, Azure DevOps, etc.
Cuando las soluciones AST se están automatizando durante la
fase de compilación/CI, los complementos de CI se utilizan para
automatizar los análisis. Finalmente, la integración del sistema
de administración de incidencias cierra el ciclo al entregar a los
desarrolladores, en tiempo real, los resultados relevantes de sus
análisis.
12
Identificar vulnerabilidades Correlacionar los resultados

En cuanto se haya realizado la actividad de integrar y automatizar las
soluciones AST de la manera anteriormente descrita, este es el paso
en el que se llevan a cabo los análisis AST. Al utilizar SAST, IAST y
SCA de forma automática, estas soluciones son plenamente capaces
de detectar todo tipo de vulnerabilidades en sus aplicaciones de
software. Estas pueden incluir vulnerabilidades en:
• Código sin compilar
• Código en ejecución
Esta correlación se lleva a cabo para aumentar el grado
de confianza y la prioridad de los resultados de alto riesgo
(vulnerabilidades detectadas) desde las soluciones AST,
especialmente cuando se pueden correlacionar los mismos
resultados procedentes de distintas soluciones de análisis. Por
ejemplo, si SAST descubre una vulnerabilidad de inyección de
código SQL durante una evaluación estática, e IAST confirma
el mismo resultado durante la evaluación interactiva, si ambos
resultados pueden correlacionarse podrá aumentar el grado de

• Componentes de código abierto confianza de que ese resultado sea un verdadero positivo.

El objetivo es detectar errores de programación (que podrían En este caso, la posibilidad de resultados reproducibles es muy

ocasionar vulnerabilidades) lo antes posible sin frenar el desarrollo, grande. Cuando esto ocurre, es necesario solucionar cuanto

entrega e implementación de las aplicaciones de software, antes dicha vulnerabilidad. Cuando las organizaciones disponen

garantizando así que se mantenga la agilidad de DevOps. de cientos de aplicaciones y sus soluciones AST detectan miles
de posibles vulnerabilidades, la capacidad de escalar comienza
aquí, cuando dichas organizaciones pueden entender las grandes
cantidades de datos procedentes de los resultados de sus análisis.

Cuando las organizaciones disponen de cientos de aplicaciones y sus soluciones AST

detectan miles de posibles vulnerabilidades, la capacidad de escalar comienza aquí, cuando
dichas organizaciones pueden entender las grandes cantidades de datos procedentes de los
resultados de sus análisis.

13
Resolver vulnerabilidades
El proceso de resolución presenta dos aspectos. Uno es lo que
debe rectificarse y el otro es cómo hacerlo. En lo que se refiere
a lo que debe rectificarse, dentro del contexto de la escala,
ningún desarrollador puede manejar miles de resultados de
vulnerabilidades. Es necesario garantizar la posibilidad de priorizar
todos esos resultados de tal manera que un desarrollador pueda
abordarlos.
Cuando los desarrolladores reciben todos sus resultados de
vulnerabilidades, de forma parecida a cómo reciben todos los
defectos de su actual herramienta de administración de defectos,
esto ayuda a acelerar el plazo de la resolución y la adopción de
AST. Además, si los desarrolladores reciben mejores prácticas
sobre cómo rectificar una vulnerabilidad concreta, con la mejor
ubicación para hacerlo, esto les permite solucionar de forma rápida
y eficiente el mayor número de vulnerabilidades. En resumen, los
desarrolladores necesitan poder centrarse en lo más importante
y trabajar para solucionar primero aquellas vulnerabilidades que
reducirían exponencialmente el mayor riesgo.
En cuanto un equipo decide qué se necesita resolver, normalmente
según la política establecida en el primer punto de la lista (Definir
las políticas de seguridad), la siguiente decisión es cómo hacerlo.
Aquí es donde la educación sobre programación segura (SCE) puede
ayudar mucho. La SCE puede enseñar a los desarrolladores cómo
Administrar y supervisar
solucionar una vulnerabilidad concreta con una lección a medida
que sea específica a ese tipo de vulnerabilidad, especialmente si la
SCE se integra directamente en el IDE de los desarrolladores.
En administración y supervisión es donde las organizaciones
hacen un seguimiento de los indicadores clave del rendimiento
(KPI) de su programa de seguridad de aplicaciones. Esto permite
a las organizaciones ver si, con el paso del tiempo, se reduce el
número de vulnerabilidades, así como la tasa de introducción de
nuevas vulnerabilidades y el índice de vulnerabilidades graves. Las
organizaciones utilizan todo tipo de KPI para evaluar la eficacia de
su programa de seguridad.
Parte de ese ciclo de KPI se dedica a averiguar cuáles son las
áreas que necesitan mejoras y cuáles no. Esto permite a los
equipos determinar si la política de seguridad se cumple o no,
y si los desarrolladores necesitan más formación, herramientas
o incentivos. Los equipos también pueden evaluar si la política
necesita perfeccionarse, etc. Toda esta actividad permite a las
organizaciones medir el estado actual de su programa y el grado
de las mejoras que se estén realizando. También crea un ciclo de
retroalimentación para los desarrolladores, ya que este proceso
no tiene fin. Y el objetivo final es permitir una mejora continua a
través de todo el ecosistema de DevSecOps.
14
Conclusión
El objetivo de esta Guía es fomentar un cierto nivel de conocimientos sobre dónde se debe integrar la seguridad dentro
de la cultura de DevOps de las organizaciones con la esperanza de ayudarles a lograr una completa DevSecOps. Lo que
realmente se logra integrando Sec en DevOps, de la forma más automatizada posible, es un software más seguro que
respalda los resultados finales de la organización a la vez que reduce el riesgo.

15
Acerca de Checkmarx
Seguridad de software para DevOps y mucho más.
Checkmarx hace que la seguridad del software sea una infraestructura esencial, unificada con DevOps y perfectamente integrada
en todo su proyecto de CI/CD, desde el código sin compilar hasta las pruebas en tiempo de ejecución. Nuestra plataforma holística
establece el nuevo estándar para integrar la seguridad al desarrollo moderno.

Con Checkmarx usted obtiene:

Seguridad desde el principio Velocidad de DevOps

Ofrecemos la plataforma de seguridad de software unificada
más completa del mercado, que combina a la perfección
SAST, SCA, IAST y concientización sobre AppSec para integrar
la seguridad del software a lo largo de todo el proyecto CI/CD
y reducir los riesgos del software.
Solamente Checkmarx le permite administrar la exposición
del software a la velocidad de DevOps, comenzando la
producción de las aplicaciones de forma rápida y segura
sin interrumpir los flujos de trabajo de los desarrolladores.

Automatización AST simplificada Conocimientos inigualables sobre DevSecOps

Checkmarx se integra a la perfección con herramientas Conocemos el software como nadie. Conocemos la
de planificación ágil y organización de lanzamiento de seguridad como nadie. Los desarrolladores prefieren a
software, como IDE, servidores de gestión de compilación, Checkmarx por encima de los demás.
herramientas de seguimiento de errores y repositorios de
fuentes para cumplir automáticamente con las políticas de
seguridad.

Para obtener más información sobre nuestra plataforma de seguridad de

Software SEGURIDAD
software consulte:
www.checkmarx.com/products/software-security-platform

16