El marco Secure OPSWAT: un compromiso con la resiliencia y la seguridad en profundidad

Los actores maliciosos atacan los sistemas con el fin de obtener beneficios o causar trastornos, lo que genera costes, riesgos empresariales y daños a la reputación de las organizaciones. 

Según una encuesta reciente, el coste de corregir un fallo de seguridad es 30 veces mayor cuando se detecta en el entorno de producción que cuando se detecta durante la fase de análisis y definición de requisitos.

El Marco Secure OPSWATdefine metodologías estructuradas y principios de seguridad que sirven de guía para el desarrollo seguro de software. 

OPSWAT el ciclo de vida ágil Software . Con el fin de cumplir plenamente con los requisitos de nuestros clientes, hemos adaptado el marco Secure a los requisitos normativos y las normas internacionales. Este enfoque refuerza nuestro compromiso con la mejora continua y la resiliencia en un panorama de ciberseguridad en constante evolución.

El marco Secure OPSWATse basa en el SSDF (Secure Software Framework) de la norma NIST SP 800-218, lo que garantiza que la seguridad esté estructurada, sea cuantificable y se aplique de forma coherente en todas las fases del proceso de desarrollo de software.  

Mediante la integración de las mejores prácticas del SSDF, OPSWAT una estrategia de seguridad proactiva, incorporando la seguridad en todas las fases del desarrollo de software, desde la planificación y el diseño hasta la implementación, la verificación y la supervisión continua. 

El certificado de conformidad de los productos individuales se facilita a nuestros clientes del Gobierno Federal de EE. UU. previa solicitud. Consulte los datos de contacto que figuran a continuación.

A medida que la normativa en materia de ciberseguridad sigue evolucionando, OPSWAT su compromiso de adaptar su Marco Secure a los requisitos normativos internacionales, empezando por la Ley de Ciberresiliencia de la UE y la Directiva NIS2. Al adaptarse de forma proactiva a las nuevas normas, OPSWAT que su Secure siga siendo exhaustivo, conforme a la normativa y resiliente en un panorama normativo cada vez más complejo.

Mantener una seguridad de la información sólida es fundamental tanto para la integridad operativa como para el cumplimiento normativo. El marco Secure OPSWAT incorpora los principios del SGSI (Sistema de Gestión de la Seguridad de la Información) de la norma ISO 27001, lo que garantiza que los controles de seguridad, las estrategias de gestión de riesgos y las medidas de cumplimiento se integren a la perfección en el funcionamiento de nuestros productos en la nube. 

Como proveedor y usuario de nuestras soluciones de seguridad, OPSWAT internamente políticas de seguridad corporativas, garantizando que nuestros productos certificados cumplan con los requisitos de seguridad de nivel empresarial antes de su implementación.  

Consulte más detalles sobre el cumplimiento normativo y las certificaciones.

Para garantizar los más altos estándares de calidad del software, el marco Secure OPSWATestá integrado en el Sistema de Gestión de la Calidad (SGC) conforme a la norma ISO 9001. El SGC establece controles de calidad auditados para la gobernanza, la gestión del cambio y los procesos interfuncionales, lo que respalda la definición, el diseño, el desarrollo, la producción y el mantenimiento del producto y de los servicios de asistencia, y se extiende más allá de la I+D a áreas como ventas, atención al cliente, tecnologías de la información y recursos humanos.  

Este enfoque refuerza nuestro compromiso con un enfoque estructurado y basado en el riesgo para la gestión de la calidad, garantizando que la seguridad de las aplicaciones siga siendo un aspecto fundamental en todas las funciones de la empresa.

Consulte más detalles sobre el cumplimiento normativo y las certificaciones.

El Modelo de Madurez Software (SAMM) de OWASP es un marco integral diseñado para ayudar a las organizaciones a evaluar, formular y aplicar estrategias eficaces de seguridad del software dentro de su ciclo de vida del desarrollo de software (SDLC) actual.

