Prepare su aplicación para pasar la revisión de seguridad de AppExchange ☁️

Esta guía se publicó originalmente en Medium a principios de 2021 y se actualizó con la orientación y los consejos más recientes, incluidas nuevas funciones de seguridad como parte de los lanzamientos recientes y una nueva estructura de precios para las revisiones .

Ha creado su aplicación, funciona muy bien y ahora está listo para lanzarla al mundo. Pero antes de que pueda publicar su creación en AppExchange , su aplicación debe pasar una revisión de seguridad. En Salesforce, nada es más importante que la confianza de nuestros clientes. El proceso de revisión de seguridad está aquí para validar que se puede confiar en su aplicación con los datos del cliente.

En esta publicación de blog, brindaremos orientación sobre el proceso de revisión de seguridad de AppExchange para arquitectos, desarrolladores, evaluadores, propietarios de productos y cualquier otra persona involucrada en el desarrollo o envío de un paquete determinado.

Enlaces rápidos:

Este artículo incluye una colección de las mejores prácticas de desarrollo seguro y una lista de verificación de los errores comunes encontrados durante la revisión de seguridad (SR) de AppExchange. Puede ahorrar tiempo antes de su revisión de seguridad asegurándose de evitar estos problemas comunes. No es una lista exhaustiva, y el campo de la seguridad está en constante evolución. Para evitar la duplicación, vincularemos a la fuente autorizada para un tema determinado.

Comencemos abordando algunas preguntas frecuentes sobre el proceso de revisión de seguridad.

¿Por qué mi paquete pasó el escaneo inicial y no la revisión de seguridad más profunda?

La revisión de seguridad es un proceso complejo de varias capas que involucra varias herramientas y especialistas en seguridad. Las herramientas de verificación de código automatizadas iniciales brindan una evaluación de alto nivel de su código, pero no pueden encontrar todas las vulnerabilidades de seguridad encontradas durante una revisión manual, ya que este es un campo en constante evolución y requiere experiencia humana.

¿Qué hizo que nuestro paquete fallara en la revisión?

La persona que envió la revisión debería haber recibido un correo electrónico con un archivo adjunto que detalla qué causó que la revisión fallara. Comuníquese con su administrador de cuentas de socios (PAM) si no tiene acceso a este correo electrónico/informe.

He corregido todos los resultados de la revisión de seguridad, ¡pero ahora he vuelto a fallar!

El informe de revisión de seguridad no es una lista de verificación exhaustiva de las cosas que se deben corregir, especialmente si hay una gran cantidad de problemas con un envío. Enumera las clases de vulnerabilidades encontradas en su aplicación, pero no todas las instancias en las que ocurren. La función de la revisión de seguridad es validar que su paquete cumpla con las mejores prácticas de seguridad actuales, que no tenga vulnerabilidades conocidas y que, en general, sea seguro promocionarlo a AppExchange, donde la confianza es nuestra prioridad número 1. La revisión de seguridad no está ahí para encontrar todos los problemas de seguridad por usted, esto es algo que debe integrarse en su proceso de desarrollo y revisarse periódicamente.

Envié mi paquete para revisión, ¿cuándo se revisará?

Hay un par de pasos para esto: una vez que lo envía, el paquete está sujeto a algunas comprobaciones iniciales antes de que se coloque en la cola de SR más grande. Esto detecta cualquier error de envío importante, como la versión incorrecta del paquete enviado, y brinda una respuesta rápida de que el paquete debe volver a enviarse. Una vez pasada esta etapa, pasa a la cola principal de SR. Debido al proceso laborioso de realizar la revisión de seguridad, hay un tiempo de espera de seis a nueve semanas. Consulte la documentación para obtener la información más reciente sobre la longitud de las colas.

¡Lanzamos mañana/la próxima semana y necesitamos que se revise ahora!

El proceso de revisión de seguridad lleva tiempo y debe tenerlo en cuenta en su ciclo de desarrollo y lanzamiento. En circunstancias excepcionales, se puede dar prioridad a una revisión en particular, pero recuerde que esto realmente significa excepcional y aún requiere que un revisor de seguridad esté disponible, lo que podría demorar varios días (¡nuestras revisiones son exhaustivas!). Comuníquese con su administrador de cuentas de socios si necesita ayuda.

