Los programadores conquistan la infraestructura de seguridad como series de códigos, utilizando componentes de fuentes no confiables
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la 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 los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
El comportamiento que induce la vulnerabilidad en el que nos vamos a centrar aquí es el uso de código de fuentes que no son de confianza, una práctica aparentemente benigna que está causando grandes problemas.
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la 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 los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la 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 los desafíos de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
報告書を見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido fantástico ayudar a desarrolladores como tú en su viaje hacia la seguridad en iAC.
¿Has estado jugando a los desafíos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes sobre los inconvenientes de usar componentes de fuentes que no son de confianza:
¿Aún tienes trabajo por hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos centraremos hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite a los expertos aportar sus ideas, trabajos e incluso código terminado a repositorios como GitHub para que lo utilicen otras personas que tienen dificultades para hacer que un programa o una aplicación funcione correctamente. El uso de código completo para controlar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, el uso de fragmentos de código de fuentes poco fiables, no investigadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes que no son de confianza es una de las formas más comunes en las que las vulnerabilidades de seguridad, tanto mayores como menores, se infiltran en aplicaciones que, por lo demás, serían seguras. En ocasiones, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que posibles atacantes escribieron código malicioso. Luego, el código se comparte con la esperanza de atrapar a las víctimas para que lo incluyan en sus aplicaciones.
¿Por qué es peligroso usar código de fuentes no confiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Este puede ser un proceso complicado. Entonces, en lugar de perder mucho tiempo intentando resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada sobre la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker usando dos líneas:
EJECUTE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora, la imagen de Docker extraerá dinámicamente el archivo de configuración de terceros. E incluso si el archivo se prueba y se comprueba que está bien en ese momento, el hecho de que el puntero esté ahora incrustado en el código de la nueva aplicación significa que existe una dependencia permanente. Días, semanas o meses después, el autor original o un atacante podría modificar el archivo y poner en peligro el repositorio de código. De repente, el archivo de configuración compartido puede indicar a la aplicación que funcione de forma muy diferente a la prevista, lo que puede dar acceso a usuarios no autorizados o incluso robar datos directamente y filtrarlos.
Una forma mejor de usar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, se deben implementar procesos para garantizar que se haga de manera segura. Al evaluar el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales únicamente mediante enlaces seguros. Y aun así, nunca debes vincular a una fuente externa para obtener ese código, ya que eso eliminaría el control del proceso. En su lugar, el código aprobado debe guardarse en una biblioteca segura y utilizarse únicamente desde esa ubicación protegida. Por lo tanto, en un entorno de Docker, el código tendría este aspecto:
COPIA src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración remotos de terceros, esto dependería de una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o malintencionados.
Además de usar una biblioteca de códigos segura, se debe implementar un proceso de administración de parches para monitorear continuamente los componentes durante todo el ciclo de vida del software. También se deben comprobar todos los componentes del lado del cliente y del servidor para detectar alertas de seguridad mediante herramientas como NVD o CVE. Por último, elimina todas las dependencias y funciones innecesarias o no utilizadas que puedan venir acompañadas del código externo.
Al seguir estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Eche un vistazo a la 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 los desafíos de IaC en 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 ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード
%20(1).avif)
.avif)