Como marco de código abierto, SAMM se beneficia de las contribuciones de todo el mundo, lo que garantiza un enfoque colaborativo y en constante evolución de la seguridad de las aplicaciones. Su metodología estructurada ofrece a las organizaciones una forma eficaz y cuantificable de analizar y mejorar su ciclo de vida de desarrollo. SAMM da soporte a todo el ciclo de vida de desarrollo. SAMM es independiente de la tecnología y los procesos. SAMM es evolutivo y se basa en el riesgo. Al aprovechar SAMM, los equipos obtienen información útil sobre las brechas de seguridad y pueden mejorar sistemáticamente su postura de seguridad a lo largo de todo el ciclo de vida de desarrollo.

El Estándar de Verificación de la Seguridad de las Aplicaciones (ASVS) de OWASP es un marco reconocido a nivel mundial diseñado para establecer un enfoque estructurado, cuantificable y aplicable en materia de seguridad de las aplicaciones web. Proporciona a los desarrolladores y a los equipos de seguridad un conjunto completo de requisitos de seguridad y directrices de verificación para garantizar que las aplicaciones cumplan con las mejores prácticas del sector. 

Al ser un marco de código abierto, ASVS se beneficia de las numerosas aportaciones de la comunidad de seguridad internacional, lo que garantiza que se mantenga al día frente a las amenazas emergentes y a la evolución de las normas de seguridad.

El Programa Secure OPSWAT traduce el Marco Secure en un sistema de gobernanza estructurado, garantizando que los requisitos de seguridad se documenten, mantengan, evalúen y mejoren continuamente, al tiempo que se asegura que todas las partes implicadas reciban la formación adecuada. Establece funciones, responsabilidades y medidas de seguridad para los entornos de desarrollo, pruebas y producción, así como para la seguridad del flujo de trabajo, definiendo el Entorno Secure y exigiendo la aplicación de políticas de seguridad dentro del Proceso Secure .

Dirección ejecutiva – Director de Producto (CPO)

El director de producto (CPO) es responsable de la supervisión estratégica y la aplicación del Programa Secure en todos los equipos de producto, así como de otros programas de investigación y desarrollo (I+D), como el Programa de Control de Calidad (QA) y el Programa de Experiencia de Usuario (UX), garantizando un enfoque coherente para un desarrollo de software seguro, de alta calidad y centrado en el usuario.

Como principal responsable del riesgo de todos los productos y procesos de I+D, el CPO encarga a Operaciones de I+D la gestión del Programa Secure y se asegura de que los responsables de producto velen por la aplicación de Secure programa e implementen el proceso Secure de manera eficaz en los equipos de producto. En el desempeño de esta función, el CPO aprueba las modificaciones del Programa Secure , así como las desviaciones respecto al proceso Secure .

El CPO también supervisa los resultados del Programa Secure , realizando un seguimiento de la madurez en materia de seguridad, las vulnerabilidades, el cumplimiento normativo y las actividades de desarrollo, con el fin de mantener un alto nivel de seguridad en los productos.

Además, el director de compras es responsable de la asignación y aprobación del presupuesto de seguridad para I+D, garantizando que se destinen los recursos adecuados al programa Secure .

Prioridades estratégicas

El plan estratégico OPSWATen materia de seguridad de las aplicaciones se ajusta a sus prioridades empresariales y a su nivel de tolerancia al riesgo, teniendo en cuenta el grado de madurez de cada producto y su exposición a las amenazas de seguridad. El objetivo principal es proteger los productos de alto riesgo, en particular aquellos que cuentan con una amplia base de clientes, implementaciones orientadas al público o integración en infraestructuras críticas.

Como parte del Programa Secure , además de los cursos generales de sensibilización en materia de seguridad de la empresa, se exige a todo el personal involucrado en el desarrollo seguro que realice cursos de formación específicos para su puesto. Todas las formaciones se registran en las herramientas de formación de la empresa. Los programas de formación y sensibilización se revisan periódicamente para incorporar las nuevas tendencias en materia de seguridad y garantizar el cumplimiento continuo de las normas de seguridad.

