御盾Conclusiones y condiciones de decisión.
- No envíe meramente un instalador con el mismo nombre; debe registrar su origen, versión, resumen del archivo (digest), plan de firma y canales de distribución previstos.
- No solicite simplemente «máxima fortaleza»; especifique qué lógica, si se invierte ingeniería o modifica, causaría pérdidas comerciales específicas.
- El stack tecnológico debe cubrir lenguajes, sistemas de compilación, versiones mínimas del SO, ABIs, componentes nativos, carga dinámica, marcos multiplataforma y SDKs de terceros.
- Defina las condiciones de éxito, fallo, alcance no cubierto, parada y reversión antes de la PoC para evitar confundir un lanzamiento exitoso con la preparación para producción.
Proporcione primero un candidato de lanzamiento únicamente identificable
El candidato de lanzamiento sirve como objeto común para la configuración, pruebas y conclusiones posteriores. Como mínimo, proporcione el nombre del paquete o Bundle ID, versión, origen de compilación, SHA-256 del archivo, estado actual de firma, plan de firma objetivo y canales de distribución previstos. Si la entrega del archivo es temporalmente imposible, indique claramente si el proyecto se encuentra en la fase de arquitectura, desarrollo, integración o preparación para el lanzamiento.
Los archivos con el mismo nombre no representan el mismo artefacto. Recompilar, volver a firmar, modificar recursos de canal o reemplazar dependencias genera una nueva identidad. Para cada cambio, especifique qué validaciones deben volver a ejecutarse; no aplique conclusiones de aprobación de candidatos antiguos directamente a nuevos archivos.
Cuando se trate de código propietario o datos de usuario, envíelos mediante el flujo de trabajo controlado del proyecto en la plataforma central de Yudun. Los sitios públicos de temas solo proporcionan métodos y puntos de entrada; no aceptan cuentas, instaladores, certificados ni secretos del proyecto.
| Campo | Contenido de ejemplo | Propósito | Lagunas comunes |
|---|---|---|---|
| Identidad de la aplicación | Nombre del paquete o Bundle ID, Versión | Se asigna al alcance de lanzamiento, actualización y pruebas | Solo se proporciona el nombre de la tienda |
| Identidad del archivo | SHA-256 y hora de generación | Garantiza que todas las pruebas apunten al mismo archivo | Sobrescribir archivos antiguos con el mismo nombre |
| Origen de compilación | Rama, Commit, trabajo de CI o registro de lanzamiento | Trazabilidad de incidencias y recompilación | Incapacidad para especificar el origen |
| Plan de firma | Estado actual, certificado final y pasos de firma | Valida la identidad de actualización y lanzamiento | Vuelta a firmar arbitrariamente después de la PoC |
| Alcance de distribución | Tiendas, canales empresariales o privados | Determina las señales de integridad y las comprobaciones de entrega | Asumir que todos los canales son idénticos |
Definir la pérdida comercial para el código que requiere protección
«Máxima fortaleza», «protección total» y «anti-craqueo» no son requisitos ejecutables. Enumere algoritmos centrales, comprobaciones de autorización, manejo de protocolos, derechos de contenido, modelos o decisiones locales críticas, y explique la pérdida específica incurrida si estos se comprenden, copian, modifican o eluden.
Explique simultáneamente por qué esta lógica debe permanecer en el lado del cliente. Las autorizaciones de alto riesgo que pueden gestionarse en el servidor deben decidirse primero en el servidor; la protección en el cliente debe evaluarse solo para rutas que requieran capacidad sin conexión, baja latencia o funciones nativas de la plataforma. Esto asegura que el VMP se reserve para el código que realmente requiere una representación de ejecución alterada.
Cada activo debe tener también un propietario, punto de entrada de invocación, frecuencia de ejecución, contexto de hilo, definiciones de entrada/salida, dependencias y plan de contingencia ante fallos. Los activos sin rutas de aceptación independientes deben incorporar primero condiciones de prueba, independientemente de su valor.
| Tipo de activo | Pérdida a describir | Necesidad en el lado del cliente | Preparación de aceptación sugerida |
|---|---|---|---|
| Autorización y derechos | Recursos accesibles si se omiten las ramas locales | Capacidad offline o juicio local rápido | Estados normal, caducado, manipulado y de reverificación en servidor |
| Algoritmos centrales | Valor comercial perdido en caso de copia | Rendimiento on-device, privacidad o necesidades offline | Consistencia de entrada/salida, rendimiento y datos límite |
| Protocolo y uso de claves | Consecuencias de replay, falsificación o abuso masivo | Vinculación al dispositivo o comunicación local | Gestión de errores, detección de replay, rotación y límites del servidor |
| Modelos o reglas on-device | Replicación y modificación de modelos, prompts o postprocesamiento | Requisitos offline, de privacidad o de baja latencia | Emparejamiento de versiones, carga, rollback y registro |
| Interfaces críticas de terceros | Consecuencias de omitir el SDK o invocar incorrectamente | Requisitos de plataforma o canal | Cuentas reales, firmas y rutas de callback |
El inventario del stack tecnológico define los límites de las pruebas de compatibilidad
Los proyectos Android deben especificar versiones de Java, Kotlin, NDK, Gradle y Android Gradle Plugin, minSdk, targetSdk, ABIs publicadas, y el uso de reflexión, serialización, carga dinámica de clases, hotfixes, pluginización, WebView, componentes nativos y arquitecturas multiproceso. Los proyectos iOS deben especificar Swift, Objective-C, versión mínima del SO, extensiones, bibliotecas dinámicas, características del runtime y capacidades de firma.
Para Flutter, React Native, Unity, Cocos u otros frameworks multiplataforma, registre la versión del framework, método de puente, motor y bibliotecas nativas de negocio. No se limite a indicar "multiplataforma", ya que la estructura del artefacto, el comportamiento de inicio y las integraciones de terceros varían significativamente entre versiones.
El inicio de sesión de terceros, pagos, notificaciones push, mapas, audio/vídeo, analítica, control de riesgos, hotfixes y servicios de proveedores pueden depender de reflexión, firmas, entradas del Manifest, URL Schemes, JNI, recursos o sus propias comprobaciones de integridad. Listarlos completamente durante la evaluación inicial ahorra más tiempo que intentar adivinarlos uno a uno tras producirse caídas.
- Idiomas, sistemas de compilación y versiones principales de plugins
- SO, dispositivos y ABIs mínimos y objetivo
- Componentes nativos, JNI, carga dinámica y frameworks multiplataforma
- Multiproceso, WebView, hotfixes y pluginización
- SDKs críticos: inicio de sesión, pago, push, audio/vídeo, etc.
Definir firma, canales y planes de actualización antes del PoC
Especifique qué firma usa el artefacto del PoC, quién firma la versión formal, si los recursos de canal se procesan antes o después de la firma, si se usa Play App Signing y qué método de distribución se emplea para iOS. Estos factores afectan a la instalación, actualizaciones, señales de integridad e identidad final del archivo.
Android establece oficialmente que las claves de firma de aplicaciones confirman que las actualizaciones provienen del mismo titular de clave. Si el PoC usa un certificado temporal, solo valida ese entorno específico y no demuestra automáticamente cobertura para versiones en producción. La aceptación formal debe usar un plan de firma consistente con la cadena de lanzamiento, permitido por los flujos de autorización y seguridad.
El procesamiento de canales debe seguir un orden fijo. Modificar el cuerpo del paquete tras la firma final rompe la firma; reconstruir o volver a firmar tras la aceptación genera un nuevo candidato. Las versiones de rollback también deben verificar de antemano firmas, números de versión, migración de datos y actualizaciones por sobrescritura.
| Pregunta | Por qué es importante | Estado aceptable del PoC | Requisito de aceptación formal |
|---|---|---|---|
| ¿Quién realiza la firma final? | Determina la responsabilidad sobre la clave y la identidad del artefacto | Firma temporal con limitaciones claras | Consistente con el proceso formal y auditable |
| ¿Cuándo se modifica el cuerpo del paquete para los canales? | La modificación altera el archivo y el contenido firmado | El orden puede describirse | Completado antes de la firma con identidad re-fijada |
| ¿Cómo cubrir las versiones en línea? | Valida la firma y la continuidad de la versión | Puede omitirse, pero se marca como no cubierto | Actualización desde una versión en línea real |
| ¿Cómo realizar un rollback? | Debe ser ejecutable durante incidentes | Preparar candidato de línea base | Paquete de rollback pre-verificado con propietario asignado |
Definir de antemano las condiciones de éxito, fallo y parada para la PoC
Una PoC no es simplemente generar un paquete endurecido instalable. Predetermine el alcance de protección a observar, la superficie de exposición estática, el comportamiento de inicio, los flujos de negocio críticos, el presupuesto de rendimiento, los sistemas objetivo, las ABIs, los SDKs de terceros, la instalación/actualizaciones y las caídas por excepción. Cada proyecto puede tener pesos diferentes, pero ninguno puede carecer de definiciones.
Las condiciones de éxito deben ser medibles, como entradas/salidas de clave consistentes, aprobación de los sistemas objetivo elemento por elemento, cambios de arranque dentro del presupuesto del proyecto, rutas de excepción seguras y configuraciones de protección rastreables. Las condiciones de fallo incluyen bloqueo de arranque, errores críticos de negocio, cambios de rendimiento inaceptables, fallos de compatibilidad dentro del alcance objetivo o problemas no atribuibles.
Las condiciones de parada evitan la expansión ciega del alcance. Si las identidades de los candidatos son inconsistentes, faltan líneas base, los registros críticos no están disponibles, los flujos de firma no están confirmados o los entornos de prueba no coinciden con el alcance de lanzamiento, aborde estas brechas antes de continuar.
| Estado | Significado | Requisito de informe | ¿Publicable? |
|---|---|---|---|
| Verificado | Evidencia obtenida para el mismo candidato dentro del alcance acordado | Especificar método, entorno, resultados y límites | Juicio válido solo para ese alcance |
| Fallido | Ocurrió un bloqueo reproducible o incumplimiento del presupuesto | Conservar las primeras diferencias y el impacto | No se puede publicar con la configuración original |
| No ejecutado | Faltan dispositivos, cuentas, datos o autorización | Indicar motivo y siguientes pasos | No se puede sustituir con otros resultados |
| No aplicable | El proyecto excluye explícitamente esta plataforma o capacidad | Proporcionar la base para la determinación | Excluido del alcance actual |
project_stage: release-candidate
artifacts:
baseline: identified
protected_candidate: pending
assets:
- entitlement-decision
- protocol-core
stack:
platform: Android
min_os: project-defined
abis: [arm64-v8a]
critical_journeys:
- cold-launch
- sign-in
- protected-operation
acceptance:
functional_parity: required
performance_budget: project-defined
compatibility_matrix: required
rollback_rehearsal: required
boundaries:
- no_unverified_attack_resistance_claim
- uncovered_devices_remain_openEntregables formados por la evaluación de Yudun tras la entrega completa de datos
La entrada completa soporta tres fases consecutivas. La Fase Uno confirma activos, pila tecnológica y cadena de lanzamiento para formar un alcance de protección inicial y una lista de riesgos. La Fase Dos genera una PoC trazable y ejecuta comprobaciones estáticas y en tiempo de ejecución sobre la misma identidad de candidato. La Fase Tres ajusta el alcance según los resultados para finalizar la matriz objetivo, los límites de lanzamiento y las condiciones de rollback.
Las capacidades de protección específicas, el soporte de plataforma, los presupuestos de rendimiento y los ciclos de entrega deben confirmarse contra proyectos reales. Esta página no utiliza casos de clientes, tasas de aprobación ni cifras de rendimiento genéricas, ni promete resultados finales sin un candidato de lanzamiento.
El inicio de sesión, registro, solicitudes, precios y datos del proyecto están unificados dentro de la plataforma central de Yudun. Los sitios temáticos no establecerán un segundo conjunto de cuentas o sistemas de aplicación. Organice los materiales según esta lista de verificación antes de la entrega para evitar suplementar repetidamente identidades de candidatos y alcances de lanzamiento después del inicio del proyecto.
- Candidato de lanzamiento, línea base y cadena de lanzamiento trazables
- Descripción clara de los activos protegidos y las pérdidas de negocio
- Pila tecnológica completa, dependencias de terceros y matriz objetivo
- Condiciones de éxito, fallo, alcance no cubierto y rollback definidas
- Enviar datos sensibles solo a través de la plataforma central
Límites de evidencia y aplicabilidad
Esta sección separa los datos documentados de la plataforma, los juicios de ingeniería y los límites que no se pueden generalizar en afirmaciones de productos no verificadas.
| Sentencia del artículo | Base de hecho o ingeniería | Límite de aplicabilidad |
|---|---|---|
| La identidad del candidato de lanzamiento es la clave primaria común para la evidencia de evaluación. | La recompilación, firma, modificaciones de canal y cambios de dependencias alteran el archivo final y el comportamiento potencial en tiempo de ejecución. | SHA-256 identifica el archivo, pero no implica que el archivo sea seguro. |
| Los objetivos de protección VMP deben derivarse de la pérdida de negocio y el modelado de amenazas. | OWASP MASVS trata la anti-ingeniería inversa y la anti-manipulación como defensa en profundidad contra amenazas específicas, no como reemplazos de la lógica del lado del servidor o la arquitectura general. | Los estándares no pueden demostrar que un candidato o configuración específicos hayan superado las pruebas. |
| Los planes de firma y actualización deben cerrar el ciclo en la aceptación formal. | Android utiliza la identidad de firma de la aplicación para confirmar la continuidad de las actualizaciones; las plataformas de Apple también exigen que el código ejecutable siga la cadena de firma de código. | Los diferentes métodos de distribución y estrategias de rotación de certificados deben verificarse por proyecto. |
| La capacidad de instalar y lanzar no constituye una conclusión completa de una prueba de concepto (PoC). | El lanzamiento también implica flujos de negocio críticos, rendimiento, sistemas, ABIs, terceros, actualizaciones, monitoreo y reversión. | Los proyectos pueden recortar la matriz según el alcance real del usuario, pero los elementos no cubiertos deben declararse explícitamente. |
| Los sitios temáticos no aceptan datos sensibles del proyecto. | Las cuentas, aplicaciones y datos del proyecto son gestionados uniformemente por la plataforma central de Yudun; los sitios de contenido solo proporcionan métodos públicos y redirecciones. | Los permisos específicos de datos y las reglas de retención están sujetos a la plataforma central y a los acuerdos del proyecto. |
Preguntas de ingeniería
¿Puedo solicitar una evaluación solo con un APK y sin código fuente?
Puede confirmar primero el artefacto y los objetivos, pero la configuración de protección, la atribución de problemas y las capacidades de recompilación pueden ser limitadas. Debe especificar si puede proporcionar cooperación en la compilación, símbolos, cuentas de prueba y líneas base.
¿Es obligatorio proporcionar la firma formal durante la primera comunicación?
No necesariamente. Se puede utilizar una firma de prueba controlada para una PoC parcial, pero debe indicarse claramente que esto no representa actualizaciones en producción ni la cadena de firma formal. El plan de lanzamiento debe completarse antes de la aceptación formal.
¿Por qué listar todos los SDK de terceros?
Los SDK de terceros pueden depender de reflexión, firmas, recursos, JNI, orden de inicialización o sus propias verificaciones de integridad, lo que los convierte en una fuente significativa de problemas de compatibilidad.
¿Puedo solicitar directamente la máxima fortaleza?
Puede indicar sus preferencias de riesgo, pero el alcance final debe estratificarse según el valor del negocio, la frecuencia de ejecución, el radio de impacto y las capacidades de pruebas de regresión; de lo contrario, es difícil establecer una conclusión de lanzamiento estable.
¿Se pueden cargar directamente los datos listados en este artículo a través del sitio temático?
No. Los sitios temáticos solo proporcionan contenido público. El inicio de sesión, registro, solicitudes y datos del proyecto deben redirigirse a la plataforma central de Yudun para su procesamiento.
¿Quieres probar esto en tu propia aplicación?
Envíe la versión candidata, los sistemas de destino y las rutas comerciales críticas para una prueba de concepto de Yudun y una evaluación de compatibilidad.
Continuar con: Lista de verificación de preparación de Yudun VMP