Nuestro paquete no pasó la revisión de seguridad y lo hemos vuelto a enviar. ¿Podemos saltarnos la cola?

Cuando envía una nueva prueba, ya tiene un probador asignado, lo que, en cierto modo, se salta el tiempo de cola y va directamente a la cola de su probador.

¡Nuestro paquete ha fallado varias veces!

Hay varias razones por las que esto podría suceder:

Se corrigieron algunos problemas, pero no todos . Recuerde, no destacamos todo, así que verifique su código para ver todas las instancias de un problema.
Nuevo código, nuevos problemas : ¿se ha agregado un nuevo código que presenta problemas adicionales?
Malentendido de los problemas planteados : esto significa que los problemas no se solucionan correctamente.
Mal diseño de seguridad : ¿hay instancias en las que su código es inseguro por diseño? Puede requerir re-arquitectura.
¿Ha revisado minuciosamente la solución usted mismo? El propósito de la revisión de seguridad es confirmar que la solución se diseñó teniendo en cuenta la seguridad, no la van a asegurar por usted.

Cada aplicación es única, pero la mayoría de las fallas de revisión de seguridad se dividen en algunas categorías. Esta sección los detalla y proporciona enlaces a la documentación para ayudarlo a evitar estos problemas.

CRUD, FLS

Objeto (CRUD) y Seguridad de nivel de campo (FLS) : se configuran en perfiles y conjuntos de permisos y se pueden usar para restringir el acceso a objetos estándar y personalizados y campos individuales. Los desarrolladores de Salesforce deben diseñar sus aplicaciones para hacer cumplir la configuración CRUD y FLS de la organización en objetos estándar y personalizados, y degradar correctamente si se ha restringido el acceso de un usuario. Algunos casos de uso en los que podría ser aceptable omitir CRUD/FLS son: creación de resúmenes acumulativos o agregados que no expongan directamente los datos, modificación de objetos o campos personalizados como registros o metadatos del sistema que no deberían ser accesibles directamente para el usuario a través de CRUD/FLS, y casos en los que otorgar acceso directo al objeto personalizado crea un modelo de seguridad menos seguro. Asegúrese de documentar estos casos de uso como parte de su presentación. Para obtener más información, consulte la documentación de CRUD y FLS en los documentos para desarrolladores de Salesforce.
Reforzar la seguridad a nivel de campo y de objeto en Apex : el método Security.stripInaccessible para la protección de datos a nivel de campo y de objeto ya está disponible de forma general. Utilice el método stripInaccessible para eliminar los campos a los que el usuario actual no puede acceder desde los resultados de consultas y subconsultas. Utilice el método para eliminar campos inaccesibles de sObjects antes de una operación DML para evitar excepciones. Además, use el método stripInaccessible para desinfectar los sObjects que se han deserializado de una fuente que no es de confianza.
Dónde: este cambio se aplica a Lightning Experience y Salesforce Classic en las ediciones Enterprise, Performance, Unlimited y Developer.
Cómo: el método stripInaccesible verifica los registros de origen en busca de campos que no cumplan con la verificación de seguridad a nivel de campo y objeto para el usuario actual y crea una lista de devolución de sObjects. La lista de devolución es idéntica a los registros de origen, excepto que se eliminan los campos inaccesibles para el usuario actual.
Seguridad contra rayos — Debido a que el código Lightning comparte el mismo origen que el código creado por Salesforce, se imponen mayores restricciones al código Lightning de terceros. Estas restricciones se aplican mediante Lightning Locker y una Política de seguridad de contenido especial. También hay un escrutinio adicional en la revisión de seguridad de AppExchange.
Recursos externos : todo lo que interactúa con el paquete y el usuario es un objetivo para la revisión de seguridad. Es importante que el equipo de seguridad de Salesforce revise cada paquete de extensión. Incluso los paquetes pequeños pueden presentar vulnerabilidades de seguridad.
Para obtener más información, consulte: Utilice las mejoras de seguridad de Apex para reducir el tiempo de desarrollo .
Código Apex seguro con operaciones de base de datos en modo de usuario : los nuevos métodos Database y Search admiten un parámetro accessLevel que le permite ejecutar operaciones de base de datos y búsqueda en modo de usuario en lugar de en el modo de sistema predeterminado. Esta función, ahora disponible de forma general, incluye algunos cambios desde la última versión. El código de Apex se ejecuta en modo de sistema de forma predeterminada, lo que significa que se ejecuta con permisos sustancialmente elevados sobre el usuario que ejecuta el código. Esta función se introdujo en Spring '23.
Para organizaciones de segmentación por código anteriores a Spring '23, WITH SECURITY_ENFORCED es el nivel de acceso a usar.
Para las organizaciones de orientación de código posteriores a Spring '23, WITH USER_MODE es el nivel de acceso a usar.
Selección del modo de uso compartido correcto: use las palabras clave de uso compartido WITH SHARING o WITHOUT SHARING en una clase para especificar si se deben aplicar las reglas de uso compartido. Incluya siempre estos últimos en los informes de falsos positivos. Utilice la palabra clave compartida heredada en una clase para ejecutar la clase en el modo compartido de la clase que la llamó.
El uso compartido heredado es un tema avanzado y requiere una consideración adicional. Debido a que el modo de uso compartido se determina en el tiempo de ejecución, debe tener sumo cuidado para asegurarse de que su código de Apex sea seguro para ejecutarse tanto con el modo de uso compartido como sin el modo de uso compartido.

