New Crowdin translations by GitHub Action

i18n/pl/basics/common-threats.md

@@ -114,13 +114,13 @@ Ten rodzaj ataku może być przeprowadzony na kilka sposobów:
 2. Deweloper może zostać zmuszony przez podmiot zewnętrzny do dodania złośliwego kodu.
 3. Osoba lub grupa może zidentyfikować zależność zewnętrzną (bibliotekę) i spróbować ją zainfiltrować powyższymi metodami, wiedząc, że zostanie użyta przez deweloperów na szczeblu „downstream”.
 
-Tego rodzaju ataki mogą wymagać dużo czasu i przygotowań oraz są ryzykowne, bo można je wykryć — szczególnie w popularnych projektach open source, na które zwraca się uwagę z zewnątrz. Niestety są też jednymi z najgroźniejszych, ponieważ trudno je całkowicie wyeliminować. We would encourage readers to only use software which has a good reputation and makes an effort to reduce risk by:
+Tego rodzaju ataki mogą wymagać dużo czasu i przygotowań oraz są ryzykowne, bo można je wykryć — szczególnie w popularnych projektach open source, na które zwraca się uwagę z zewnątrz. Niestety są też jednymi z najgroźniejszych, ponieważ trudno je całkowicie wyeliminować. Zalecamy korzystanie tylko z oprogramowania o dobrej reputacji, które podejmuje wysiłki zmniejszające ryzyko, na przykład poprzez:
 
-1. Only adopting popular software that has been around for a while. The more interest in a project, the greater likelihood that external parties will notice malicious changes. A malicious actor will also need to spend more time gaining community trust with meaningful contributions.
-2. Finding software which releases binaries with widely-used, trusted build infrastructure platforms, as opposed to developer workstations or self-hosted servers. Some systems like GitHub Actions let you inspect the build script that runs publicly for extra confidence. This lessens the likelihood that malware on a developer's machine could infect their packages, and gives confidence that the binaries produced are in fact produced correctly.
-3. Looking for code signing on individual source code commits and releases, which creates an auditable trail of who did what. For example: Was the malicious code in the software repository? Which developer added it? Was it added during the build process?
-4. Checking whether the source code has meaningful commit messages (such as [conventional commits](https://conventionalcommits.org)) which explain what each change is supposed to accomplish. Clear messages can make it easier for outsiders to the project to verify, audit, and find bugs.
-5. Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enabling undesirable behavior. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.
+1. Przyjmowanie wyłącznie popularnego oprogramowania, które istnieje od dłuższego czasu. Im większe zainteresowanie projektem, tym większe prawdopodobieństwo, że zewnętrzne podmioty zauważą złośliwe zmiany — a cyberprzestępca będzie musiał poświęcić więcej czasu, żeby zdobyć zaufanie społeczności poprzez znaczący wkład.
+2. Wybieranie oprogramowania, które publikuje wydania binarne przy użyciu powszechnie stosowanych, zaufanych platform do kompilacji, zamiast z maszyn deweloperskich czy serwerów hostowanych samodzielnie. Niektóre systemy, jak GitHub Actions, umożliwiają publiczne sprawdzenie skryptu kompilacji, co daje dodatkową pewność. Zmniejsza to prawdopodobieństwo, że złośliwe oprogramowanie na maszynie dewelopera zainfekuje pakiety, i zwiększa pewność, że wersje binarne zostały poprawnie utworzone.
+3. Szukanie podpisywania kodu dla pojedynczych commitów i wydań, co tworzy możliwy do skontrolowania ślad, kto co zrobił, np. czy złośliwy kod znajdował się w repozytorium oprogramowania,  który deweloper go dodał,  albo czy został wprowadzony w procesie kompilacji.
+4. Sprawdzanie, czy historia commitów zawiera sensowne komunikaty (takie jak [conventional commits](https://conventionalcommits.org)), które wyjaśniają, co ma osiągnąć każda zmiana. Jasne komunikaty ułatwiają osobom postronnym weryfikację, audyt i odnajdywanie błędów.
+5. Zwracanie uwagi na liczbę współtwórców i maintainerów projektu. Samotny deweloper może być bardziej podatny na przymus dodania złośliwego kodu przez podmiot zewnętrzny lub na niedbalstwo umożliwiające niepożądane zachowania — co często oznacza, że oprogramowanie tworzone przez tzw. *Big Tech* podlega większej kontroli niż projekt jednego dewelopera, który nie odpowiada przed nikim.
 
 ## Privacy from Service Providers