paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
18 security · Governance

Oficial de Seguridad

Triaje de vulns y cumplimiento.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El InfoSec Officer es la persona que mantiene defensibles el software y los sistemas de IA en el cambio continuo. En un SDLC AI-nativo, el InfoSec Officer opera un agente Threat Triager, cuatro slash prompts, y un catálogo validado de MCPs anclado en GitHub Advanced Security y Microsoft Defender for Cloud — no una lista de verificación PDF.

Resumen ejecutivo

El InfoSec Officer posee la postura de seguridad del pipeline de entrega y los productos que lanza. En un SDLC AI-nativo, opera un agente Threat Triager con cuatro slash prompts (/vuln-triage, /sbom-scan, /threat-model, /incident-security), instrucciones con alcance para rutas sensibles a seguridad, y un catálogo validado de MCPs que alcanza GitHub Advanced Security, Dependabot, CodeQL, Secret Scanning, Push Protection, Microsoft Defender for Cloud, Microsoft Sentinel, Microsoft Purview, Entra ID, y Azure Key Vault.

Los entregables principales son colas de vulnerabilidades triadas con SLAs, facturas de materiales de software firmadas, modelos de amenaza adjuntos a cada decisión de arquitectura, e incidentes respondidos coordinados a través de Sentinel. El InfoSec Officer convierte la seguridad de un bloqueador de lanzamiento en una capa continua, mayormente automática y productora de evidencia.

La seguridad es una propiedad del pipeline, no un evento de auditoría. El InfoSec Officer integra políticas, detecciones y remediaciones en herramientas cotidianas para que en el momento en que una PR llega a merge, la mayoría de preguntas ya tengan respuesta.

Rol y responsabilidades

Piensa en el InfoSec Officer como el inspector de seguridad de una ciudad. No apaga cada fuego, pero redacta el código de construcción, certifica inspecciones, realiza simulacros, y coordina la respuesta cuando ocurre un incendio real. En un SDLC AI-nativo, el InfoSec Officer refuerza el código y orquesta la respuesta a través de superficies GitHub, Azure, y Microsoft 365.

Responsabilidades principales:

  • Triage de alertas de vulnerabilidad desde GitHub Advanced Security, Dependabot, y Defender for Cloud
  • Mantener el SBOM (software bill of materials) por servicio con procedencia firmada
  • Redactar modelos de amenaza para cada nueva arquitectura; actualizar cuando la arquitectura cambia
  • Coordinar la respuesta a incidentes de seguridad a través de Microsoft Sentinel y issues de GitHub
  • Reforzar Push Protection, Secret Scanning, CodeQL, y políticas de Dependabot en cada repositorio
  • Integrar seguridad de IA (filtros de contenido, redacción de PII) con los pipelines del ML AI Engineer
  • Operar el agente Threat Triager y los prompts /vuln-triage, /sbom-scan, /threat-model, /incident-security
  • Gestionar higiene de identidad y secretos a través de Microsoft Entra ID y Azure Key Vault

Jobs to be done

  1. Como InfoSec Officer, quiero que cada alerta de Dependabot o CodeQL sea triada dentro del SLA, para que las ventanas de exposición se minimicen.
  2. Como InfoSec Officer, quiero un SBOM firmado publicado con cada lanzamiento, para que las preguntas sobre supply chain tengan respuestas inmediatas.
  3. Como InfoSec Officer, quiero modelos de amenaza adjuntos a PRs de arquitectura, para que las mitigaciones estén en lugar antes de que el código llegue.
  4. Como InfoSec Officer, quiero Push Protection y Secret Scanning habilitados por defecto, para que las credenciales nunca alcancen una rama remota.
  5. Como InfoSec Officer, quiero que los hallazgos de Defender for Cloud se conviertan automáticamente en issues de GitHub, para que el trabajo de remediación sea visible en el mismo backlog que las features.
  6. Como InfoSec Officer, quiero alertas de Sentinel enriquecidas con contexto de repo, para que el triaje sea rápido y preciso.
  7. Como InfoSec Officer, quiero que las cronologías de incidentes se produzcan automáticamente desde chat, commits, y alertas, para que las revisiones posteriores al incidente se basen en hechos.
  8. Como InfoSec Officer, quiero todos los secretos almacenados en Azure Key Vault con identidad administrada, para que no haya credenciales de larga vida en CI.