Puntos finales inseguros

Utilice siempre HTTPS cuando se conecte a puntos finales externos para insertar o extraer datos en Salesforce como parte de su aplicación. Cualquier atacante de la red puede acceder a los datos enviados a través de HTTP en texto claro y representa una amenaza para el usuario. Encuentre más información en la Guía de codificación segura .
Todos los servicios web externos a los que se hace referencia se someterán a pruebas de penetración, así que asegúrese de que estén configurados correctamente. Un problema común es cuando un servicio externo se implementa en producción en modo de depuración, lo que hace que divulgue información (seguimiento de la pila, etc.) si la prueba de penetración logra bloquearlo al enviar datos con formato incorrecto.

SOQL

Evite problemas de rendimiento comunes, como consultas SOQL, en bucles FOR anidados.
Evite los ataques de inyección de SOQL desinfectando las entradas y adoptando un estilo de programación defensivo.

Estilo CSS

CSS para LWC s debe estar en el CSS del componente, no en línea.
El CSS en línea está fuertemente desaconsejado y restringido por el modelo de seguridad de contenido .
Si su CSS rompe otro componente, fallará la revisión.
No use .THIS, fijo, absoluto o flotante en CSS. Los componentes están destinados a ser modulares y ejecutarse en páginas con otros.
1. Puede agregar una documentación de falso positivo para esto, pero debe estar bien justificada.
CSS también puede ser un vector de ataque, por lo que es importante prestar atención a esto. Consulte los siguientes recursos:
1. https://css-tricks.com/css-security-vulnerability/
2. https://www.netsparker.com/blog/web-security/private-data-stolen-exploiting-css-injection/

JavaScript

Hay numerosas recomendaciones de JavaScript a lo largo de este documento, por lo que evitaremos repetirlas aquí. Una cosa adicional a considerar es verificar las versiones heredadas de las bibliotecas, especialmente jQuery. Las versiones heredadas con vulnerabilidades conocidas harán que falle la revisión, y esto es fácil de resolver antes de tiempo. Además, vale la pena mencionar de nuevo retire.js , que se puede ejecutar como una tarea de compilación o como una extensión del navegador.
Las versiones heredadas de JavaScript que se incluyen con los paquetes son uno de los problemas más comunes y más fáciles de evitar que causan fallas; asegúrese siempre de estar usando la versión más reciente.

Política de seguridad de contenido

La descripción general de la política de seguridad de contenido es un excelente recurso sobre cómo Lightning Framework utiliza la política de seguridad de contenido (CSP) para imponer restricciones al contenido. El objetivo principal es ayudar a prevenir las secuencias de comandos entre sitios ( XSS ) y otros ataques de inyección de código.

Los navegadores web siguen las reglas de CSP especificadas en los encabezados de las páginas web para bloquear las solicitudes a servidores desconocidos de recursos, incluidos scripts, imágenes y otros datos. Las directivas de CSP también se aplican a JavaScript del lado del cliente, por ejemplo, restringiendo JavaScript en línea en HTML.

