Empiece por las amenazas de este producto
Una lista de vulnerabilidades conocidas ayuda, pero no muestra cuáles son las más importantes para una aplicación concreta. Primero trace activos, usuarios, flujos de datos y límites de confianza. ¿Quién entra, quién modifica datos financieros, de dónde llegan archivos y cómo actúa un servicio externo? En cada paso considere abuso, error accidental y divulgación. El resultado es un modelo de amenazas breve que establece prioridades para pruebas y protecciones.
El marco SSDF de NIST recomienda incorporar prácticas seguras al desarrollo normal. Un equipo pequeño no necesita crear un proceso pesado. Sí necesita responsable del riesgo, reglas de revisión y camino desde el hallazgo hasta la reparación. Actualice el modelo de amenazas cuando aparezcan permisos, integraciones o clases de datos nuevas. Una lista sin cambios puede dar confianza falsa mientras las fronteras reales del producto se han movido.
La identidad y los permisos tienen sentido comercial
Autenticar comprueba quién es una persona; autorizar determina qué puede hacer. Muchos errores reales aparecen en la segunda parte. Una persona puede entrar legítimamente en un portal y, aun así, no debe ver el pedido de otra empresa ni concederse un rol. Escriba una matriz de funciones según operaciones y datos reales. Cada petición al servidor debe verificar la regla, incluso si la interfaz esconde el botón. La visibilidad de un control no es una barrera de seguridad.
Las cuentas administrativas necesitan acceso robusto, límite de intentos y forma de revocar sesiones. Las cuentas de servicio requieren permisos estrechos y rotación de credenciales. Cuando un empleado cambia de rol, su acceso debe terminar también en cachés, exportaciones y otros sistemas. Pregunte cómo se resuelven dispositivos perdidos, salidas de personal y accesos de emergencia. Las respuestas influyen más en la implementación que la elección de una biblioteca de inicio de sesión.
Convierta requisitos en controles comprobables
La frase «la aplicación debe ser segura» no se puede verificar. «Un usuario normal no puede leer registros de otra organización» sí se puede probar. OWASP ASVS ofrece un catálogo estructurado de controles web que puede seleccionarse según riesgo. Elija áreas pertinentes como sesiones, validación de entradas, acceso a datos y configuración. Una cada control con una prueba concreta, responsable y resultado. Eso es más útil que afirmar cumplimiento total de una norma sin pruebas.
Un escáner automático encuentra ciertos fallos conocidos, pero puede ignorar la lógica comercial. Añada revisión manual de cambios de riesgo y pruebas entre roles. En una API compruebe duplicados, firmas y errores. En archivos, tipo, tamaño y tratamiento seguro. Registre lo probado y lo pendiente. Un control con límites explícitos ayuda más que una etiqueta verde que esconde escenarios sin examinar.
Las pruebas de seguridad forman parte de la entrega
Durante el desarrollo automatice controles de tipos, dependencias y patrones de código arriesgados cuando aporten valor. También generan falsos avisos y nunca cubren toda la aplicación. Clasifique hallazgos por impacto y posibilidad real de llegar al fallo. Una autorización rota es más urgente que la puntuación de una biblioteca que ni siquiera se ejecuta en producción. Cada hallazgo necesita cierre claro: reparación, mitigación probada o aceptación por la persona responsable.
Antes de publicar algo importante, pruebe los escenarios del modelo de amenazas: saltar roles, enviar archivos imprevistos o explotar estados de error. Si hace falta una prueba de penetración independiente, defina alcance, permiso y proveedor; no presente una revisión interna como auditoría externa. Tras corregir, repita el abuso original y compruebe que el uso legítimo sigue funcionando. Una protección que rompe la tarea principal necesita un diseño mejor.
Código y dependencias tienen procedencia
El producto utiliza bibliotecas, herramientas de construcción, imágenes y procesos automáticos. Su origen y versiones afectan al software entregado. Fije dependencias, limite permisos de CI y separe secretos de trabajos corrientes. Registre qué commit y configuración generaron cada artefacto. SLSA describe niveles progresivos de garantía en la cadena de suministro. Un equipo pequeño quizá no necesite el nivel mayor, pero debe saber qué puede demostrar sobre el origen de su construcción.
Al actualizar, mire más que el número de vulnerabilidades. ¿Se usa la dependencia en producción, existe arreglo y cómo se instala de forma segura? Un paquete antiguo sin mantenimiento puede ser más preocupante que una actualización incómoda. Anote excepciones con fecha de revisión. El propio entorno de construcción necesita control de acceso, porque una publicación comprometida puede evitar las defensas del código de aplicación.
Los registros pueden ayudar y perjudicar
Los eventos registrados permiten investigar cambios no autorizados y fallos. Elija sucesos que respondan quién hizo qué, cuándo y con qué resultado. Cambios de rol, acciones administrativas e intentos de acceso fallidos son ejemplos. El formato debe ser estructurado y resistir entradas que intenten insertar líneas falsas. Cada origen necesita retención proporcionada y acceso limitado. Una enorme cantidad de datos que nadie revisa no mejora la seguridad.
OWASP desaconseja guardar habitualmente contraseñas, tokens de sesión, claves, datos personales sensibles e instrucciones de pago completas. Un identificador de correlación y el tipo de error suelen bastar para investigar sin crear una nueva exposición. Revise además analítica, informes de error y copias de registros. Eliminar un dato del log principal no ayuda si otra herramienta lo copia automáticamente a un servicio externo.
Prepare la respuesta a hallazgos e incidentes
Ninguna prueba garantiza que no aparezca un problema después de publicar. Establezca un canal para comunicar vulnerabilidades, responsable de respuesta, valoración del impacto y plan de reparación. Durante un incidente separe contención, conservación de pruebas necesarias, recuperación del servicio y comunicación. El procedimiento debe ajustarse a los datos y compromisos contractuales. Las obligaciones legales de notificación dependen del hecho concreto y la jurisdicción y exigen revisión específica.
Después de reparar, pregunte por qué el problema superó el proceso: ¿faltaba una prueba, un rol estaba mal definido o cambió una integración sin actualizar las amenazas? Añada controles que generen valor repetible. Para una aplicación pequeña quizá baste una prueba de integración y mejor alerta. Un servicio crítico puede requerir un cambio de arquitectura. El objetivo es aprender y reducir riesgo, no producir documentos después del incidente.
Delimite el trabajo de seguridad
La primera solicitud debería incluir tipo de producto, clases de datos, roles, integraciones, entornos y fecha prevista de publicación. Añada pruebas anteriores, acceso al repositorio y límites operativos. Entonces se puede decidir entre modelo de amenazas, revisión de arquitectura, controles en el desarrollo o evaluación independiente. Son trabajos con resultados distintos y no deben confundirse.
Esta página explica un enfoque para crear software más seguro. No atribuye a EXCOIN certificaciones no demostradas, autoridad auditora ni riesgo cero. Si se requiere auditoría formal o valoración jurídica, identifique un profesional cualificado y el alcance. El equipo técnico puede preparar evidencias y corregir defectos confirmados. Avanzar significa nombrar riesgos, asignar responsables y probar de verdad los escenarios de abuso principales.