Puntos de dolor antes de la era AI-nativa

  • Fatiga de alertas. Miles de alertas de Dependabot y CodeQL sin triaje, por lo que los problemas reales se pierden en el ruido.
  • SBOMs como PDFs. Facturas de materiales producidas una vez, nunca firmadas, nunca consumidas en CI.
  • Modelos de amenaza en una bóveda. Modelos de amenaza redactados en el lanzamiento del proyecto, nunca revisados; describen un sistema que ya no existe.
  • Caos en incidentes. Incidentes gestionados en cinco herramientas; la cronología se recupera luego entrevistando personas.
  • Credenciales en CI. Claves API en secretos de GitHub Actions, rotadas en vacaciones, almacenadas en YAML plano por accidente.
  • Políticas como diapositivas. Las políticas de seguridad existen en SharePoint, no como configuración reforzada.
  • Seguridad de IA aislada. Los controles de seguridad de IA propiedad de un equipo diferente, no integrados en la misma revisión.

Flujo diario AI-nativo

El InfoSec Officer trabaja desde Visual Studio Code y la terminal con Claude Code, orquestando el Threat Triager e imponiendo hooks en cada repositorio.

Setup de la mañana

  1. Abrir dashboards de Microsoft Defender for Cloud, Microsoft Sentinel, y GitHub Advanced Security.
  2. Ejecutar /vuln-triage --since=yesterday para agrupar nuevas alertas por servicio y severidad.
  3. Revisar bypasses de Push Protection y notificaciones de Secret Scanning durante la noche.
  4. Verificar los logs de acceso a Azure Key Vault para anomalías; confirmar que Conditional Access de Entra ID esté saludable.
  5. Publicar el resumen de standup de seguridad en Microsoft Teams con incidentes abiertos y relojes de SLA.

Ejecución al mediodía

  1. Para cada PR de arquitectura, invocar /threat-model; el Threat Triager redacta hallazgos y mitigaciones STRIDE, luego abre issues de seguimiento.
  2. Para cada grupo de vulnerabilidades, triage con /vuln-triage: asignar propietario, severidad, ventana de corrección, controles compensatorios.
  3. Ejecutar /sbom-scan como parte de CI; bloquear lanzamiento en componentes sin firmar o que violen política.
  4. Coordinar el canal de incidente activo en Microsoft Teams; /incident-security mantiene actualizada la cronología.

Revisión al final de la tarde

  1. Verificar recomendaciones de Defender for Cloud y archivar excepciones de Azure Policy donde sea justificado.
  2. Revisar adiciones de consultas CodeQL y fusionar consultas personalizadas aprobadas en el pack compartido.
  3. Actualizar el registro de riesgo trimestral en el repo; publicar la puntuación de postura actualizada a Microsoft Loop.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
threat-triager.github/agents/threat-triager.agent.mdTriages vulnerabilities, runs SBOM scans, drafts threat models, coordinates incidents

Slash prompts

ComandoArchivoPropósito
/vuln-triage.github/prompts/vuln-triage.prompt.mdCluster alerts, assign owners, set SLA, propose remediations
/sbom-scan.github/prompts/sbom-scan.prompt.mdGenerate, sign, and verify the SBOM for a release
/threat-model.github/prompts/threat-model.prompt.mdDraft STRIDE analysis and mitigation tasks on an architecture PR
/incident-security.github/prompts/incident-security.prompt.mdMaintain live incident timeline from Sentinel, Teams, and GitHub

Instrucciones con alcance

Alcance (applyTo)ArchivoPropósito
.github/workflows/**/*.yml.github/instructions/actions-security.instructions.mdOIDC to Azure, no long-lived secrets, pinned SHA actions
infra/**/*.bicep.github/instructions/infra-security.instructions.mdKey Vault references, managed identity, network isolation
src/**/auth/**.github/instructions/auth.instructions.mdEntra ID patterns, token handling, least privilege
prompts/**/*.prompt.md.github/instructions/ai-safety.instructions.mdContent-safety guardrails and PII redaction

Hooks

  • pre-commit: Secret Scanning, push protection, dependency policy check
  • pre-push: CodeQL fast queries on changed files
  • post-merge: Dependabot triage, SBOM refresh, Defender for Cloud sync
  • pre-release: SBOM signature and threat-model presence gate
  • on-incident: create a Sentinel incident record and pin the Microsoft Teams channel

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerRead Advanced Security alerts, Dependabot, CodeQL, manage issues and PRsGitHub
Azure MCP ServerDrive Defender for Cloud, Sentinel, Key Vault, Entra ID, Azure Policy operationsMicrosoft
Microsoft Learn Docs MCPResolve current security guidance across Microsoft stacksMicrosoft
Azure DevOps MCP ServerTrack remediation work items when the team uses Azure DevOpsMicrosoft
Playwright MCPValidate security UX flows (SSO, MFA, consent) end-to-endMicrosoft

Ejemplos reales

Ejemplo 1: triaje de día cero en una hora

