Cómo verificar la procedencia del software en marketplaces

La procedencia del software se verifica en el distribuidor y en el archivo instalado. El equipo de compras compara el artefacto con una referencia independiente y autenticada y define quién interrumpe su uso. El 29 de octubre de 2026 aparecieron en el marketplace de Cursor versiones maliciosas de una extensión, un componente instalado que añade funciones a un programa.

El aviso de Cursor, actualizado el 30 de octubre, identifica las versiones 2.1.312 y 2.1.313 de Anthropic.claude-code, para Windows y macOS, disponibles aproximadamente entre las 2:27 y las 13:35, hora del Pacífico. Las versiones modificadas se distribuyeron en el marketplace de Cursor, pero no fueron desarrolladas por Anthropic. El aviso no identifica organizaciones, clientes ni países afectados, ni informa de una compra pagada. El caso no demuestra una falla de un comprador.

¿Qué reunir antes de evaluar la compra?

La evaluación comienza con la propuesta, el contrato disponible, el fabricante y el canal de entrega, además del inventario de las extensiones previstas. Compras debe reunir a ingeniería, seguridad y finanzas antes de la firma, porque cada equipo responde por una parte de la aprobación y ninguno puede completarla por sí solo.

El inventario debe relacionar producto, identificador de la extensión, versión, sistema operativo, usuarios previstos y responsable interno, para que seguridad localice las instalaciones cuando haya una alerta sobre ese paquete. En una estación administrada, o endpoint, es necesario definir quién autoriza las instalaciones y quién las restringe.

La aceptación sigue cinco pasos.

1. Identificar quién vende y quién distribuye.
2. Comprobar la identidad y la integridad del artefacto.
3. Acordar la respuesta a incidentes con las partes involucradas.
4. Limitar la autoridad concedida en la máquina.
5. Definir y probar la desconexión.

Cada paso exige evidencia.

Paso 1: ¿quién vende y quién distribuye el software?

La cadena de suministro de software comienza antes del contrato: quien fabrica, quien firma y quien entrega el archivo pueden ser partes diferentes. Compras registra esas identidades y obtiene confirmación del canal autorizado para cada componente, pues el nombre en la propuesta no identifica por sí solo el origen del paquete instalado en la estación.

En la comparación entre compra directa y marketplace, la ruta comercial ayuda a identificar quién responde por la propuesta. En cualquiera de las rutas, el comprador confirma quién contrata, quién emite el documento fiscal y quién entrega la extensión. La ruta comercial no sustituye la comprobación de la procedencia del software.

Cada respuesta exige un documento o una confirmación escrita antes de la compra.

La Receita Federal, autoridad tributaria federal de Brasil, describe la NFS-e, factura electrónica de servicios de Brasil, como un documento digital que formaliza la prestación de servicios. No verifica los bytes del artefacto. Finanzas y el equipo jurídico analizan el documento aplicable a la operación; la lectura sobre importación y factura aborda por separado la documentación de respaldo.

Nexforce Marketplace ofrece una ruta para contratar software internacional con pago local y gestión centralizada. En ambas rutas, compras confirma facturación, pago, fabricante y canal. La contratación local no sustituye la verificación del archivo.

Paso 2: ¿cómo verificar la procedencia del software en el artefacto?

La verificación de la procedencia del software compara el artefacto recibido con una referencia autenticada e independiente del canal de entrega, vinculada al identificador, la versión y la plataforma correctos. Cuando haya una firma verificable, seguridad también debe examinar quién firmó y si la cadena de confianza sigue siendo válida.

Un hash es un resumen calculado a partir del contenido de un archivo, y la verificación de extensiones de software depende de una referencia que no provenga del mismo canal. Si el hash del artefacto recibido difiere de la referencia confiable, la instalación no supera la aceptación. Si coincide, la comparación indica que los archivos coinciden para ese cálculo, pero no demuestra autoría cuando el archivo y la referencia provienen del mismo canal comprometido. La fuente independiente debe estar autenticada. La comprobación se repite con cada actualización, no solo en la instalación.