OPSWAT compromete a mejorar continuamente su programa Secure mediante mediciones estructuradas del rendimiento, evaluaciones de madurez y actualizaciones periódicas, con el fin de garantizar la eficacia continua de la seguridad.  

Para mantener un alto nivel de seguridad, OPSWAT un enfoque sistemático para supervisar y mejorar el rendimiento en materia de seguridad. Esto incluye evaluaciones trimestrales de la madurez de la seguridad de los productos, revisiones internas de seguridad para verificar el cumplimiento de las mejores prácticas y la definición de indicadores clave de rendimiento (KPI) anuales, que se miden cada trimestre.  

Para medir de forma eficaz el estado de seguridad de las aplicaciones, OPSWAT los equipos mediante métricas estructuradas. La madurez de la seguridad de los productos se evalúa por equipo basándose en el marco SAMM, lo que proporciona una medida cuantificable del progreso en materia de seguridad. Además, los productos se someten a una evaluación de cumplimiento de la norma ASVS para garantizar el cumplimiento de los requisitos de verificación de seguridad. El cumplimiento del proceso Secure se supervisa y evalúa de cerca, y la consecución de los objetivos de los KPI se basa en datos empíricos, lo que garantiza que tanto el estado de seguridad como las mejoras en materia de seguridad sean medibles y aplicables. Todos los equipos de producto deben cumplir los objetivos de madurez de seguridad como parte de su evaluación de rendimiento anual. 

Como parte de sus esfuerzos de mejora continua, OPSWAT periódicamente nuevas iniciativas de seguridad de productos para aumentar los niveles de madurez y reforzar la seguridad de las aplicaciones. Estas iniciativas incluyen la actualización de las políticas de seguridad para hacer frente a las amenazas emergentes, la integración de nuevas herramientas de seguridad para mejorar la detección y la prevención, y la ampliación de los objetivos de los indicadores clave de rendimiento (KPI) para impulsar el progreso continuo. 

Con el fin de reforzar aún más la gestión de la seguridad, OPSWAT una revisión anual del marco Secure , en la que se incorporan las conclusiones extraídas de los análisis de las causas fundamentales de incidentes de seguridad anteriores, las evaluaciones de las tendencias en materia de vulnerabilidades y las mejoras introducidas en los procesos y políticas existentes.  

Este enfoque estructurado de mejora continua garantiza que OPSWAT una postura proactiva y resiliente en materia de seguridad de los productos, adaptándose de manera eficaz a los retos cambiantes de la ciberseguridad y cumpliendo al mismo tiempo los objetivos de seguridad tanto normativos como operativos.

El proceso Secure pone en práctica el programa Secure mediante la definición de los controles de seguridad que deben seguir los equipos, lo que incluye actividades específicas como comprobaciones de seguridad automatizadas y mecanismos de verificación en cada fase de desarrollo. Este proceso está coordinado con otros programas clave de I+D, como el programa de garantía de calidad y el programa de experiencia del usuario, lo que garantiza un enfoque coherente para un desarrollo de software seguro, de alta calidad y centrado en el cliente. 

El proceso Secure se describe en detalle en las siguientes secciones:

• Secure y evaluación de riesgos
• Secure , compilación y despliegue Secure
• Pruebas y verificación de la seguridad de las aplicaciones
• Secure
• Secure y mantenimiento Secure

El proceso Secure es un proceso de alto nivel; los equipos pueden implementarlo de forma ampliada y personalizada, siempre y cuando el nivel de seguridad del proceso se mantenga, como mínimo, al mismo nivel. Cualquier desviación del proceso Secure debe documentarse y aprobarse.

El Programa Secure comprende diversas políticas que deben ser aprobadas y aceptadas formalmente por los equipos de producto para garantizar el cumplimiento de sus requisitos. El cumplimiento de estas políticas es obligatorio a nivel interno, y cada equipo es responsable de revisarlas, firmarlas y aplicarlas como parte de sus procesos de desarrollo. 

A continuación se incluye una lista de las políticas clave junto con sus respectivos objetivos. En el caso de las políticas con repercusión externa, se han incorporado detalles adicionales en este documento.

