Usa las políticas de seguridad de Snyk para priorizar las correcciones con mayor eficiencia

Las políticas de seguridad de Snyk ahora son mucho más potentes: incorporan una nueva acción y dos condiciones nuevas que ayudan a tus equipos de desarrollo y seguridad a evaluar los riesgos y enfocar los recursos con mayor eficiencia.

Para los desarrolladores, cuanto menos «ruido», mejor. Asignarles la tarea de corregir problemas que simplemente no son importantes ni relevantes desperdicia valioso tiempo de desarrollo y probablemente genere frustración y desconfianza. Sin duda, no ayudará a que los desarrolladores asuman más responsabilidad y compromiso con la seguridad de la organización.

Las políticas de seguridad pueden ayudar, ya que priorizan de manera eficaz qué problemas deben abordarse antes que otros y cuáles pueden ignorarse por completo hasta que se hayan resuelto los más críticos. Aplicadas en distintas etapas del SDLC, las políticas también pueden garantizar que los componentes vulnerables o que no cumplen con las normas no pasen inadvertidos. Las políticas son una parte integral del marco de gobernanza de la organización y se rigen por los estándares de seguridad y cumplimiento aceptados internamente.

El motor de reglas mejorado que se incorporó a las políticas de seguridad de Snyk incluye una nueva acción Ignore y nuevas condiciones (CVE e ID de Snyk), lo que te brinda mayor flexibilidad y granularidad en la gobernanza, y te ayuda a impulsar estrategias de priorización más eficaces en toda la organización. 

Ignora vulnerabilidades en bloque

Una política de seguridad de Snyk contiene una regla o un conjunto de reglas que definen exactamente cómo deben manejarse las vulnerabilidades de seguridad. Las reglas activan acciones según una condición o un conjunto de condiciones. Hasta ahora, estas reglas admitían una sola acción: ajustar la gravedad de las vulnerabilidades. Según el CWE de una vulnerabilidad o si tenía un exploit, los usuarios podían cambiar su nivel de gravedad.

Ahora tienes la opción adicional de ignorar por completo vulnerabilidades específicas. Puedes hacerlo según las condiciones disponibles hasta ahora, y también según las dos condiciones nuevas que acabamos de incorporar: CVE e ID de Snyk. Esta herramienta puede ayudarte a despejar el backlog de vulnerabilidades de varias maneras.

Por ejemplo, puedes configurar una política de seguridad para ignorar las vulnerabilidades sin un exploit conocido:

Con la nueva condición CVE junto con los atributos del proyecto, también puedes ignorar una vulnerabilidad específica que sabes que no es relevante para ciertos tipos de aplicaciones:

Y lo mismo aplica para ignorar toda una categoría de vulnerabilidades usando la condición CWE:

Administración granular de políticas

Los proyectos son distintos entre sí y probablemente requieran límites de seguridad y cumplimiento diferentes. Por ejemplo, un proyecto crítico para el negocio requiere un control más estricto y riguroso que un proyecto interno, aislado en un entorno de desarrollo de pruebas.

Snyk ofrece la granularidad necesaria para decidir exactamente cómo aplicar las políticas en la organización. Las políticas se pueden aplicar a un proyecto o a un grupo de proyectos mediante etiquetas y atributos del proyecto, dos tipos de metadatos que se pueden agregar a los proyectos, de forma manual o automática mediante la API de Snyk, para agruparlos según características compartidas. Como alternativa, las políticas se pueden aplicar a organizaciones específicas dentro de un grupo de Snyk (consulta nuestra documentación para obtener más información sobre las jerarquías de grupos, organizaciones y proyectos de Snyk).

Veamos un ejemplo, esta vez con las políticas de licencias de Snyk.

El equipo legal de la organización X determinó que era necesario aplicar límites de cumplimiento sumamente estrictos a todos los servicios frontend críticos para el negocio en producción. Por otro lado, le preocupa menos que los proyectos internos en desarrollo cumplan con las normas.

Como primer paso, la organización X se asegura de agregar los atributos Critical, Production y Frontend a los proyectos pertinentes en Snyk.

Luego, como segundo paso, se crea una nueva política de licencias. Con los atributos recién agregados, se asigna la política a los proyectos pertinentes. Dentro de la política, se puede asignar una gravedad alta a cualquier licencia copyleft identificada en los proyectos, como las licencias GPL-3.0 y AGPL-3.0. 

Aplicación en todo el SDLC

Una vez creadas, las políticas de seguridad y licencias de Snyk se aplican a todos los proyectos pertinentes y se hacen cumplir en las distintas etapas del SDLC. Esto comienza desde las primeras etapas, en el entorno de desarrollo local del desarrollador, en el IDE o la CLI; continúa en los flujos de trabajo basados en Git y en CI/CD, y llega hasta producción. Estas múltiples barreras de seguridad y cumplimiento permiten detectar los problemas lo antes posible durante el proceso de desarrollo, cuando corregirlos cuesta menos tiempo y recursos.

Por ejemplo, en los proyectos de GitHub supervisados por Snyk, cualquier pull request nueva que envíe un desarrollador colaborador se verifica según las políticas de seguridad y licencias asignadas al proyecto. De este modo, el código vulnerable o que no cumple con las normas no puede incorporarse al repositorio y se respetan los estándares internos de la organización.

En el ejemplo de abajo, intento agregar el paquete fullpage.js para habilitar el desplazamiento en pantalla completa en mi aplicación de JavaScript. Aunque pasa la verificación de seguridad (la versión más reciente del paquete no tiene vulnerabilidades conocidas), no pasa la verificación de licencia porque incluye la licencia GPLv3, que infringe nuestra política de licencias.

Al hacer clic en el enlace Details, obtenemos información más detallada y contexto sobre la prueba fallida:

Del mismo modo, las políticas se aplican en CI/CD para garantizar que las compilaciones cumplan con los límites de seguridad y cumplimiento. En el ejemplo de abajo, falló un flujo de trabajo de compilación de GitHub Actions debido a una vulnerabilidad de gravedad alta detectada en las pruebas de Snyk.

La seguridad y la velocidad no son incompatibles

En la seguridad de las aplicaciones, las políticas cumplen la función esencial de garantizar un equilibrio entre el desarrollo rápido, por un lado, y la seguridad, por el otro. El equilibrio exacto varía de una organización a otra, pero, si se implementan correctamente, las políticas garantizan que los equipos de desarrollo y seguridad trabajen dentro de los límites de seguridad y cumplimiento aceptados por la organización, al tiempo que maximizan su productividad. 

Pero, para lograrlo, las políticas deben…

• ser lo suficientemente flexibles para permitir reglas granulares y su aplicación en toda la organización

• complementar los procesos y flujos de trabajo de desarrollo, en lugar de generar fricción

• permitir priorizar los problemas de forma eficaz para garantizar la máxima eficiencia y seguridad

• ofrecer a las personas o equipos que las administran una visibilidad clara de qué reglas se aplican y dónde

• contar con una gobernanza adecuada para que se puedan administrar de forma centralizada y garantizar el cumplimiento.

Estas son capacidades fundamentales de las políticas de Snyk. Para obtener más información sobre las políticas de Snyk y cómo usarlas, consulta nuestra documentación técnica.