Salesforce CLI ukryje sekrety – ryzyko dla CI/CD

27 maja 2026 standardowe outputy Salesforce CLI przestaną zwracać wrażliwe dane, co może od razu wywrócić pipeline’y oparte na parsowaniu tokenów, haseł i URL-i autoryzacyjnych.

Zmiana jest już widoczna w release candidate od 20 maja 2026 i dotyczy codziennej pracy adminów, devów oraz zespołów DevOps (Salesforce Ben). Najważniejsza konsekwencja nie dotyczy samej składni komend, tylko założenia, że sekrety nie powinny już pojawiać się w normalnym outputcie CLI ani w odpowiedziach JSON. Jeśli organizacja ma skrypty, które czytają dane z komend takich jak sf org display czy logowań użytkownika, czas na poprawki liczony jest w dniach, nie w sprintach.

Co dokładnie zmienia się w Salesforce CLI

Zmiana obejmuje komendy związane z zarządzaniem orgami, użytkownikami i autoryzacją. W praktyce standardowe komendy nie będą już pokazywać wrażliwych danych domyślnie. Dotyczy to m.in. tokenów dostępu, haseł użytkowników i URL-i autoryzacyjnych SFDX, które dotąd bywały pobierane bezpośrednio z normalnego outputu lub z odpowiedzi JSON.

Nowy model rozdziela informacje operacyjne od sekretów. Dane administracyjne nadal mają być dostępne w zwykłych komendach, ale pobranie sekretu wymaga użycia dedykowanej komendy, jasno nazwanej i oznaczonej jako operacja wrażliwa. Do tego celu mają służyć m.in. sf org auth show-access-token, sf org auth show-sfdx-auth-url oraz sf org auth show-user-password.

To nie jest kosmetyka, tylko zmiana modelu bezpieczeństwa. CLI przechowuje trwałe poświadczenia do wielu orgów, więc przejęcie jednego środowiska roboczego może otworzyć drogę do szerszego incydentu. Ryzyko rośnie szczególnie tam, gdzie logi wykonania trafiają do systemów automatyzacji, narzędzi AI albo historii czatów przechowywanych w jawnym tekście. Ten kontekst dobrze łączy się z szerszą zmianą pracy zespołów, w której automatyzacja i agenci AI coraz częściej dotykają delivery oraz operacji, co widać też przy rosnących wydatkach na AI coding agents i automatyzację inżynierii.

Dla praktyka najważniejsze jest jedno: jeśli skrypt zakłada, że zwykła komenda zwróci sekret, to po wdrożeniu aktualizacji to założenie przestaje być prawdziwe. Problem nie ogranicza się do lokalnych aliasów czy ręcznej pracy developera. Największe skutki pojawią się tam, gdzie pipeline automatycznie wyciąga credentiale z CLI i przekazuje je dalej do kolejnych kroków.

Jak działają nowe komendy i gdzie pękną pipeline’y

Nowe komendy do pobierania sekretów mają wymuszać świadome działanie użytkownika. W trybie interaktywnym pokazują ostrzeżenia bezpieczeństwa i wymagają jawnego potwierdzenia, zanim wrażliwa wartość zostanie ujawniona. To dobrze odpowiada na problem przypadkowego wycieku w terminalu, ale oznacza też, że stare automatyzacje przestaną działać bez zmian.

Dla środowisk nieinteraktywnych, takich jak CI/CD, przewidziano użycie flag typu --json albo --no-prompts. To ważny detal, bo pokazuje kierunek migracji: nie chodzi o ręczne obchodzenie zabezpieczeń, tylko o przepisanie pipeline’u tak, aby korzystał z nowych, dedykowanych komend w sposób jawny i kontrolowany. Jeżeli organizacja pobiera access token do testów integracyjnych, generuje URL autoryzacyjny do bootstrapu środowiska albo odczytuje hasło użytkownika technicznego, musi wskazać te miejsca explicite.

Najbardziej narażone są skrypty shellowe i kroki w runnerach, które parsują standardowy output tekstowy. Drugą grupą ryzyka są integracje oczekujące starego kształtu odpowiedzi JSON. Trzeci problem to procesy, które w ogóle nie powinny opierać się na eksponowaniu sekretów, ale historycznie tak zostały zbudowane – i dopiero teraz przestaną działać. W tym sensie aktualizacja CLI jest też testem dojrzałości operacyjnej zespołu.

Warto przy okazji przejrzeć nie tylko same pipeline’y, ale też politykę logowania i retencji logów. Jeżeli runner zapisuje pełne outputy z CLI, to nawet po migracji trzeba sprawdzić, czy nowe komendy nie są uruchamiane w zbyt szerokim kontekście i czy ich rezultat nie ląduje w artefaktach builda. To wpisuje się w szerszy temat praktycznego hardeningu orgów i procesów, podobnie jak w materiale o wyciekach powiązanych z Salesforce i integracjami cloud.

Co zrobić teraz, zanim zniknie obejście tymczasowe

Bezpośrednio po wdrożeniu ma być dostępne tymczasowe obejście w postaci zmiennej środowiskowej SF_TEMP_SHOW_SECRETS=true. To bezpiecznik na krótki okres, który ma ograniczyć nagłe awarie pipeline’ów. Nie należy jednak traktować go jako rozwiązania docelowego, bo ma zostać całkowicie usunięty w wydaniu Summer ’26.

Plan działania powinien być prosty i szybki. Najpierw trzeba zidentyfikować wszystkie miejsca, w których skrypty odczytują sekrety z CLI – zarówno w repozytoriach aplikacyjnych, jak i w bibliotekach współdzielonych dla DevOps. Następnie warto rozdzielić przypadki użycia: które procesy naprawdę muszą pobierać sekret w runtime, a które można przebudować tak, by używać bezpieczniejszego mechanizmu lub w ogóle nie eksponować poświadczeń w logice pipeline’u. Dopiero potem należy podmienić stare komendy na nowe i sprawdzić zachowanie w runnerach nieinteraktywnych.

To także dobry moment na przegląd operacji związanych z release managementem przed Summer ’26, bo ta wersja przynosi więcej zmian wpływających na codzienną administrację i delivery. W praktyce warto połączyć migrację CLI z szerszym przeglądem zmian opisanych przy najważniejszych funkcjach Summer ’26 dla adminów.

Najkrótszy możliwy wniosek jest taki: nie czekaj na produkcyjne wdrożenie, tylko testuj zmiany już na release candidate i poprawiaj skrypty zanim obejście tymczasowe zniknie. Ta aktualizacja ogranicza realne ryzyko wycieku credentiali, ale zrobi to kosztem kompatybilności ze starymi nawykami. Pytanie dla zespołów brzmi nie czy migrować, tylko jak szybko znaleźć wszystkie miejsca, w których CLI nadal jest traktowane jak wygodny magazyn sekretów.