Como parte del proceso Secure , los requisitos de seguridad se supervisan, documentan y mantienen a lo largo de todo el ciclo de vida del desarrollo. Se exige a los proveedores externos que acepten y cumplan con las normas ASVS, garantizando así la coherencia en las expectativas de seguridad y el cumplimiento de la Política de cumplimiento de la privacidad de los productos en todos los componentes de software. 

La seguridad se integra en todas las fases del ciclo de vida del desarrollo. Es responsabilidad de los responsables de seguridad tener en cuenta las expectativas del proceso Secure y transmitirlas a sus equipos. 

El conjunto de requisitos Secure incluye requisitos de seguridad funcionales y no funcionales basados en el ASVS. El departamento de I+D proporciona modelos de referencia para respaldar las decisiones de diseño, junto con ajustes documentados a los requisitos del ASVS en caso necesario (por ejemplo, requisitos de cifrado más estrictos).

El modelado de amenazas es un proceso estructurado destinado a identificar amenazas y vulnerabilidades en las primeras fases del ciclo de vida del desarrollo. Forma parte integrante del proceso Secure y se lleva a cabo de forma periódica —al menos una vez al año o cada vez que se introducen nuevas funcionalidades o cambios arquitectónicos—. Los equipos de producto llevan a cabo el modelado de amenazas definiendo los objetivos de seguridad, identificando los activos y las dependencias, analizando posibles escenarios de ataque y mitigando las amenazas identificadas.  

Un enfoque mejorado incorpora el análisis del flujo de datos y prácticas consolidadas de modelización de amenazas (por ejemplo, el modelo STRIDE), lo que garantiza una evaluación exhaustiva de todos los productos. Cuando es necesario, se llevan a cabo revisiones de seguridad para validar el cumplimiento de los requisitos de seguridad y abordar de forma proactiva los posibles riesgos. Las decisiones de diseño se documentan minuciosamente y los riesgos restantes se supervisan de forma continua a lo largo de todo el ciclo de vida del producto.

Los riesgos de seguridad de las aplicaciones se evalúan utilizando múltiples fuentes, entre las que se incluyen las amenazas residuales identificadas durante el modelado de amenazas, las vulnerabilidades de seguridad ampliamente reconocidas, como las que figuran en el Top 10 de OWASP y el Top 25 de SANS, y los controles de seguridad que faltan según las directrices de ASVS. Otros factores de riesgo son las deficiencias en la gestión de secretos a lo largo de los procesos de compilación, implementación y lanzamiento, así como las vulnerabilidades en los componentes de código abierto y de terceros. 

Tras la evaluación de riesgos, se elaboran planes de mitigación para reducir la gravedad de los riesgos identificados, teniendo en cuenta tanto el impacto como la probabilidad. Estos planes, junto con los riesgos correspondientes y las medidas de mitigación, se documentan exhaustivamente. 

Los riesgos residuales se supervisan a lo largo de todo el ciclo de vida del producto, se someten a revisiones periódicas y deben ser reconocidos formalmente por los responsables de los riesgos. Además, se incorporan a los informes internos de lanzamiento para garantizar la transparencia y la rendición de cuentas. 

Cuando es necesario, se llevan a cabo revisiones de seguridad para garantizar el cumplimiento de los requisitos de seguridad y abordar de forma proactiva los posibles riesgos, reforzando así la seguridad general del producto.

Como parte del proceso Secure , que incluye la implementación, la compilación y el despliegue, el objetivo es prevenir vulnerabilidades y fallos, basándose en el Secure y la evaluación de riesgos. El conjunto de requisitos incluye expectativas sobre los requisitos de seguridad funcionales y no funcionales basados en ASVS, así como una metodología de desarrollo y pruebas seguras que se apoya en el entorno Secure .  

Durante la implementación, se deben aplicar las mejores prácticas Secure , la revisión Secure y la detección temprana de fallos de seguridad. Los equipos deben cumplir la Política Supply Chain (incluidos los aspectos relacionados con la incorporación de proveedores y el software de código abierto), la Política de uso de la IA y la Política de gestión de muestras de malware. Durante la compilación y la implementación, se exige Secure y una implementación Secure mediante el uso de un canal de CI/CD centralizado y la separación de funciones.

