SECURITY.md

Por: Artiko
githubsecurity-policyvulnerabilidadesdevops

SECURITY.md

SECURITY.md es tu política de seguridad: le dice a quien encuentra una vulnerabilidad cómo reportarla de forma responsable, sin exponerla públicamente en una issue donde cualquiera la vería antes del parche. GitHub la muestra en la pestaña Security del repo.

Ubicación

Como el resto de community health files: .github/SECURITY.md (recomendado), la raíz del repo, o docs/.

Contenido recomendado

Una buena política incluye:

Ejemplo de estructura

# Security Policy

## Supported Versions

| Versión | Soportada          |
| ------- | ------------------ |
| 5.x     | :white_check_mark: |
| 4.x     | :white_check_mark: |
| < 4.0   | :x:                |

## Reportar una vulnerabilidad

Usá el botón **Report a vulnerability** en la pestaña Security de este
repo, o escribí a [email protected].

Respondemos en un plazo de 72 horas y publicamos un parche
coordinando la divulgación con quien reportó.

Private Vulnerability Reporting

GitHub ofrece Private Vulnerability Reporting, una función opt-in por repo (Settings → Security → Private vulnerability reporting). Al activarla, aparece un botón Report a vulnerability en la pestaña Security que permite a quien reporta abrir un Security Advisory privado en lugar de una issue pública.

flowchart LR
    R["Investigador<br/>encuentra un fallo"] --> B["Botón 'Report a vulnerability'<br/>pestaña Security"]
    B --> A["Security Advisory privado<br/>(no visible al público)"]
    A --> F["Mantainer discute y parchea<br/>en privado"]
    F --> CVE["Divulgación coordinada<br/>+ posible CVE"]

Es el mecanismo moderno recomendado, complementario al texto de SECURITY.md: el archivo explica la política; el Private Vulnerability Reporting provee el canal privado real.

Security Advisories y CVE

Los Security Advisories de GitHub pueden derivar en la asignación de un CVE: desde el advisory podés solicitar el identificador, publicar los detalles una vez parcheado y notificar a quienes dependen de tu proyecto. Así la vulnerabilidad se divulga de forma coordinada, no filtrada.


AnteriorCapítulo 8: CODEOWNERS · SiguienteCapítulo 10: Issue templates