DevSecOps дайджест — 12 травня 2026

posts · 2026-05-12

Ключові сигнали дня

  • TanStack npm compromise показує межі provenance без захищеного build pipeline. За розбором Snyk, 11 травня через легітимний release pipeline TanStack було опубліковано 84 шкідливі npm-артефакти у 42 пакетах @tanstack. Найважливіший сигнал для DevSecOps: malware мав валідну SLSA provenance, бо attacker захопив сам CI runner. Attestation підтверджує “де і як зібрано”, але не гарантує, що workflow не був hijacked.
  • Checkmarx Jenkins AST plugin — ще один доказ, що remediation після supply-chain інциденту має бути повною. The Hacker News пише, що модифіковану версію Checkmarx Jenkins AST plugin опублікували в Jenkins Marketplace, а Checkmarx радить перевірити версії plugin. Ризик не тільки в одному plugin: якщо secret rotation, repo access review і build-system forensics неповні, attacker повертається через залишені токени або foothold.
  • CISA KEV додала PAN-OS vulnerability — firewall/control-plane exposure треба патчити як production incident. CISA додала CVE-2026-0300 у Palo Alto Networks PAN-OS до Known Exploited Vulnerabilities через active exploitation. Для platform/security команд це пріоритетний item: перевірити exposed management/authentication surfaces, maintenance windows, compensating controls і SLA на remediation.
  • DigiCert certificate incident нагадує: code-signing trust теж має операційний blast radius. SANS NewsBites узагальнює інцидент, де DigiCert відкликала 60 code-signing certificates після compromise support portal. Практичний урок: підписаний binary не дорівнює trusted binary; потрібні certificate revocation monitoring, allowlist політики, provenance/context checks і жорстке поводження з executable attachments у support flows.

3 матеріали для прокачки

  1. GitHub Actions 2026 security roadmap — корисно для розуміння, куди рухаються secure defaults: dependency locking, policy-driven execution, scoped credentials і observability для CI/CD.
  2. GitHub Security Lab: preventing pwn requests — must-read для тих, хто використовує pull_request_target: пояснює trust boundary, через який ламаються open-source і internal pipelines.
  3. SLSA specification v1.1 — хороша рамка для supply-chain maturity, але сьогоднішній TanStack кейс варто читати поруч: provenance працює тільки тоді, коли сам build environment захищений.

Практичний висновок

Сьогодні найсильніший крок — інвентаризувати privileged CI/CD paths і прибрати implicit trust: заборонити або централізовано контролювати pull_request_target, pin actions/dependencies immutable references, обмежити token permissions, перевірити OIDC trust policies, додати egress controls для runners і мати runbook для швидкої ротації secrets після compromise.