Los equipos de producto deben seguir las mejores prácticas de programación segura, independientemente del lenguaje utilizado, durante la implementación. Se les exige que validen los datos de entrada, limpien los datos enviados a otros sistemas, eliminen las advertencias del compilador, configuren mensajes de error seguros, apliquen la codificación de salida cuando sea necesario, implementen un registro seguro sin exponer datos confidenciales y sigan las directrices adecuadas para el manejo de errores y la gestión de excepciones. Los equipos también deben asegurarse de que, si se utiliza la criptografía, esta se base en algoritmos aprobados y en la generación segura de números aleatorios, y gestionar de forma segura los recursos del sistema mediante un manejo seguro de la memoria, la prevención de condiciones de carrera y la evitación de interbloqueos mediante una sincronización adecuada. 

También se recomienda a los equipos de producto que sigan las directrices de programación segura específicas para cada lenguaje, cuya aplicación se garantiza mediante herramientas SAST, tal y como se ilustra a continuación: 

En el caso de Java, los equipos deben asegurarse de que las claves utilizadas en las operaciones de comparación sean inmutables, utilizar SecureRandom en lugar de Random y evitar la deserialización insegura mediante la validación o la restricción de las clases de entrada.

En C++, se recomienda detectar y gestionar los errores de asignación de memoria, evitar los desbordamientos de búfer mediante la comprobación de límites y el uso de punteros inteligentes como std::unique_ptr(), y evitar funciones poco seguras como strcpy() y sprintf(). 

En Python, los desarrolladores deben evitar el uso de funciones como eval() o exec() para reducir los riesgos de inyección de código, y optar por formatos de serialización seguros, como el módulo json, en lugar de pickle, al procesar datos no fiables.

Como parte de las revisiones de seguridad exigidas por la Política de verificación de la seguridad de las aplicaciones, la revisión de código seguro es fundamental y se lleva a cabo en función de la tecnología de desarrollo utilizada, aplicando diversas listas de verificación Secure basadas enla serie «OWASP Cheatsheet».

Tal y como exige la Política de verificación de la seguridad de las aplicaciones, la detección temprana de fallos de seguridad es un componente fundamental del proceso de desarrollo. Para minimizar los posibles problemas de seguridad, es obligatorio aplicar un enfoque de «fallo en la compilación», que garantiza que el código inseguro no avance por el proceso de desarrollo. Además, se aplica un enfoque de «fallo en la fusión», que exige a los equipos corregir cualquier problema detectado antes de que los cambios puedan integrarse. La resolución de los fallos detectados es esencial para cumplir los criterios de lanzamiento.

Como parte del proceso Secure , es obligatorio el uso de un canal de CI/CD centralizado y coordinado para garantizar la seguridad de las compilaciones y evitar ataques a la cadena de suministro. Los registros de auditoría, compilación e implementación se generan, conservan y revisan según lo establecido en las políticas de seguridad de la empresa. 

Cada equipo de producto es responsable de aplicar configuraciones seguras de compilación y del compilador cuando sea necesario. Deben utilizar opciones de compilación seguras, desactivar el código de depuración, reforzar los entornos de ejecución de los lenguajes interpretados, fijar las versiones de las dependencias, garantizar que las compilaciones sean reproducibles y reforzar las imágenes de contenedor. Las configuraciones utilizadas deben documentarse y revisarse periódicamente. 

De acuerdo con el principio de separación de funciones, los desarrolladores y demás miembros del equipo que tengan acceso al código o a las compilaciones no pueden tener acceso al entorno de producción. En el caso de los productos en la nube, solo los ingenieros de fiabilidad del sitio del producto están autorizados a realizar implementaciones en el entorno de producción.