La firma digital permite comprobar la integridad y la identidad asociada a la firma. El equipo verifica al firmante. Examina la cadena de confianza. Verifica la revocación según el formato del archivo. Sin un hash confiable o una firma verificable, compras registra la brecha para dejarla pendiente o tramitar una excepción formal. La clasificación de hallazgos de seguridad complementa la verificación de procedencia del software, pero no la sustituye.

En el caso comunicado por Cursor, los hashes publicados identifican archivos maliciosos y sirven para la detección. No son hashes de referencia confiables. El equipo debe separar el material utilizado para buscar indicios de compromiso de la referencia autenticada usada para aceptar una nueva instalación.

Paso 3: ¿cómo acordar la respuesta a incidentes en el contrato?

El contrato debe dejar claro quién avisa, por qué canal y a partir de qué momento comienza el plazo de notificación negociado. Compras y el equipo jurídico obtienen esos compromisos antes de la firma y confirman cómo apoyará el proveedor la investigación y la corrección cuando un artefacto sospechoso llegue a las máquinas.

La negociación solicita versiones y plataformas afectadas, ventana de exposición, indicadores y actualizaciones. El plazo necesita un punto de inicio y un destinatario definidos. Las partes acuerdan la preservación de evidencias, el apoyo a la investigación y las instrucciones de corrección. El equipo jurídico evalúa las notificaciones y responsabilidades aplicables a la operación, sin presumir obligaciones a partir del caso de Cursor.

Son propuestas, no cláusulas atribuidas. El costo total incluye investigación y restauración, incluso cuando la propuesta no las desglosa.

Paso 4: ¿cómo limitar la autoridad en la máquina del desarrollador?

La empresa debe autorizar una extensión por el acceso necesario, no por la función anunciada. Ingeniería y seguridad deben examinar el acceso a repositorios, archivos locales, terminal, red y credenciales, y distinguir los permisos de la extensión de los que pertenecen al usuario o al administrador de la máquina.

Una extensión ejecutada en el contexto del usuario puede alcanzar recursos accesibles para esa cuenta; el acceso administrativo es otra decisión y debe seguir un proceso propio. El inventario debe registrar qué componentes pueden iniciar procesos, modificar configuraciones o permanecer activos después de cerrar el programa. El equipo revisa la necesidad de esos accesos cuando cambie la versión o la función.

En el aviso de Cursor, el código intentaba agregar una clave SSH controlada por el atacante, habilitar el servicio SSH local y abrir un túnel inverso. La etapa de habilitar el servicio exigía privilegios de administrador que la extensión no tenía en la mayoría de los hosts; en esos hosts, la etapa falló. Según el aviso, se agregó la clave, se instaló la persistencia y se enviaron datos del host. Esto no demuestra acceso remoto en todos los dispositivos. Tampoco demuestra robo de credenciales.

Paso 5: ¿cómo definir y probar la desconexión?

La desconexión debe cubrir la distribución y la ejecución en máquinas ya expuestas. Antes de la compra, seguridad y operaciones definen quién retira un paquete del canal, quién bloquea la ejecución en los endpoints administrados y quién aísla un dispositivo con evidencia de compromiso.

Compras y el equipo jurídico registran en el contrato qué medidas de desconexión corresponden al proveedor y cuáles al canal, después de confirmar el reparto. El retiro del catálogo no elimina la persistencia instalada. Cursor informa que retiró las versiones, bloqueó la distribución y reconstruyó el marketplace; desinstalar la extensión puede no ser suficiente. La empresa exige instrucciones de recuperación verificables.

La prueba parte del inventario de versiones y confirma si los equipos pueden localizar instalaciones, bloquear la ejecución y registrar a los responsables. La prueba simula la llegada de una versión nueva antes de la comprobación. Seguridad preserva las evidencias antes de la limpieza y verifica el regreso al uso. La ausencia de un indicador no demuestra que la máquina esté limpia.

Ante evidencia de ejecución maliciosa, el plan debe permitir el aislamiento, la investigación, la eliminación de la persistencia y la evaluación de la reconstrucción del dispositivo. El equipo responsable evalúa la rotación de credenciales y sesiones desde un sistema confiable y registra el resultado.