Tantos problemas vuelven a los puntos planteados en esa página, que tiene sentido replicar los puntos principales aquí:

Solo se puede hacer referencia a las bibliotecas de JavaScript desde su organización : todas las bibliotecas de JavaScript externas deben cargarse en su organización como recursos estáticos. La directiva script-src 'self' requiere que la fuente del script se llame desde el mismo origen. Para obtener más información, consulte Uso de bibliotecas de JavaScript externas .
Los recursos deben estar ubicados en su organización de manera predeterminada : las directivas font-src , img-src , media-src , frame-src , style-src y connect-src están configuradas en 'self' . Como resultado, los recursos como fuentes, imágenes, videos, contenido de marcos, CSS y scripts deben estar ubicados en la organización de forma predeterminada. Puede cambiar las directivas de CSP para permitir el acceso a recursos de terceros agregando Sitios de confianza de CSP. Para obtener más información, consulte Crear sitios de confianza de CSP para acceder a API de terceros .
Conexiones HTTPS para recursos : todas las referencias a fuentes externas, imágenes, marcos y CSS deben usar una URL HTTPS. Este requisito se aplica tanto si el recurso se encuentra en su organización como si se accede a él a través de un sitio de confianza de CSP.
URL de blob no permitidas en iframes : la directiva frame-src no permite el esquema blob:. Esta restricción evita que un atacante inyecte contenido arbitrario en un iframe en un intento de secuestro de clics. Use un enlace regular a una URL de blob y abra el contenido en una nueva pestaña o ventana en lugar de usar un iframe.
JavaScript en línea no permitido : las etiquetas de script no se pueden usar para cargar JavaScript y los controladores de eventos no pueden usar JavaScript en línea. La fuente insegura en línea para la directiva script-src no está permitida. Por ejemplo, se evita este intento de usar un controlador de eventos para ejecutar un script en línea: <button onclick = " doSomething () "></button> .

vulnerabilidades comunes

Script entre sitios (XSS) — Los ataques de Cross-Site Scripting son un tipo de problema de inyección, en el que se inyectan scripts maliciosos en sitios web de confianza y benignos. Los ataques de secuencias de comandos en sitios cruzados (XSS) ocurren cuando un atacante utiliza una aplicación web para enviar código malicioso, generalmente en forma de secuencia de comandos del lado del navegador, a un usuario final diferente. Las fallas que permiten que estos ataques tengan éxito están bastante extendidas y ocurren en cualquier lugar donde una aplicación web use la entrada de un usuario en la salida que genera sin validarla ni codificarla. Un atacante puede usar XSS para enviar un script malicioso a un usuario desprevenido. El navegador del usuario final no tiene forma de saber que no se debe confiar en el script y lo ejecutará. Debido a que cree que la secuencia de comandos proviene de una fuente confiable, la secuencia de comandos maliciosa puede acceder a cualquier cookie, token de sesión u otra información confidencial retenida por su navegador y utilizada con ese sitio. Estos scripts pueden incluso reescribir el contenido de la página HTML. Los ataques XSS almacenados son persistentes y ocurren como resultado de que la aplicación web almacene información maliciosa y luego la presente a los usuarios. Para obtener más información, consulte lawiki de OWASP .
Falsificación de solicitud entre sitios (CSRF) : CSRF es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado actualmente. Con un poco de ayuda de ingeniería social (como enviar un enlace por correo electrónico/chat), un atacante puede obligar a los usuarios de una aplicación web a ejecutar acciones de su elección. Un exploit CSRF exitoso puede comprometer los datos del usuario final y realizar acciones de cambio de estado en estos datos sin el conocimiento del usuario. Si el usuario final objetivo es la cuenta de administrador, esto puede comprometer toda la aplicación web. El uso de encabezados personalizados (incluidos métodos como PUT) para protegerse de CSRF no es un enfoque perfecto. Todavía necesita implementar el token CSRF como una medida de seguridad en profundidad.
Manejo de cookies de sesión inseguro : todas las cookies de sesión deben configurarse a través de conexiones HTTPS con el indicador SEGURO. Estas cookies deben invalidarse al cerrar la sesión, y las ID de sesión almacenadas en dichas cookies deben ser aleatorias con suficiente entropía, para evitar que un atacante las adivine con una probabilidad razonable de éxito. Los valores de las cookies nunca deben reutilizarse y deben ser únicos por usuario, por sesión. Los datos confidenciales del usuario no deben almacenarse en la cookie.