De acuerdo con nuestra Política de verificación de la seguridad de las aplicaciones, llevamos a cabo una documentación formal y un seguimiento de los problemas detectados, y utilizamos herramientas automatizadas para la verificación continua. Como parte del proceso Secure , se aplican y supervisan controles de seguridad en cada fase del ciclo de vida del desarrollo de software (SDLC) para cumplir con los requisitos de cumplimiento normativo. El objetivo de estos controles es detectar de manera eficiente las posibles fallas de seguridad. Los problemas de seguridad que surgen son investigados por los equipos y resueltos dentro de los plazos establecidos. Estos plazos forman parte de los indicadores clave de rendimiento (KPI) de seguridad definidos.

• Revisiones de arquitectura y diseño: Los ingenieros sénior y los miembros del equipo virtual de seguridad de aplicaciones evalúan los aspectos de seguridad de los cambios de diseño, incluyendo el cifrado, la autenticación, la autorización, la auditoría, el refuerzo de la seguridad del sistema y la arquitectura del sistema y de la red. 
• Revisiones de código: además de las revisiones de código habituales realizadas por compañeros e ingenieros sénior, los miembros del Equipo Virtual de Seguridad de Aplicaciones revisan los cambios para evitar fallos habituales, como la inyección de código, la gestión de errores y las configuraciones inseguras.

• Análisis de secretos para evitar la filtración de información confidencial y garantizar un diseño adecuado y una implementación segura de la gestión de secretos.
• Herramientas de SAST (pruebas estáticas de seguridad de aplicaciones) para detectar vulnerabilidades (por ejemplo, inyección SQL, desbordamientos de búfer).
• El SCA (análisisSoftware ) se utiliza para detectar vulnerabilidades en el software de código abierto.
• El DAST (pruebas dinámicas de seguridad de aplicaciones) se utiliza para detectar problemas de tiempo de ejecución (por ejemplo, fallos de memoria) y del entorno

Las herramientas definidas en la sección «Detección temprana de problemas de seguridad» son de uso obligatorio en el proceso de CI/CD. Todas las vulnerabilidades identificadas deben corregirse siguiendo la Vulnerability Management del producto.

Se utilizan metodologías de pruebas de seguridad tanto automatizadas como manuales, de conformidad con el Programa de Garantía de Calidad, en el marco de la ejecución del Plan de Pruebas de Seguridad.

• Las herramientas DAST se utilizan para detectar vulnerabilidades en tiempo de ejecución, comprobar las configuraciones predeterminadas y evaluar la resiliencia del sistema tras aplicar las recomendaciones de refuerzo de la seguridad. Las pruebas se centran tanto en el software como en la infraestructura subyacente. 
• Para evitar un retroceso en los requisitos y las funciones de seguridad, utilizamos herramientas de pruebas automatizadas para verificar de forma continua la integridad de las funciones y los controles de seguridad. 
• Las pruebas manuales se utilizan cuando las herramientas automatizadas no dan la talla, por ejemplo, para verificar los controles contra la filtración de información, identificar fallos en la lógica de negocio y detectar vulnerabilidades contextuales. 
• El análisis automatizado en busca de malware de los artefactos durante el ciclo de vida del desarrollo también forma parte de las medidas destinadas a prevenir problemas de seguridad.

Como parte del proceso Secure , el proceso de lanzamiento aplica criterios de lanzamiento que garantizan tanto el cumplimiento del proceso Secure como la seguridad general del producto, basándose en los resultados obtenidos en las pruebas y la verificación de la seguridad de la aplicación. El control de versiones del producto desempeña un papel crucial a la hora de mantener las mejoras de seguridad en todas las versiones, evitar la regresión relacionada con la seguridad y preservar el nivel de seguridad alcanzado, como requisito fundamental para cada lanzamiento. 

El proceso de lanzamiento incluye la elaboración de informes internos de lanzamiento, en los que se documentan los riesgos residuales y cualquier problema de seguridad pendiente. Estos informes deben ser aprobados formalmente por el responsable del producto. Además, las notas de lanzamiento externas informan sobre los cambios y las correcciones relacionados con la seguridad como parte del lanzamiento oficial del producto. 