Llega un CVE en una dependencia ampliamente utilizada. /vuln-triage identifica 23 repos expuestos y mapea cada uno a su propietario de servicio. El Threat Triager abre issues con PRs de corrección ya redactados por Copilot. Dentro de una hora, 19 PRs están fusionadas; los 4 restantes reciben controles compensatorios documentados. Defender for Cloud confirma que la exposición se cerró.

Ejemplo 2: modelo de amenaza impulsa un cambio de diseño

Una PR de arquitectura propone un nuevo endpoint que acepta URLs firmadas. /threat-model marca un riesgo de replay y sugiere un nonce más expiración corta. El Software Architect actualiza el diseño antes de que la PR se fusione; las tareas de mitigación se vinculan y cierran automáticamente cuando la implementación llega.

Ejemplo 3: SBOM firmado bloquea un lanzamiento

El flujo de lanzamiento invoca /sbom-scan. El pipeline detecta una dependencia transitiva sin firmar y bloquea el lanzamiento. El InfoSec Officer confirma que el componente no está bajo explotación activa, archiva una excepción temporal en Azure Policy, y el lanzamiento procede con pista de auditoría completa.

Anti-patrones

  • Triaje en spreadsheet. El triaje fuera de GitHub pierde contexto y seguimiento de SLA; mantenerse en issues.
  • Secretos de larga vida. Cualquier secreto mayor a 90 días es una responsabilidad; usar identidad administrada y referencias de Key Vault.
  • Modelos de amenaza una sola vez. Los modelos deben evolucionar con el sistema; vincularlos a PRs de arquitectura.
  • Ignorar bypasses de Push Protection. Cada bypass es revisado el mismo día, no al cierre de trimestre.
  • Silos de seguridad. La seguridad de IA pertenece en el mismo pipeline que la seguridad de app, con los mismos revisores.
  • Política como PDF. Las políticas que no son Azure Policy o configuraciones de GitHub Advanced Security no existen.
  • Incidentes sin cronología. Cada incidente produce una cronología reproducible generada desde herramientas, no memoria.

KPIs y métricas de impacto

MétricaBaseline (manual)Objetivo (agéntico)Fuente
Tiempo medio para triage de CVE4 días< 4 horas/vuln-triage history
Cobertura SBOM40 por ciento100 por ciento de lanzamientosGitHub Actions
Cobertura de modelo de amenaza en PRs de arq20 por ciento100 por ciento/threat-model runs
Secretos detectados al momento de push12 por mes0Push Protection logs
Hallazgos altos de Defender for Cloud > 7 días30< 5Defender for Cloud
Incidentes de Sentinel con cronología automática10 por ciento100 por cientoSentinel workbooks
Rotación de credencial de Key Vault a tiempo60 por ciento100 por cientoEntra ID audit

Madurez en cuatro niveles

  • L1 Manual: Avisos rastreados en spreadsheet, no SBOM, modelos de amenaza solo en lanzamiento.
  • L2 Asistido: Dependabot y Secret Scanning habilitados pero sin triage; dashboards de Defender for Cloud observados ad hoc.
  • L3 Aumentado: Agente Threat Triager, cuatro slash prompts, instrucciones con alcance, pack personalizado de CodeQL, integración de Sentinel.
  • L4 Autónomo: Triaje automatizado con refuerzo de SLA, SBOMs firmados bloqueando lanzamiento, modelos de amenaza adjuntos a cada PR de arquitectura, incidentes con cronologías auto-generadas.

Integración con otras personas

  • Del Software Architect: diagramas de diseño y ADRs alimentando /threat-model.
  • Para el Developer: issues de remediación con drafts de corrección vinculados.
  • Con ML AI Engineer: configuración de seguridad de IA, filtros de content-safety, redacción de PII.
  • Con SRE: runbooks de Sentinel compartidos y respuesta a incidentes.
  • Con Compliance Auditor: SBOMs, modelos de amenaza, y paquetes de evidencia de grado de auditoría.
  • Del Data Engineer: clasificaciones de Purview impulsando controles de manejo de datos.
  • Con DBA: revisiones de acceso a base de datos y verificaciones de least privilege.

Glosario

  • SBOM: software bill of materials — lista firmada de cada componente en un lanzamiento.
  • STRIDE: taxonomía de modelado de amenaza (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
  • Push Protection: Feature de GitHub Advanced Security que bloquea secretos de llegar a ramas remotas.
  • Managed identity: Identidad de Microsoft Entra ID usada por cargas de trabajo, eliminando credenciales almacenadas.
  • Dependabot: Servicio de GitHub que abre PRs para dependencias vulnerables.
  • Sentinel incident: un objeto de caso de Microsoft Sentinel recopilando alertas, entidades, y cronología.
  • Compensating control: una mitigación alternativa cuando la corrección preferida aún no es viable.

Referencias