Consideraciones de código

Código comentado : se permiten comentarios en pequeños fragmentos y muestras, pero las funciones y clases completas que están comentadas deben eliminarse.
Documentación de prueba incompleta: es importante que la documentación sea lo más completa posible, incluida la documentación de sus respuestas a los falsos positivos . Esto ayuda al revisor a comprender por qué puede estar haciendo algo de una manera particular que normalmente no sería la mejor práctica, y comprender qué acciones ha tomado para mitigar cualquier problema de seguridad.
Versiones de software no seguras: Cuando se descubren nuevas vulnerabilidades en el software, es importante aplicar parches y actualizaciones a una versión del software para la que se corrige la vulnerabilidad. Los atacantes pueden crear ataques para vulnerabilidades reveladas muy rápidamente, por lo que los parches de seguridad deben implementarse tan pronto como estén disponibles. Nota: Si cree que se trata de un falso positivo, envíe un documento de falso positivo en la próxima prueba con sus motivos.
Secretos en código: no almacene secretos en código. Use configuraciones personalizadas protegidas , metadatos personalizados o credenciales con nombre, según corresponda.
Almacenamiento de datos confidenciales — Este es un recurso brillante sobre cómo trabajar de forma segura con datos confidenciales. Si su aplicación copia y almacena datos confidenciales que se originaron en Salesforce.com, debe tomar precauciones adicionales. Salesforce.com se toma muy en serio las amenazas a los datos que se originaron en su sitio, y una violación o pérdida de datos podría poner en peligro su relación con Salesforce si es un socio. Asegúrese de seguir las mejores prácticas de la industria para el almacenamiento seguro en su plataforma de desarrollo. Nunca almacene contraseñas de Salesforce fuera de la plataforma.
Acceso al sistema externo, exfiltración de ID de sesión: la postura de seguridad sobre el uso de ID de sesión se ha endurecido significativamente en los últimos años. Específicamente, enviar el ID de sesión a un sistema externo a través de la API dará como resultado una falla automática en el futuro. Las alternativas sugeridas son usar un usuario de integración dedicado u OAuth como alternativas modernas. Borrador de orientación (se requiere iniciar sesión en la Comunidad de socios ).
Eco de contraseña : almacenar información confidencial en el código fuente de su aplicación rara vez es una buena práctica, ya que cualquiera que tenga acceso al código fuente puede ver los secretos en texto claro.

Fuga de información

La fuga de información implica la revelación inadvertida de datos del sistema o la información de depuración que ayuda a un adversario a aprender sobre el sistema y formar un plan de ataque. Se produce una fuga de información cuando los datos del sistema o la información de depuración abandonan el programa a través de un flujo de salida o una función de registro.

Información confidencial en la depuración: revelar información en las declaraciones de depuración puede ayudar a revelar posibles vectores de ataque a un atacante. Las declaraciones de depuración pueden ser invaluables para diagnosticar problemas en la funcionalidad de una aplicación, pero no deben divulgar públicamente información confidencial o demasiado detallada (esto incluye PII, contraseñas, claves y seguimientos de pila como mensajes de error, entre otras cosas).
Información confidencial en la URL: no olvide que uno de los medios de transferencia de datos más simples es la propia URL. La información confidencial que se pasa a través del método GET (HTTP GET Query String) a la aplicación web puede provocar una fuga de datos y exponer la aplicación de varias maneras. La URL completa a menudo se almacena "tal cual" en el servidor en registros de texto claro que pueden no almacenarse de forma segura, el personal puede verlos y un tercero puede comprometerlos. Los motores de búsqueda indexan las URL que almacenan información confidencial sin darse cuenta. Almacenamiento de rutas URL completas en el historial del navegador local, caché del navegador, marcadores y marcadores sincronizados entre dispositivos. La información de URL se envía a aplicaciones web de terceros a través del encabezado de referencia. Los secretos a largo plazo, como nombre de usuario/contraseña, tokens de acceso de larga duración y tokens de API, no deben enviarse en URL.
Configuración TLS/SSL: debido a las restricciones de exportación históricas de la criptografía de alto grado, los servidores web heredados y nuevos a menudo pueden y están configurados para manejar opciones criptográficas débiles. Incluso si normalmente se usan e instalan cifrados de alto grado, se podría usar alguna configuración incorrecta del servidor para forzar el uso de un cifrado más débil para obtener acceso al supuesto canal de comunicación seguro. El servidor no debe admitir cifrados, como SSL v2/SSL v3/TLS v1.0/TLS v1.1, o cifrados que utilicen un cifrado NULL o que tengan longitudes de clave débiles. TLS 1.0 y 1.1 han sido declarados al final de su vida útil por la mayoría de los sistemas y ya no deben usarse. Consulte: Pruebas de SSL-TLS . Actualmente, Salesforce requiere TLS 1.2 o superior.