En el caso de los productos en la nube, la implementación sigue un enfoque de automatización basado en el «fracaso en la implementación», lo que garantiza que solo se publiquen versiones seguras. Las pruebas y la verificación de la seguridad de las aplicaciones están integradas en el proceso de implementación, con una estrategia operativa de tipo «pull» en lugar de «push», lo que refuerza la validación de la seguridad antes de la implementación en producción. 

De conformidad con la Política de gestión de la lista deBill of Materials (SBOM) de software (Bill of Materials (SBOM) ), cada versión incluye unaBill of Materials (SBOM) Software Bill of Materials (SBOM) garantizar la trazabilidad del origen de los componentes, lo que favorece la transparencia y la seguridad de la cadena de suministro. Todos los archivos de la versión se archivan de forma segura para garantizar su accesibilidad a largo plazo.

De acuerdo con la Política de Integridad de las Versiones, con el fin de garantizar la integridad y la seguridad de las versiones de los productos, se aplica un sistema de control de versiones estructurado (por ejemplo, el sistema de versiones semánticas), lo que asegura una trazabilidad clara de los cambios y un periodo de conservación definido para todos los artefactos publicados, incluida la documentación. Para reforzar aún más la seguridad, los artefactos de software se firman digitalmente a nombre de la empresa, y se publican las huellas SHA para que los usuarios puedan verificar su autenticidad y detectar cualquier intento de manipulación. 

Cada versión va acompañada de documentación actualizada que ofrece orientación detallada sobre métodos de verificación de la integridad, procedimientos de instalación segura, prácticas recomendadas de configuración y medidas de refuerzo de la seguridad del sistema. Estos recursos ayudan a los usuarios a implementar controles de seguridad de forma eficaz, reduciendo así las posibles superficies de ataque. Además, se incluye el Acuerdo de licencia de usuario final (EULA) para establecer las obligaciones de cumplimiento y garantizar la transparencia jurídica. 

La lista de materiales (SBOM) de cada producto se facilita a nuestros clientes previa solicitud. Póngase en contacto con nosotros.

Los entornos de desarrollo, pruebas y producción están separados de forma segura para evitar el acceso no autorizado. Cada entorno cumple con estrictas normas de refuerzo de la seguridad y protocolos de seguridad de los terminales. Los entornos de desarrollo deben cumplir con las políticas de seguridad de la empresa.

Como parte de la protección de los puntos finales, se supervisan todos los dispositivos OPSWAT para detectar vulnerabilidades, el software instalado, los parches instalados y el cumplimiento de las políticas de seguridad de la empresa. En caso de incumplimiento, se adoptan medidas restrictivas para limitar el acceso a los recursos corporativos. 

Solo se puede acceder a los recursos clasificados como de alto riesgo a través de vías de acceso controladas (VPN). Los dispositivos que se encuentren fuera de la red de la empresa deben utilizar canales seguros para acceder a los recursos de I+D.

La seguridad del proceso de CI/CD se rige por estrictas directrices de seguridad para mitigar las amenazas en constante evolución. El origen de estas amenazas puede residir en elementos de infraestructura obsoletos (como sistemas operativos, herramientas de análisis, etc.), accesos no autorizados debidos a controles de privilegios deficientes y entornos mal aislados. Mantener la infraestructura de CI/CD actualizada, sometida a rigurosas comprobaciones y estrictamente controlada es una piedra angular de nuestro ciclo de vida de desarrollo de software (SDLC) seguro. 

A nivel regional, se utilizan servidores ubicados en EE. UU. para todos los servicios centralizados, incluyendo el almacenamiento de código, el proceso de CI/CD, las herramientas de análisis y pruebas, y la firma segura de artefactos. La configuración de todas las herramientas centralizadas está bajo el control del departamento de Operaciones de I+D. 

Aplicamos sólidos mecanismos de autenticación (autenticación multifactorial, MFA) y controles de autorización (control de acceso basado en roles, RBAC). Se aplican el principio del privilegio mínimo y se realizan revisiones periódicas de los accesos. 

