Skip to content

feat(integration): ingest security-alert signals for vulnerability-response practices #1675

Description

@FelixTJDietrich

New practice vertical: security-response discipline — how fast and how consistently a team triages what its security tooling surfaces. Signals: Dependabot alerts (time-to-patch, dismissal hygiene), secret-scanning alerts (leaked-credential response time, revocation follow-through), code-scanning alerts (static-analysis triage discipline).

The GitHub Apps are already provisioned (2026-09-01, both environments): permissions vulnerability_alerts: read, secret_scanning_alerts: read, security_events: read and events dependabot_alert, secret_scanning_alert, code_scanning_alert — shipping this requires no permission increase and no org re-approval round. Event timestamps (not poll snapshots) are what make response-latency practices measurable.

Scope sketch: ingest the three alert event families + backfill via REST; practice-detection contracts for response-time/dismissal practices; privacy note — alert contents are sensitive; store the minimum (identifiers, states, timestamps), never secret values or vulnerability details beyond severity/state. Sibling of #1403 (CI signals); same ingestion architecture.

Done when the three alert families flow into practice detection with a response-latency practice shipping on at least one of them, and the data-minimization posture is documented in the record of processing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    application-serverSpring Boot server: APIs, business logic, databasefeatureNew feature or enhancementpriority:mediumPlan for soon - Moderate impactsize:LThis PR changes 100-499 lines, ignoring generated files.webhook-ingestTypeScript webhook receiver: GitHub/GitLab event intake

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions