Ciclo de vida de desarrollo seguro - Patrones
Obtenga más información acerca de Well-Architected Confide → Ciclo de vida seguro del desarrollo
La seguridad debe integrarse durante todo el ciclo de vida del desarrollo, desde el diseño inicial hasta el despliegue y las operaciones. Estos patrones activan prácticas de seguridad de turno a la izquierda, solucionan vulnerabilidades comunes y protegen sus oportunidades en curso de implementación.
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Desarrollo | Herramientas | ✅ Escaneo de seguridad IDE integrado en el flujo de trabajo del desarrollador |
| Desarrollo | Diseño | ✅ Modelado de amenazas completado durante la fase de diseño utilizando la metodología STRIDE |
| Desarrollo | Requisitos | ✅ Requisitos de seguridad incluidos en historias de usuario y criterios de aceptación |
| Desarrollo | Control de origen | ✅ Los ganchos de confirmación previa aplican políticas de seguridad (escaneo secreto, análisis de código) |
| Desarrollo | Formación | ✅ Formación de seguridad de desarrollador actualizada regularmente para reflejar amenazas en evolución |
| Desarrollo | CI/CD | ✅ Las pruebas de seguridad automatizadas en oportunidades en curso de CI/CD fallan se basan en hallazgos críticos |
| Desarrollo | Revisión de código | ✅ Revisiones de compañeros de seguridad requeridas para autenticación, autorización y código de acceso a datos |
| Desarrollo | Análisis de código | ✅ Estándares de codificación seguros aplicados a través de linters y análisis estáticos |
| Desarrollo | Dependencias | ✅ La exploración de vulnerabilidades de dependencias se ejecuta en cada confirmación |
| Desarrollo | Pruebas | ✅ El ámbito de pruebas de penetración incluye nuevas funciones antes de la versión de GA |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Desarrollo | Pruebas | ⚠️ Pruebas de seguridad aplazadas a revisión manual antes de la versión |
| Desarrollo | Formación | ⚠️ Formación en seguridad realizada una vez durante la incorporación únicamente |
| Desarrollo | Revisión de código | ⚠️ El equipo de seguridad revisa el código tras la combinación |
| Desarrollo | Diseño | ⚠️ Modelos de amenazas no actualizados cuando cambia la arquitectura |
| Desarrollo | Control de origen | ⚠️ Exploración secreta desactivada para reducir falsos positivos |
| Desarrollo | CI/CD | ⚠️ Se ignoran los hallazgos de seguridad cuando se avecinan plazos de lanzamiento |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Inyección | ✅ Las consultas SOQL utilizan variables de vinculación para evitar la inyección |
| Inyección | ✅ Entrada de usuario validada y desinfectada antes de su uso en SOQL, SOSL o consultas dinámicas |
| Inyección | ✅ SOQL dinámico restringido solo a entradas de confianza |
| Control de acceso | ✅ Permisos CRUD y FLS aplicados utilizando Security.stripInaccessible() |
| XSS | ✅ Los componentes Lightning escapan al contenido generado por el usuario en la presentación de la interfaz de usuario |
| Inyección | ✅ Las integraciones de API externas validan y desinfectan todas las entradas |
| Control de acceso | ✅ Acceso de usuario invitado minimizado y altamente restringido |
| Autenticación | ✅ Credenciales nombradas utilizadas para autenticación externa (no credenciales codificadas) |
| Autenticación | ✅ Flujos de OAuth 2.0 implementados correctamente con PKCE |
| Gestión de sesiones | ✅ Las políticas de seguridad de sesión aplican restricciones de tiempo de espera e IP |
| Configuración | ✅ Comprobación del estado de seguridad revisada trimestralmente y hallazgos de alto riesgo solucionados |
| Control de acceso | ✅ Metadatos personalizados y permisos auditados para evitar privilegios excesivos |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Inyección | ⚠️ Consultas SOQL construidas utilizando concatenación de cadenas con entrada de usuario |
| Control de acceso | ⚠️ Perfiles de usuario invitado con permisos Crear, Actualizar o Eliminar |
| XSS | ⚠️ Los componentes Lightning utilizan expresiones sin escapar en plantillas |
| Autenticación | ⚠️ Las integraciones externas utilizan credenciales codificadas en código |
| Registro | ⚠️ Los registros de depuración contienen datos confidenciales como contraseñas o PII |
| Control de acceso | ⚠️ Se omiten las comprobaciones de FLS y CRUD porque “controlamos todos los usuarios” |
| Configuración | ⚠️ Resultados de Comprobación de estado de seguridad ignorados o pospuestos indefinidamente |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Canalizaciones | Control de origen | ✅ Las reglas de protección de sucursales aplican revisiones y comprobaciones de estado requeridas |
| Canalizaciones | Control de acceso | ✅ Las oportunidades en curso de implementación utilizan cuentas de servicio con permisos mínimos requeridos |
| Oportunidades en curso | Secretos | ✅ Secretos almacenados en bóvedas seguras (nunca en control de origen o variables de entorno) |
| Oportunidades en curso | Implementación | ✅ Las implementaciones de producción requieren una puerta de aprobación manual del personal autorizado |
| Oportunidades en curso | Auditoría | ✅ Los registros de implementación capturan quién implementó qué cuando con seguimientos de aprobación |
| Canalizaciones | Validación | ✅ La validación previa a la implementación incluye análisis de seguridad y comprobaciones de cumplimiento |
| Canalizaciones | Control de acceso | ✅ Autenticación de múltiples factores requerida para el acceso administrativo de oportunidades en curso |
| Canalizaciones | Supervisión | ✅ Los cambios de configuración de Canalizaciones desencadenan notificaciones del equipo de seguridad |
| Canalizaciones | Validación | ✅ La validación posterior a la implementación automatizada confirma los controles de seguridad esperados activos |
| Oportunidades en curso | Dependencias | ✅ Actualizaciones de dependencias evaluadas para impacto de seguridad antes de la implementación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Oportunidades en curso | Secretos | ⚠️ Secretos confirmados para el control de versiones (incluso si se eliminan más adelante) |
| Canalizaciones | Control de origen | ⚠️ Cualquiera puede combinar con la rama principal/de producción sin revisión |
| Canalizaciones | Control de acceso | ⚠️ Las canalizaciones de implementación se ejecutan con permisos a nivel de administrador |
| Oportunidades en curso | Implementación | ⚠️ Implementaciones de producción completamente automatizadas sin puertas de aprobación |
| Oportunidades en curso | Auditoría | ⚠️ Los registros de implementación no capturan quién inició o aprobó los cambios |
| Canalizaciones | Validación | ⚠️ Análisis de seguridad fallidos ignorados o omitidos para cumplir los plazos |
| Canalizaciones | Supervisión | ⚠️ Cambios de configuración de oportunidades en curso no supervisados o revisados |
| Canalizaciones | Validación | ⚠️ La validación posterior a la implementación solo comprueba la corrección funcional |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Pruebas | Análisis estático | ✅ Salesforce Code Analyzer se ejecuta en IDE de desarrollador para comentarios inmediatos y en oportunidades en curso de CI/CD como puertas automatizadas |
| Pruebas | Pruebas de penetración | ✅ Pruebas de penetración realizadas para aplicaciones personalizadas expuestas a usuarios no fiables, especialmente sitios de Experience Cloud y API de cara al público |
| Pruebas | Pruebas de unidad | ✅ Las pruebas de unidad de Apex centradas en la seguridad se ejecutan como usuarios con diferentes perfiles de permisos |
| Pruebas | Dependencias | ✅ El análisis de dependencias supervisa paquetes de AgentExchange y bibliotecas JavaScript para vulnerabilidades conocidas |
| Pruebas | Revisión de seguridad | ✅ Informe de análisis estático preparado para cada envío de AppExchange o AgentExchange Security Review |
| Pruebas | Revisión de seguridad | ✅ Informe de exploración dinámica (prueba de penetración) preparado cuando una solución integra una aplicación o servicio web externo |
| Pruebas | Dependencias | ✅ Avisos de seguridad para paquetes instalados suscritos y supervisados |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Pruebas | Cobertura | ⚠️ Las pruebas de seguridad se basan en una única técnica como el análisis estático por separado |
| Pruebas | Pruebas de unidad | ⚠️ Las pruebas Apex validan el comportamiento funcional pero nunca se ejecutan como usuarios de privilegios inferiores |
| Pruebas | Revisión de seguridad | ⚠️ Envío de AppExchange o AgentExchange preparado sin el análisis estático requerido o los informes de análisis dinámicos |
| Pruebas | Pruebas de penetración | ⚠️ Pruebas de penetración omitidas para sitios y API de Experience Cloud de cara al público |
Consulte también:
- Patrones normativos y de cumplimiento: regulación de plataforma y controles de auditoría
- Patrones de gestión de identidad y acceso: autenticación y autorización
- Patrones de respuesta a incidentes: Detección y respuesta de eventos de seguridad
- Patrones de agentes: controles de seguridad específicos de agentes