Nuestros procesos incorporan varias herramientas de automatización de análisis y pruebas, entre las que se incluyen las pruebas estáticas de seguridad de aplicaciones (SAST), el análisis Software (SCA), las pruebas dinámicas de seguridad de aplicaciones (DAST), el análisis de secretos y el análisis de malware. 

En nuestra solución de firma de código segura, utilizamos módulos Hardware (HSM) para proteger el material de claves frente al acceso no autorizado y para generar la firma. La solución de firma forma parte de la infraestructura de CI/CD, pero se ha implementado una segmentación de la red. Solo el departamento de Operaciones de I+D está autorizado a acceder a los HSM durante breves periodos de tiempo. Cada acción de firma se registra y puede revisarse en el registro de auditoría. 

El conjunto de herramientas utilizado para desarrollar, compilar o probar el software debe incluir información sobre su procedencia y proceder de una fuente validada. El número de herramientas utilizadas en el proceso de CI/CD es limitado; solo se instalan las herramientas necesarias. Para las fases de compilación y desarrollo del proceso solo se permite el uso de software LTS. En el funcionamiento de los servicios centralizados, se definen períodos de mantenimiento periódico y de rotación de claves. Las herramientas desarrolladas internamente se rigen por el proceso Secure .

El refuerzo de la seguridad de todos los servicios centralizados es un proceso continuo, y estos requisitos de seguridad se revisan periódicamente. Las directrices de refuerzo se comunican a los equipos de producto para garantizar que estén preparados y puedan adaptar sus procesos de desarrollo en consecuencia. En caso de producirse un incidente de seguridad, se lleva a cabo un análisis de las causas raíz (RCA) para adoptar medidas preventivas y actualizar dichos requisitos.

La protección del código fuente es un aspecto fundamental del desarrollo de software para garantizar la confidencialidad y la integridad del código fuente dentro de la empresa. 

El código fuente se almacena siguiendo el principio del mínimo privilegio, permitiendo el acceso únicamente al personal y a las herramientas autorizadas. El código fuente está sometido a control de versiones. El sistema de gestión del control de versiones garantiza la trazabilidad y la responsabilidad de los cambios en el código. Los repositorios de código fuente están cifrados con criptografía conforme a la norma FIPS 140-3 y protegidos con una longitud de clave adecuada.

El cumplimiento de esta política es obligatorio para todos los equipos internos. Este documento está subordinado a las políticas de la empresa, lo que significa que, en caso de contradicción, prevalecerán las políticas de la empresa y deberán respetarse. 

Proceso de escalado de incumplimientos Secure : cualquier incumplimiento de esta política se gestiona internamente, comenzando por el departamento de Operaciones de I+D y escalándose hasta el director de producto (CPO) si es necesario.

Se espera que los proveedores que suministren componentes o presten servicios para productos incluidos en el ámbito de aplicación de las normas ISO 27001, SOC 2 y NIST SSDF cumplan los requisitos que se detallan a continuación, recogidos en el Marco Secure . El cumplimiento está sujeto a auditorías de seguridad periódicas, evaluaciones realizadas por terceros y a las obligaciones de cada parte en virtud de los contratos firmados. 

Todos los proveedores deben facilitar información sobre la procedencia y la integridad, junto con la documentación justificativa, tal y como se define en la sección «Integridad de las versiones». 

Los proveedores de componentes y bibliotecas deben establecer entornos de desarrollo que se ajusten a nuestras prácticas, tal y como se describe en la sección «Entorno Secure ». Deben someter sus componentes y bibliotecas a pruebas de seguridad, tal y como se describe en la sección «Pruebas y verificación de la seguridad de las aplicaciones». 

Los proveedores de componentes de la cadena de suministro también deben establecer entornos de desarrollo que se ajusten a nuestras prácticas, tal y como se describe en la sección «Entorno Secure ». Además, sus procesos de desarrollo deben ajustarse al proceso Secure OPSWAT. 

Se espera que los proveedores de servicios utilicen entornos ubicados en Estados Unidos que ofrezcan un nivel de seguridad comparable al de los servicios OPSWAT. Su Secure debe incluir tanto un programa Secure como un proceso Secure que se ajusten a las expectativas OPSWAT.