Zestawy rozmówBlog

Twoja wymarzona praca? Lets Git IT.
Interaktywna platforma przygotowująca do rozmów technicznych dla nowoczesnych programistów.

XGitHub

Platforma

  • Kategorie

Zasoby

  • Blog
  • O aplikacji
  • FAQ
  • Sugestie

Prawne

  • Polityka prywatności
  • Regulamin

© 2026 LetsGit.IT. Wszelkie prawa zastrzeżone.

LetsGit.IT/Kategorie/Bezpieczeństwo
Bezpieczeństwohard

Czym jest ryzyko supply chain w oprogramowaniu i jak je ograniczać?

Tagi
#supply-chain#dependencies#slsa
Wróć do kategoriiPrzejdź do quizu

Odpowiedź

Ryzyko supply chain to możliwość podmiany zależności, etapów builda lub artefaktów. Mitigacje obejmują pinowanie wersji, SBOM, weryfikację podpisów, least-privilege w CI oraz monitoring podatnych zależności.

Odpowiedź zaawansowana

Głębiej

Ataki supply chain celują w zależności i pipeline builda:

  • Ryzyka: typosquatting, przejęte paczki, zatrute kroki builda.
  • Kontrole: lockfile, provenance (SLSA), podpisy artefaktów (Sigstore).
  • Hardening CI: least-privilege tokeny, izolowane runnery.
  • Ciągłe skanowanie: SCA, SBOM, polityki zależności.

Przykłady

Spójność zależności dzięki lockfile + walidacji w CI:

- npm ci (używa lockfile)
- weryfikacja podpisów paczek
- build fail przy krytycznych CVE

Typowe pułapki

  • Auto-update bez review.
  • Współdzielone sekrety CI między repo.
  • Brak SBOM lub audytów zależności.

Pytania uzupełniające na rozmowie

  • Jak reagujesz na przejętą zależność?
  • Co oznacza SLSA level 2/3 w praktyce?
  • Jak zapewniasz powtarzalność builda?

Powiązane pytania

Monolity
Jak zapobiegać cyklicznym zależnościom między modułami w modularnym monolicie?
#monoliths#modular-monolith#boundaries