Microsoft rozszerza program bug bounty na kod firm trzecich i open source: „In Scope by Default”

Wprowadzenie do problemu / definicja luki

Microsoft ogłosił duże rozszerzenie programu bug bounty: krytyczne podatności w kodzie Microsoftu, firm trzecich oraz open source kwalifikują się do nagród jeśli mają bezpośredni, wykazywalny wpływ na usługi online Microsoftu. Firma nazywa tę zmianę podejściem „In Scope by Default” — wszystkie usługi online są domyślnie objęte programem, a nowe trafiają do scope w momencie premiery. To przesuwa akcent z „kto jest właścicielem kodu” na realny efekt podatności dla klientów.

W skrócie

• Scope domyślny: wszystkie usługi online Microsoftu są objęte programem; nowe usługi wchodzą do scope od dnia uruchomienia.
• Kod zewnętrzny też się liczy: krytyczne luki w komponentach third-party i open source kwalifikują się, o ile uderzają w usługi Microsoftu.
• Gdy „nie ma programu” — i tak płacą: jeśli brak istniejącego bounty dla danego komponentu, Microsoft deklaruje przyznanie nagrody, by domknąć lukę zachęt dla badaczy.
• Konsekwencje rynkowe: to praktycznie zachęta do full-stack research: łańcuchy zależności, integracje SaaS, biblioteki OS i konfiguracje chmurowe. Potencjalnie krótszy czas wykrycia/naprawy luk „na styku”. (Wniosek na podstawie źródeł.)
• Kontekst finansowy: w poprzednim roku Microsoft wypłacił >17 mln USD w ramach bounty i inicjatywy Zero Day Quest; tegoroczna edycja ZDQ miała pulę do 5 mln USD.

Kontekst / historia / powiązania

Zmiana została ogłoszona 11 grudnia 2025 r. podczas Black Hat Europe przez Toma Gallaghera (VP Engineering, MSRC). Microsoft wiąże ją z szerokim programem transformacji bezpieczeństwa Secure Future Initiative (SFI), którego celem jest „security above all else”.

Media branżowe (m.in. SecurityWeek, BleepingComputer, The Register) podkreślają, że jest to istotny zwrot: firma nagradza teraz również badania nad błędami poza własnym kodem, jeśli skutki uderzają w usługi Microsoftu (np. łańcuchy zależności w chmurze).

Analiza techniczna / szczegóły luki

Co jest „in scope” teraz?

• Wszystkie usługi online Microsoftu — domyślnie. Nowe usługi są objęte w dniu premiery.
• Krytyczne podatności w:
  • kodzie Microsoftu,
  • kodzie third-party (komercyjnym),
  • open source,
    jeżeli mają „bezpośredni i wykazywalny” wpływ na usługi online Microsoftu (np. RCE w bibliotece, z której korzysta usługa).

Microsoft utrzymuje dotychczasowe programy tematyczne (Azure, Identity, M365, Hyper-V itd.) z określonymi widełkami nagród — np. Hyper-V do 250 tys. USD, Identity do 100 tys. USD — ale nowa zasada „In Scope by Default” rozszerza kwalifikowalność o krytyczne przypadki w łańcuchu dostaw oprogramowania.

Zasady i proces

• Wymóg Responsible Security Research / Rules of Engagement i zgłoszenia przez kanały MSRC.
• Priorytet dla badań o najwyższym ryzyku (obszary najczęściej atakowane).

Praktyczne konsekwencje / ryzyko

• Łańcuch dostaw (SBOM → usługa): badacze mogą celować w biblioteki i integracje, które realnie wpływają na usługi Microsoftu (np. zależność npm/PyPI wykorzystywana przez składową usługi). To powinno skrócić „martwe strefy” scope’u, gdzie wcześniej brakowało bodźców ekonomicznych. (Wniosek na podstawie źródeł.)
• Lepszy coverage „styków”: luki „na brzegach” — API między usługami, federacje tożsamości, łączniki SaaS — mają większą szansę na szybkie wykrycie i nagrodzenie. (Wniosek na podstawie źródeł.)
• Ryzyko dla organizacji korzystających z Microsoft 365/Azure: spodziewany wzrost odkrywalności błędów zależności może prowadzić do częstszych, ale szybciej łagodzonych biuletynów i zmian konfiguracji. (Wniosek na podstawie źródeł.)

Rekomendacje operacyjne / co zrobić teraz

Dla Blue Team / SecOps

• Zaktualizuj playbooki na krytyczne CVE w łańcuchu zależności usług Microsoftu; monitoruj biuletyny MSRC i SFI pod kątem szybkich remediacji.
• Telemetry „na styku”: wzmacniaj obserwowalność w integracjach (OAuth/OIDC, SCIM, webhooki, konektory), aby skrócić MTTD.

Dla Red Team / Badaczy

• Celuj w komponenty o wysokiej dźwigni: zależności OS/third-party używane przez usługi online Microsoftu; pamiętaj o zasadach ROE i kanałach zgłoszeń MSRC.
• Sprawdź widełki i istniejące programy (Azure, Identity, M365 itd.) — to ułatwia wycenę i priorytetyzację badań.

Dla PSIRT / GRC

• Mapuj zależności (SBOM) własnych rozwiązań z usługami Microsoftu (np. Entra ID, Graph, SharePoint Online), aby szybciej ocenić ekspozycję na przyszłe zgłoszenia i łatki. (Wniosek na podstawie źródeł.)
• Śledź ZDQ — konkurs Zero Day Quest przynosi przyspieszone zgłoszenia w krytycznych obszarach (AI, chmura), co zwykle poprzedza publikacje.

Różnice / porównania z innymi przypadkami

• Dotąd programy bug bounty Microsoftu miały ściśle zdefiniowany scope per produkt/usługę. Teraz — jeżeli krytyczna luka uderza w usługi online, liczy się efekt, a nie właściciel kodu. To zbliża model do myślenia agresora (wybór najsłabszego ogniwa w łańcuchu), co zauważyły redakcje branżowe.

Podsumowanie / kluczowe wnioski

• Microsoft systemowo domyka białe plamy w zachętach dla badań nad łańcuchem dostaw: „In Scope by Default” oznacza, że krytyczne luki w kodzie zewnętrznym też mogą zostać nagrodzone, jeśli uderzają w usługi online firmy.
• Ruch wpisuje się w SFI i trend wzmacniania bezpieczeństwa po stronie usług chmurowych i AI — w tym poprzez Zero Day Quest z pulą do 5 mln USD i rekordowe >17 mln USD wypłat rok do roku.

Źródła / bibliografia

1. Microsoft MSRC — Evolving our approach to coordinated security research: In scope by default (11 grudnia 2025). (Microsoft)
2. SecurityWeek — Microsoft Bug Bounty Program Expanded to Third-Party Code (12 grudnia 2025). (SecurityWeek)
3. Microsoft — Microsoft Bounty Programs (strona programów, widełki nagród). (Microsoft)
4. BleepingComputer — Microsoft bounty program now includes any flaw impacting its services (grudzień 2025). (BleepingComputer)
5. The Register — Microsoft now buys bugs, with or without a bounty program (grudzień 2025). (The Register)