Me gustaría hablar con el revisor.

Esto se puede arreglar, generalmente, con un mínimo de tres semanas de anticipación ya que el servicio es popular. Los revisores de seguridad tienen horario de oficina y los equipos pueden programar una sesión con ellos para analizar los resultados de una revisión. Si su paquete ha fallado un par de veces, puede valer la pena programar una cita justo después de la próxima revisión para hablar con un ingeniero de seguridad. Reserve su sesión de horario de oficina a través del Portal de seguridad para socios .

Falsos positivos

Hay momentos en los que tiene una razón legítima para hacer algo de cierta manera y ha tomado medidas para garantizar la seguridad de los datos. Estas instancias deben estar claramente marcadas en el código y deben proporcionarse comentarios para evitar falsos positivos . Sin embargo, si encuentra que tiene muchas excepciones en su código, es posible que deba considerar si su código sigue un antipatrón y necesita una nueva arquitectura.

La seguridad es un estado de ánimo, no una casilla de verificación

El propósito de la revisión de seguridad es validar que ha tomado todas las precauciones necesarias. Muchos socios tienen su primer paquete que no pasa la revisión de seguridad la primera vez, y hacen que su prioridad sea que esto no vuelva a suceder, por lo que revisan agresivamente el código de todos sus paquetes y dependencias, como servicios web externos. Esto es beneficioso para todos: hace que el proceso de revisión de seguridad sea más rápido y el socio es proactivo con respecto a la seguridad: este es el objetivo final .

Hay muchas herramientas disponibles, cada una con su propio enfoque. Úselos para ayudar en el análisis de seguridad, pero recuerde que la seguridad es una mentalidad y un proceso arquitectónico explícito. Si bien las herramientas pueden detectar patrones particulares, antipatrones y otros problemas, nunca tendrán la comprensión completa de lo que la solución está tratando de hacer o la mentalidad de un revisor humano. Aquí hay más información sobre algunas de estas herramientas:

Analizador de código de Salesforce (Anteriormente Escáner CLI de Salesforce): esta es una herramienta desarrollada internamente para el análisis estático del código fuente. Es útil usar esto como parte de su proceso de desarrollo en curso. Consulte publicaciones de blog anteriores sobre esta herramienta como referencia:
1. Desarrolle un código aún más seguro con Salesforce Code Analyzer.
2. Mejore la calidad de su código con el escáner CLI de Salesforce
Chimera : este es un servicio de escaneo en tiempo de ejecución basado en la nube que se puede usar para escanear sitios web de terceros. Tenga en cuenta que Chimera es solo para sitios web de su propiedad o en los que puede cargar un token.
Escáner de código fuente (Checkmarx) — Source Code Scanner le permite programar escaneos, descargar informes de escaneos, buscar todos los escaneos para su organización y administrar los créditos de escaneo para sus organizaciones. Para obtener más información, consulte las preguntas frecuentes de Checkmarx .
ZAP : Zed Attack Proxy es un escáner web de código abierto de OWASP.org y se puede usar para escanear sitios web de terceros.
Vulnerabilidades y exposiciones comunes : CVE® es un diccionario de vulnerabilidades y exposiciones de seguridad cibernética divulgadas públicamente cuya búsqueda es gratuita.
Retire.js — Hay una gran cantidad de bibliotecas de JavaScript para usar en la web y en las aplicaciones de Node.js. Esto simplifica enormemente las cosas, pero debemos mantenernos actualizados sobre las correcciones de seguridad. El "Uso de componentes con vulnerabilidades conocidas" ahora forma parte del OWASP Top 10 y las bibliotecas inseguras pueden representar un gran riesgo para su aplicación web. El objetivo de Retire.js es ayudarte a detectar el uso de versiones con vulnerabilidades conocidas.
Base de datos nacional de vulnerabilidades : NVD es el repositorio del gobierno de EE. UU. de datos de gestión de vulnerabilidades basados en estándares representados mediante el Protocolo de automatización de contenido de seguridad (SCAP).

