Signal SentrySearchUpdated Nov 2, 05:30 UTCAM Drop
Security lens · Build and supply chain

Locked-down build pipelines

A poisoned dependency, pull request or build step finds only narrow, short-lived credentials, not the keys to every system.

Where to start

Our reading of the guidance below, for a small team. A starting point, not a complete program.

  1. Give each pipeline its own credentials with only the permissions its job needs, and do not share them across pipelines.
  2. Use credentials that expire when the job ends instead of long-lived tokens stored in pipeline settings.
  3. Require approval before a pipeline deploys to production, and review pipeline config changes like code.

The guidance

  1. OWASP · CI/CD Security Cheat Sheet

    Any identities used within the pipeline must be assigned only the minimum permissions necessary to do its job.

  2. OWASP · Secrets Management Cheat Sheet

    Rotation/Temporality: credentials used by the CI/CD tooling to authenticate against the secret management system are rotated frequently and expire after a job completes.

Short quotes from the official guidance, linked. Read the source before you act on it.

Incidents from the Drops

Security

CISA lists exploited GitLab flaw; Alpine Linux says an attack on its instance failed

CISA added CVE-2026-97229 to its list of actively exploited vulnerabilities: an unauthenticated user can run code on a GitLab server through a crafted regex in CI/CD config. SecurityWeek reports a failed attempt on Alpine Linux.

Why it matters: If you self-host GitLab on your own Ruby build, Alpine Linux says upgrading GitLab alone left it exposed: check that Ruby is 3.3.13, 3.4.12, 4.0.9 or newer.

Confirmed Way in: crafted CI configurations sent from a newly registered account on the GitLab instance

Controls that would have helped:

CISA KEV catalog · Oct 29NVD CVE-2026-97229 · Oct 29SecurityWeek · Oct 30
From Drop #057 · Sat, Oct 31, 2026 · Morning