
Las 10 mejores API de la serie OWASP de Coders Conquer Security: gestión inadecuada de activos
A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.


Esta vulnerabilidad es más bien un problema humano o de administración que permite que las API antiguas permanezcan en su lugar mucho después de que deberían haber sido reemplazadas por versiones más nuevas y seguras.
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
预约演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。


A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

点击下方链接,下载此资源的PDF文件。
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
查看报告预约演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
A diferencia de la mayoría de las vulnerabilidades de las diez principales API de OWASP, la gestión inadecuada de los activos no se centra específicamente en las fallas de codificación. Por el contrario, esta vulnerabilidad es más bien un problema humano o administrativo que permite que las API antiguas permanezcan en su lugar mucho tiempo después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo quedan expuestas al entorno de producción antes de que estén completamente protegidas contra las amenazas.
Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, es posible que los nuevos servicios se pongan en marcha rápidamente para satisfacer una necesidad temporal y luego se olviden de ellos y nunca se retiren del mercado. Si las API antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.
¿Quieres probar un desafío gamificado sobre este error de seguridad? Entra en nuestra arena: [Empieza aquí]
¿Cómo afectan las fallas de administración inadecuada de activos a las API?
La falla en la administración inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que avanzan a la velocidad de los negocios a veces pueden ofrecer cientos o miles de servicios y microservicios todos los días. Con frecuencia, esto se hace de forma rápida y sin necesidad de crear ninguna documentación complementaria ni de ninguna explicación sobre para qué se utilizan las API asociadas, durante cuánto tiempo serán necesarias o su importancia. Esto puede generar rápidamente una expansión de las API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan durante cuánto tiempo pueden existir las API.
En ese entorno, es muy posible que algunas API se pierdan, se olviden o nunca se den de baja.
Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también tienen la culpa a veces. Por ejemplo, un grupo de marketing puede crear un servicio para ayudar a respaldar un evento próximo, como el lanzamiento de un producto, y luego no volver a suspenderlo una vez finalizado el evento. Si alguien consulta ese servicio y sus API asociadas más adelante, puede que no sepa por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más recientes porque no tienen ni idea de su importancia ni de lo que hacen.
La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos mejora con el tiempo. Es posible que un investigador descubra una vulnerabilidad o que se añada una seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los piratas informáticos suelen buscarlas o utilizar herramientas automatizadas para encontrarlas.
En un ejemplo real proporcionado por OWASP, una empresa actualizó las API que utilizaba para buscar en las bases de datos de usuarios a fin de corregir una falla crítica. Sin embargo, dejaron las API antiguas en su lugar por error.
Un atacante observó que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Al reemplazar la URL por (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. En última instancia, esto expuso los registros personales de más de 100 millones de usuarios.
Eliminar las fallas en la administración inadecuada de activos
La única manera de eliminar la falla de administración de activos inadecuada de su entorno es mantener un inventario ajustado de todas las API, sus usos y versiones. Esto debe comenzar con un inventario de las API existentes, centrándose en factores como el entorno en el que deben implementarse (por ejemplo, de producción o desarrollo), quién debe tener acceso a ellas en red y, por supuesto, su versión.
Una vez que esté completo, debe implementar un proceso en el que la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluida la limitación de velocidad, la forma en que gestiona las solicitudes y respuestas, el intercambio de recursos, los puntos finales a los que se puede conectar, las políticas pertinentes que se apliquen y cualquier otra cosa que sea necesaria para auditarlas posteriormente. También debes evitar utilizar en producción las API que no sean de producción o las del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las API cuando sus propietarios deban justificar su uso continuo para evitar el desmantelamiento automático.
Siempre que haya nuevas versiones de las API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizarse y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine completamente las antiguas del entorno.
Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la administración inadecuada de activos perjudique a su organización, a los usuarios o a la red. Eche un vistazo a Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。
预约演示下载



%20(1).avif)
.avif)