¿Cómo presento una revisión de seguridad?

Usted envía su paquete para su revisión a través de la Comunidad de socios . Antes de hacerlo, consulte la guía de ISVforce para obtener la orientación más reciente y asegúrese de leer toda la información en este artículo.

Modelo de precios por revisión

Tenga en cuenta que, a partir del 16 de marzo de 2023, las tarifas de revisión de seguridad pasarán a ser un modelo por intento.

Se elimina la tarifa de revisión inicial de $2,550.
Se elimina la cuota anual de $150.
La tarifa de revisión de seguridad es de $999 por intento para aplicaciones pagas.

¿Qué pasa con las aplicaciones gratuitas? ¿Aquí también se aplicará la nueva tarifa?

En el momento de escribir este artículo, el estado de las aplicaciones gratuitas es el siguiente:

No habrá tarifas por revisiones de seguridad para soluciones gratuitas mientras trabajamos para redefinir la política.

Sin embargo, consulte la página de actualizaciones de tarifas y la discusión para obtener la información más reciente.

Versiones de paquetes

Envíe una versión puntual (p. ej., 16.7→16.8, etc.), no una versión de parche (16.7. 1234 ). El escáner de seguridad en el portal de socios está diseñado para funcionar solo con versiones principales y secundarias (Mayor.Minor). Las versiones de parches (Major.Minor.PATCH) no son compatibles y se filtran deliberadamente de la lista de paquetes disponibles. La mayoría de los problemas que encuentran los socios cuando su paquete no está visible en el escáner de seguridad se resuelven creando una nueva versión Major.Minor (p. ej., 16.7→16.8).

Envío de paquetes múltiples

Al enviar una solución que consta de varios paquetes, es importante ser explícito en el caso de los paquetes incluidos en la organización y su relación entre ellos.

Por ejemplo:
xx = paquete base
yy – depende de xx
zz depende de xx + yy

Solo los paquetes directamente relacionados con el envío de revisión de seguridad deben estar en la organización; de lo contrario, se rechazará el envío.

Tras el envío: comprobaciones previas a la cola

Una vez que se ha enviado un paquete, entra en un estado de cola previa donde se realizan comprobaciones para confirmar la validez del envío. Es posible que estos pasos tarden unos días en comprobarse manualmente antes de que el paquete pase a la cola oficial de SR.

Paquete(s) enviado(s) correcto(s) : el paquete debe administrarse. No se permiten paquetes beta, no administrados o desbloqueados.
No se enviaron otros paquetes : si hay paquetes adicionales (consulte Envío de paquetes múltiples ), proporcione una explicación detallada sobre la dependencia del paquete.
El acceso a la organización de prueba está validado : 2FA/MFA debe estar deshabilitado, para que el equipo de prueba pueda iniciar sesión para probar. Del mismo modo, para una aplicación web o un sitio remoto, asegúrese de proporcionar las credenciales de trabajo.

El proceso de revisión de seguridad está diseñado para validar que ha tomado buenas decisiones sobre la higiene de los datos y ha considerado una seguridad por diseño en su aplicación. Cuanto más piense en la seguridad por diseño, más fácil será el proceso de envío. Esta publicación le brinda una ventaja sobre las cosas que debe hacer y evitar hacer para que su revisión sea un proceso lo más fluido posible.

Recursos

Sobre el Autor

Jonathan McNamee es un evangelista técnico con sede en el Reino Unido en Salesforce, que ayuda a los socios ISV a aprovechar al máximo su inversión en la plataforma de Salesforce. Tiene 20 años de experiencia en el desarrollo de soluciones de tecnología web para empresas de todos los tamaños en una variedad de industrias y ha estado trabajando en el ecosistema de Salesforce desde 2020. Sus intereses incluyen la escalabilidad, la eficiencia y la resiliencia de los sistemas. Síguelo en LinkedIn .