¿Cómo verificar que la compra está lista para aprobación?

La compra está lista cuando cada requisito cuenta con evidencia aceptada por el equipo competente y con un responsable de la decisión. Las brechas quedan pendientes o se tramitan mediante una excepción formal, con riesgo, plazo, responsable y compensaciones documentados; una aprobación comercial aislada no sustituye la aceptación técnica antes de la instalación.

La matriz reúne exigencias para el comprador, no garantías de un proveedor, y organiza la seguridad en la compra de software en evidencias verificables.

Aprobado significa que los seis controles fueron aceptados para las versiones aprobadas. Pendiente indica falta de evidencia o de prueba. La excepción formal exige una decisión de la autoridad competente, fecha de revisión y medidas compensatorias; no convierte una verificación ausente en una verificación concluida.

¿Qué errores evitar en la compra?

Un error es tratar un documento comercial como un control que no ejecuta. La factura, el hash y el retiro del catálogo responden a preguntas diferentes; el equipo debe conservar esa distinción en el registro y revisarla cuando el software cambie de versión.

La factura documenta la operación a la que se refiere, mientras que la integridad del archivo depende de una comprobación técnica. Un hash copiado del mismo canal sospechoso no demuestra autoría. Y retirar una extensión del marketplace no limpia por sí solo las máquinas en las que ya se ejecutó. Son brechas distintas, con responsables distintos.

Preguntas frecuentes

La factura no autentica una extensión y retirar un paquete del catálogo no limpia los dispositivos en los que ya se ejecutó. La decisión de compra exige evidencia técnica. Sin una referencia confiable, la aceptación debe quedar pendiente o tramitarse mediante una excepción formal evaluada por la autoridad competente.

¿La factura demuestra la autenticidad de la extensión?

No. La NFS-e formaliza la prestación de servicios en el alcance descrito por la Receita Federal; no verifica el archivo instalado. El comprador debe pedir al proveedor la identificación del canal y la evidencia técnica aplicable, además de pedir a finanzas el análisis del documento de la operación.

¿Basta un hash igual al publicado por el canal?

No cuando el archivo y el hash provienen del mismo canal que pudo haber sido comprometido. La comparación exige una referencia independiente y autenticada para la versión y la plataforma correctas. Sin esa referencia o una firma verificable, la decisión queda pendiente o se tramita mediante una excepción formal.

¿El retiro del catálogo resuelve el incidente?

Puede interrumpir nuevas entregas por el canal, pero no garantiza la eliminación de una clave, un proceso o la persistencia en los endpoints. Seguridad debe investigar los dispositivos expuestos y seguir el plan documentado de contención y recuperación. La ausencia aislada de un indicador tampoco demuestra que el dispositivo esté limpio.

¿Quién debe aprobar la compra?

Compras coordina la decisión comercial, pero ingeniería y seguridad deben aceptar las evidencias técnicas y la prueba de desconexión. El equipo jurídico evalúa los compromisos negociados y finanzas comprueba la documentación de la operación. Cuando hay una brecha, la autoridad interna de riesgo decide sobre la excepción documentada.

Referencias y Lectura Complementaria

Las siguientes fuentes tratan puntos diferentes de la decisión de compra: el aviso de Cursor describe el incidente y sus indicadores, mientras que la Receita Federal explica la finalidad documental de la NFS-e. Ninguna de ellas demuestra la integridad del archivo. Un contrato firmado no sustituye la prueba técnica.

• Cursor: aviso de seguridad de la extensión
• Receita Federal: emisión de NFS-e de estándar nacional

¿Cómo hacer operativa la próxima compra?

La instalación no debe autorizarse solo porque se firmó el contrato o llegó la factura. La próxima adquisición debe quedar registrada con un canal autorizado, evidencia de procedencia del software y un responsable de la contención. Nexforce Marketplace puede estructurar la contratación local; la verificación del artefacto y la respuesta técnica siguen exigiendo responsables y pruebas propias.