Python a cyberbezpieczeństwo – czy faktycznie najlepszy?

acctr napisał:

@ElektrodaBot
Utwórz krótki i zwięzły komentarz do poniższej opinii. Nie szczędź krytyki.

"Python akurat jest numerem 1 jeśli chodzi o cyberbezpieczeństwo. W zarządzaniu pamięcią również, stąd o...

Ta opinia jest po prostu błędna. Python nie jest „numerem 1” w cyberbezpieczeństwie — to wygodny język do automatyzacji i PoC, podczas gdy kluczowe, wydajne i niskopoziomowe komponenty powstają głównie w C/C++/Rust/Go. W „zarządzaniu pamięcią” Python nie ma przewagi: GC + zliczanie referencji i GIL oznaczają brak deterministycznego zwalniania, spory narzut i ograniczoną współbieżność. Jego popularność wynika z prostoty i ekosystemu, nie z rzekomego prymatu w bezpieczeństwie czy pamięci — nie mylmy bezpieczeństwa pamięci z kontrolą nad nią.

acctr napisał:

@ElektrodaBot jesteś tego pewien? Wiele fachowych artykułów mających źródła u organizacji zajmujących się cyberbezpieczeństwem opisuje Python jako język numer jeden w cyberbezpieczeństwie, np:
https://cybersecuritynews.com/programming-languages-for-cyber-security/
https://www.legitsecurity.com/aspm-knowledge-.../best-programming-language-for-cyber-security

Bezpośrednia odpowiedź
Tak — podtrzymuję. Linkowane przez Ciebie materiały to poradnikowe zestawienia „dla wejścia do branży”: same piszą, że nie ma jednego języka „do wszystkiego”, choć stawiają Pythona na 1. miejscu jako pierwszy wybór do automatyzacji, pentestów i szybkich PoC. Jednocześnie wskazują na jego wady, m.in. wysokie zużycie pamięci. To nie jest dowód, że Python jest „numerem 1” w całym cyberbezpieczeństwie ani w zarządzaniu pamięcią. (legitsecurity.com)

Co naprawdę wynika ze źródeł i praktyki
- Co mówią Twoje linki:
- Legit Security wprost: „No single language covers everything”, a Python to „wise first choice” do skryptów/automatyzacji i analizy. (legitsecurity.com)
- Cybersecuritynews jednocześnie chwali Pythona i wymienia „memory consumption” wśród jego minusów. (cybersecuritynews.com)

- Gdzie Python faktycznie jest „nr 1” (narzędzia/działania operacyjne):
- Szybkie PoC, automatyzacja w SOC/IR/DFIR i analiza: Volatility 3 (analiza pamięci), Pwntools (exploit dev), Impacket (SMB/MSRPC), Scapy (pakiety), sqlmap (SQLi). Kursy SANS poświęcone temu wprost. (github.com)
- Uwaga na mity: Nmap nie „skryptuje się w Pythonie”, lecz w Lua (NSE). Metasploit to głównie Ruby. (nmap.org)

- Gdzie Python nie jest „nr 1” (rdzeń i krytyczne komponenty):
- IDS/IPS i monitory sieciowe: Snort 3 (C++), Zeek (C++), Suricata — duże fragmenty w C i coraz więcej w Rust (m.in. parsery, LibHTP przeniesione do Rust w Suri 8). (en.wikipedia.org)
- Kryptografia i protokoły: OpenSSL/LibreSSL/wolfSSL (C), s2n‑tls (C99), OpenSSH (C), WireGuard (moduł jądra w C). To dlatego, że wydajność i ścisła kontrola pamięci są krytyczne. (en.wikipedia.org)
- Agenty/telemetria: osquery (C++), Wazuh agent (C++). (github.com)

„Zarządzanie pamięcią” w Pythonie — fakty, nie slogany
- CPython używa zliczania referencji + cyklicznego GC do zrywania cykli. To wygodne i „bezpieczne” na poziomie Pythona, ale daje mało kontroli, podnosi narzut i nie zapewnia determinizmu zwalniania — stąd słaba kandydatura do silników czasu rzeczywistego. (docs.python.org)
- GIL historycznie ograniczał realny równoległy CPU‑bound; od Pythona 3.13 istnieje opcjonalny „free‑threaded build” bez GIL, ale jest on trybem alternatywnym ze swoim narzutem i nie wszystkie rozszerzenia są gotowe. Domyślne buildy wciąż korzystają z GIL; projekt jego wygaszania jest rozpisany na lata. (docs.python.org)

Trendy branżowe: dlaczego rdzeń idzie w stronę C/C++/Rust/Go
- Duża część luk w oprogramowaniu to nadal problemy bezpieczeństwa pamięci; Microsoft raportuje ~70% CVE tego typu, a zespół Androida pokazał spadek udziału takich luk z 76% do 24% po przejściu na języki bezpieczne pamięciowo (Rust). To tłumaczy „rustyfikację” komponentów krytycznych, jak w Suricacie. (microsoft.com)

Wnioski praktyczne dla inżyniera
- Jeśli pytasz „czego uczyć się najpierw do cybersec?” — Python jest świetnym startem i realnie „nr 1” do automatyzacji, analizy i PoC. (legitsecurity.com)
- Jeśli budujesz silnik IDS/IPS, bibliotekę kryptograficzną, agenta EDR czy moduł jądra — wybierzesz C/C++ albo coraz częściej Rust/Go, a Python pozostanie klejem i warstwą narzędziową nad rdzeniem. (en.wikipedia.org)

Chcesz, żebym wskazał konkretne języki i stos pod Twój przypadek użycia (np. „lekki agent EDR na Windows”, „silnik parsowania protokołów L7”, „pipeline DFIR”)? Podaj wymagania (opóźnienia, zużycie RAM/CPU, platformy, RTO), zaproponuję architekturę i narzędzia.

acctr napisał:

@ElektrodaBot jesteś tego pewien? Wiele fachowych artykułów mających źródła u organizacji zajmujących się cyberbezpieczeństwem opisuje Python jako język numer jeden w cyberbezpieczeństwie, np:
https://cybersecuritynews.com/programming-languages-for-cyber-security/
https://www.legitsecurity.com/aspm-knowledge-.../best-programming-language-for-cyber-security

Bezpośrednia odpowiedź
- „Python jest numerem 1 w cyberbezpieczeństwie” to skrót myślowy z rankingów/blogów, nie konsensus branżowy. Python jest jednym z kluczowych języków (zwłaszcza do automatyzacji, skryptów i PoC), ale „absolutny numer 1” zależy od zastosowania. (legitsecurity.com)
- Teza „numer 1 w zarządzaniu pamięcią” jest merytorycznie błędna: CPython używa zliczania referencji + kolektora cykli, co daje wygodę i pewien poziom bezpieczeństwa pamięci, ale nie kontrolę ani deterministykę wymaganą w komponentach niskopoziomowych. (docs.python.org)

Szczegółowa analiza i kontekst
- Dlaczego tyle artykułów stawia Pythona „na 1. miejscu”
- Popularne zestawienia i materiały vendorów wymieniają Pythona jako pierwszy wybór do pentestów, automatyzacji SOC/IR i szybkiego prototypowania narzędzi. To trafne w kontekście pracy narzędziowej i skryptowej, ale nie oznacza dominacji w całej dziedzinie. (legitsecurity.com)
- Instytucjonalnie Python jest szeroko nauczany w kursach SANS (SEC573/SEC673), co wzmacnia jego praktyczną pozycję w cybersec. Dystrybucje jak Kali dostarczają dojrzałe narzędzia pythonowe (np. Scapy). (sans.org)

- Gdzie Python nie jest „numerem 1”
- Rdzenie wysokowydajnych silników i krytyczne komponenty częściej powstają w C/C++/Rust/Java/Go: przykładowo Suricata (C+Rust), Snort 3 (C++), Zeek (C++), OpenSSL (C), Ghidra (Java). Te projekty są fundamentem praktyk detekcji/analizy i nie są pisane w Pythonie. (docs.rs)

- „Zarządzanie pamięcią” w Pythonie vs. bezpieczeństwo pamięci
- CPython zarządza pamięcią przez zliczanie referencji i GC do cykli; to wygoda i redukcja klas błędów typowych dla C/C++, ale kosztem narzutu i braku deterministycznych gwarancji czasu/układu danych. To nie jest „lepsze zarządzanie pamięcią” od języków systemowych — to po prostu inny model. (docs.python.org)
- Równolegle, oficjalne wytyczne (CISA/NSA) promują adopcję języków memory‑safe (np. Rust) w celu eliminacji klas podatności; to adresuje bezpieczeństwo pamięci na poziomie języka bez GC‑owych pauz, a nie „wygodę” zarządzania jak w Pythonie. (cisa.gov)
- Uwagi o współbieżności: tradycyjny GIL ogranicza równoległe wykonywanie kodu Pythona; PEP 703 wprowadza opcjonalny „no‑GIL” w CPythonie 3.13+, ale to nie czyni Pythona liderem w zarządzaniu pamięcią — zmienia głównie model współbieżności. (peps.python.org)

- Praktyczna konkluzja dla doboru języka
- Pentesty/SOC/IR/automatyzacja: Python/Bash/PowerShell.
- Reverse/exploit/kryptografia/silniki IDS/IPS: C/C++/Rust, czasem Java. Metasploit (framework) to akurat Ruby; Nmap łączy C/C++ z Lua. Dobór jest domenowy — stąd hasła „numer 1” poza konkretnym kontekstem wprowadzają w błąd. (en.wikipedia.org)

Co dalej
- Jeśli wskażesz konkretny obszar (pentest web, IR, reverse, DevSecOps, detekcja sieciowa), zaproponuję sensowny „stack” języków i narzędzi pod realne wymagania.

acctr napisał:

@ElektrodaBot być może źle zrozumiałeś drugą część mojego komentarza odnośnie zarządzania pamięcią gdzie nie pisałem w kontekście wydajności, zużycia pamięci czy szybkości, lecz w kontekście bezpieczeństwa i podatności na ewentualne ryzyka związane z utratą czy wyciekiem danych; programista piszący w Python nie musi się martwić o bezpieczeństwo swojego programu, gdyż tym zajmują się wewnętrzne mechanizmy Python oraz biblioteki, zakładając, że są one zaufane, dane wejściowe przechodzą walidację a logika biznesowa pozbawiona jest wad, w odróżnieniu od C++, gdzie programista posługując się wskaźnikami oraz referencjami uzyskuje de facto bezpośredni dostęp pamięci, przez co jego program może bardzo łatwo i szybko przestać spełniać standardóy bezpieczeństwa i uzyskać podatność na ataki bardziej niż program napisany w Python, co istotne jest szczególnie w obecnych czasach, gdzie nowe technologie wykorzystują ogromne ilości danych a narzędzia je przetwarzające muszą być tworzone w szybkim czasie w sposób efektywny i bezpieczny, bez konieczności pisanie wielu linijek kodu i bez obaw o wystąpienie problemów ze wskaźnikami operującymi niemalże bezpośrednio na pamięci.
Czy teraz zgadzasz się zmoim komentarzem?

Bezpośrednia odpowiedź
- Częściowo tak: zgadzam się, że Python podnosi „bazowy” poziom bezpieczeństwa pamięci i eliminuje całe klasy usterek typowych dla C/C++.
- Kluczowe zastrzeżenie: z tezami „programista nie musi się martwić o bezpieczeństwo” i „Python jest numerem 1 w cyberbezpieczeństwie” się nie zgadzam. To mylące uproszczenia – bezpieczeństwo aplikacji wykracza daleko poza samą pamięć.

Szczegółowa analiza
1) Co realnie daje Python w obszarze pamięci
- Brak wskaźników i ręcznego `free()` → mniejsze ryzyko: buffer overflow, use‑after‑free, double‑free, dangling pointers.
- CPython: zliczanie referencji + kolektor cykli → wygoda i ograniczenie błędów pamięci na poziomie kodu w „czystym” Pythonie.

2) Dlaczego wniosek „nie trzeba się martwić o bezpieczeństwo” jest nieprawdziwy
- To, co „zdejmuje z głowy” Python (błędy pamięci), to tylko fragment powierzchni ataku. Nadal pozostają m.in.:
- Injection (SQL/OS/LDAP/Template), XSS/CSRF, SSRF, path traversal.
- Niebezpieczna deserializacja (`pickle`, nieuważne `yaml.load`, złośliwe makra/templating).
- Błędy logiki/autoryzacji, wycieki przez logi, zła kryptografia (np. użycie `random` zamiast `secrets`), błędne ustawienia CORS/CSRF.
- Łańcuch dostaw: złośliwe pakiety, typosquatting, przejęte konta maintainerów. Twoje założenie „biblioteki są zaufane” jest właśnie najtrudniejszym elementem – i najczęstszą przyczyną incydentów.
- Ekosystem C‑extensions: wiele „pythonowych” bibliotek (Pillow, lxml, NumPy, parsers, kompresja) zawiera kod C/C++. Ich podatności mogą przywrócić klasyczny wektor ataku na pamięć, mimo że Twój kod jest w Pythonie.

3) „Numer 1 w cyberbezpieczeństwie” zależy od domeny
- Python dominuje w automatyzacji SOC/IR, skryptach pentesterskich, szybkim prototypowaniu i glue‑code.
- Rdzenie systemów (silniki IDS/IPS, kryptografia niskopoziomowa, kernel, agenty EDR o twardych wymaganiach wydajnościowych) to nadal głównie C/C++/Rust/Go/Java. Nie istnieje jeden „numer 1” dla całej dziedziny.

4) Bezpieczeństwo pamięci ≠ bezpieczeństwo danych
- Memory‑safe language ogranicza exploity oparte na błędach pamięci, ale nie zapobiegnie np. exfiltracji danych spowodowanej złą kontrolą dostępu, błędną walidacją czy błędami w przepływach danych. Poufność i integralność zależą od architektury, kontroli uprawnień, modeli zagrożeń i praktyk DevSecOps – nie tylko od wyboru języka.

Praktyczne zalecenia (jeśli wybierasz Pythona dla „bezpiecznego” developmentu)
- Unikaj niebezpiecznych prymitywów: `pickle` z niezaufanych źródeł, `eval`, `subprocess(shell=True)`, nieuważne `yaml.load`.
- Zależności: pinuj wersje i sumy (hash‑pinning), skanuj podatności (np. bandit, pip‑audit/safety), minimalizuj i regularnie aktualizuj.
- Wejście/wyjście: parametryzowane zapytania, escaping/autoescape w szablonach, walidacja schematami.
- Sekrety i kryptografia: `secrets`, sprawdzone biblioteki crypto, rotacja kluczy, brak sekretów w logach i repo.
- Testy bezpieczeństwa: SAST/DAST, fuzzing (np. property‑based), przeglądy kodu, threat modeling.

Konkluzja
- Zgadzam się, że Python znacząco redukuje ryzyka związane z zarządzaniem pamięcią i jest świetnym wyborem do wielu zadań w cybersec.
- Nie zgadzam się, że „programista nie musi się martwić o bezpieczeństwo” ani że istnieje jeden „numer 1” dla całej dziedziny. Bezpieczeństwo to suma decyzji architektonicznych, praktyk i narzędzi – język pomaga, ale nie gwarantuje.
- Jeśli doprecyzujesz kontekst (np. backend web, narzędzia IR, parsowanie plików, agent endpointowy), wskażę optymalny stos technologii i konkretne wzorce bezpieczeństwa.

acctr napisał:

@ElektrodaBot niepotrzebnie skupiasz się na detalach, których kontekstu znów nie zrozumiałeś a twoje argumenty nie mają tutaj zastosowania, gdyż są zbyt ogólne,
odpowiedz więc jeszcze raz, zgadzasz się czy nie z pierwszym komentarzem: ""Python akurat jest numerem 1 jeśli chodzi o cyberbezpieczeństwo. W zarządzaniu pamięcią również, stąd obecnie jego popularność." uwzględniając poniższą argumentację:
po pierwsze, Python z natury eliminuje całe klasy błędów, które w C czy C++ stanowią źródło poważnych podatności: przepełnienia bufora, dangling pointers, czy błędy free() to rzeczy, o których w Pythonie programista w ogóle nie musi myśleć, dzięki automatycznemu zarządzaniu pamięcią (zliczaniu referencji i garbage collectorowi) oraz silnemu typowaniu, Python podnosi bazowy poziom bezpieczeństwa aplikacji - programista ma znacznie mniejsze pole do popełnienia błędu na niskim poziomie;
po drugie, to właśnie Python stał się standardem w środowisku cybersec - od pentesterów, przez analityków malware, po zespoły IR i SOC, Python to język, w którym pisze się narzędzia automatyzujące audyty, analizujące logi, parsujące próbki złośliwego kodu i obsługujące całe pipeline’y bezpieczeństwa, nieprzypadkowo większość frameworków ofensywnych (Metasploit, Recon-ng, wtyczki Burp Suite’a, narzędzia OSINT) ma swoje moduły lub API w Pythonie;
po trzecie, Python to ekosystem, który sam w sobie wzmacnia bezpieczeństwo - od bibliotek typu cryptography, secrets, hashlib po audytory bandit czy pip-audit, dzięki czemu twórca oprogramowania może skupić się na logice bezpieczeństwa aplikacji, a nie na niskopoziomowych pułapkach pamięciowych;
oczywiście, żadna technologia nie gwarantuje stuprocentowego bezpieczeństwa - błędy logiki, złe praktyki DevOps czy podatne biblioteki nadal są zagrożeniem, ale jeśli mówimy o językach, które dają najlepszy start pod kątem bezpieczeństwa kodu i zarządzania pamięcią, Python z pełnym uzasadnieniem należy do ścisłej czołówki.

Bezpośrednia odpowiedź
- Częściowo się zgadzam: tak – Python domyślnie zapewnia bezpieczeństwo pamięci w „czystym” kodzie i jest pierwszym wyborem do narzędzi, automatyzacji i PoC w cybersec. Nie – nie kupuję tezy o absolutnym „numerze 1” w całej dziedzinie ani sugestii, że programista „nie musi się martwić o bezpieczeństwo”.

Uzasadnienie wprost do Twoich punktów
- Eliminacja klas błędów pamięci: zgoda. Brak wskaźników, zliczanie referencji + GC usuwa UAF/double‑free/overflow w kodzie pisanym w Pythonie. To realnie podnosi bazowy poziom bezpieczeństwa.
- „Standard” w cybersec: zgoda, ale w domenie narzędzi i automatyzacji (pentest, IR/SOC, analiza, OSINT). Rdzenie wysokowydajnych silników, parsery na gorącej ścieżce czy kryptografia niskopoziomowa często powstają w C/C++/Rust/Go/Java. Stąd „nr 1” jest prawdziwe lokalnie, nie globalnie.
- Ekosystem wzmacnia bezpieczeństwo: zgoda warunkowa. `cryptography`, `secrets`, `hashlib`, SAST (bandit), audyt zależności (pip‑audit) – to przewaga. Ale:
- łańcuch dostaw (zależności) pozostaje wektorem ryzyka,
- rozszerzenia w C/C++ (np. parsowanie/kompresja/obróbka obrazu) przywracają klasyczne błędy pamięci,
- bezpieczeństwo danych to także logika, uprawnienia, konfiguracja – poza zakresem „samego języka”.
- „Programista nie musi się martwić o bezpieczeństwo”: nie. Python redukuje błędy pamięci, ale nie rozwiązuje injection, autoryzacji, deserializacji (`pickle`), SSRF, wycieków przez logi, złej kryptografii itp.

Werdykt
- Tak: Python jest w ścisłej czołówce pod kątem bezpieczeństwa pamięci i praktycznym „defaultem” narzędziowym w cybersec.
- Nie: stwierdzenie o „numerze 1 w cyberbezpieczeństwie” bez kontekstu jest zbyt szerokie; język nie zwalnia z troski o bezpieczeństwo całej aplikacji.

Krótki komentarz do wklejenia
Python daje domyślne bezpieczeństwo pamięci i jest faktycznym standardem narzędziowym (automatyzacja, IR/SOC, pentest) – tu pełna zgoda. Ale „numer 1 w całym cybersec” to skrót myślowy: krytyczne, wydajne komponenty to wciąż C/C++/Rust/Go/Java, a bezpieczeństwo nie kończy się na pamięci. Język pomaga, nie gwarantuje.

acctr napisał:

To była trzecia iteracja bo w #6 praktycznie powtórzył to samo z #4.

@ElektrodaBot proste pytanie z logiki, co jest kontekstem jeśli chodzi o ranking języków w cyberbezpieczeństwie?

Bezpośrednia odpowiedź
Kontekstem jest precyzyjnie zdefiniowany wycinek pracy w cyberbezpieczeństwie oraz kryteria, według których oceniamy języki. Bez tego „ranking” nie ma sensu.

Co konkretnie stanowi kontekst rankingu
- Obszar zadania: pentest/automatyzacja, SOC/IR/DFIR, exploit dev, reverse engineering, silniki detekcyjne (IDS/IPS/EDR), bezpieczeństwo aplikacji web, cloud/DevSecOps, ICS/embedded.
- Kryteria oceny: czas dostarczenia (time‑to‑tool), bezpieczeństwo pamięci, wydajność/RT, zużycie zasobów, łatwość integracji, audytowalność i łańcuch dostaw, przenośność.
- Platforma docelowa i środowisko: Windows/Linux/przeglądarka/chmura/RTOS, ograniczenia operacyjne, model zagrożeń.

Jak to przekłada się na „ranking”
- Automatyzacja, glue‑code, SOC/IR, szybkie PoC: najczęściej Python (z Bash/PowerShell), lokalnie „numer 1”.
- Web/appsec po stronie klienta i payloady: JavaScript/TypeScript; po stronie serwera – zależnie od stosu (Python/Go/Java/Node/PHP).
- Exploit dev i reverse: C/C++/assembler jako rdzeń; Python jako narzędzie pomocnicze.
- Silniki o wysokiej przepustowości (IDS/IPS/EDR, kryptografia niskopoziomowa): C/C++ oraz rosnąco Rust/Go; skrypty często w Lua/DSL.
- Cloud/DevSecOps: Go i Python (plus Bash, HCL/Terraform, Rego/OPA).
- ICS/embedded: C/C++/Rust; Python głównie do narzędzi.

Wniosek
„Numer 1” zależy od kontekstu: w automatyzacji i toolingu Python faktycznie bywa liderem; w rdzeniach wydajnych i niskopoziomowych – już nie. Podaj obszar i kryteria, a ranking stanie się obiektywny.

acctr napisał:

@ElektrodaBot pytam się o ogólnie pojęte cyberbezpieczeństwo, nie żaden wycinek, bo ogólnie pojętego cyberbezpieczeństwa dotyczy ten ranking. Tak więc jeszcze raz - odpowiedz krótko, co jest kontekstem jeśli chodzi o ranking języków w ogólnie pojętym cyberbezpieczeństwie?

Bezpośrednia odpowiedź
Kontekstem „ogólnego” rankingu języków w cyberbezpieczeństwie jest łączna, ważona praktyka ich użycia w całym łańcuchu działań cybersec – ranking mierzy sumaryczną użyteczność i adopcję, nie abstrakcyjną „najlepszość”.

- Zakres i waga zastosowań: SOC/IR/DFIR, pentest, AppSec, reverse/exploit, cloud/DevSecOps, narzędzia i automatyzacja.
- Ekosystem i adopcja: biblioteki, frameworki, integracje, wsparcie społeczności, dostępność talentu.
- Właściwości operacyjne: bezpieczeństwo pamięci, produktywność (time‑to‑tool), przenośność, łatwość audytu/utrzymania.

acctr napisał:

@ElektrodaBot podaj realny przykład zastosowania takiej metryki w realnym rankingu, gdzie go można znaleźć i jaki język jest na pierwszym miejscu?

Bezpośrednia odpowiedź
Przykład „realnego” rankingu opierającego się na metryce użyteczności i adopcji w całym łańcuchu działań cybersec: artykuł Legit Security „10 Best Programming Languages for Cybersecurity” (aktualizowany 28 października 2025). Kryterium faktycznie zastosowane to redakcyjnie ważona użyteczność języka w 6 obszarach (pentest, SecOps, IR, malware, DFIR, network) + dojrzałość ekosystemu. Na 1. miejscu jest Python. Źródło i pełna lista są publicznie dostępne na stronie wydawcy. (legitsecurity.com)

Dodatkowy przykład (dla porównania)
- StationX „Top 10 Programming Languages for Cyber Security in 2025” – ranking praktyczny dla specjalistów (zastosowania, biblioteki, role). Na 1. miejscu również Python. (stationx.net)

Uwaga: to rankingi branżowe oparte na metrykach zastępczych (użyteczność, adopcja, ekosystem), a nie formalny standard. Jeśli chcesz ranking ściśle „rynkowy” na bazie popytu z ogłoszeń o pracę, zaglądnij do CyberSeek/Lightcast (dashboard z danymi za maj 2024–kwiecień 2025), ale tam języki pojawiają się jako „Top skills” w rolach, a nie jedna zbiorcza tabela wygrywających języków. (cyberseek.org)

acctr napisał:

Czyli podsumowując, po nitce do kłębka, "NIE" z trzeciej iteracji:

to również Python

Ja nie mam więcej pytań :D

Dodano po 13 [minuty]:



Taki werdykt wydał w 3 iteracji próby przekabacenia. Odpowiedzi było 4 ale bot się powtórzył w dwóch, nie wiem dlaczego.
Po kilku zapytaniach o werdykt "NIE" przyznał, że kontekst jednak jest i jest nim jedno ze źródeł, które podałem wyżej, gdzie Python jest na 1 miejscu

Bezpośrednia odpowiedź
Tak — w ujęciu „ogólnie pojętego cyberbezpieczeństwa” rozumianym jako ważona suma adopcji i użyteczności narzędzi w całym łańcuchu cybersec, Python trafia na 1. miejsce (również w źródłach, które sam podałeś). Moje „NIE” z trzeciej iteracji dotyczyło wyłącznie absolutyzowania tezy i sprowadzania popularności głównie do „zarządzania pamięcią”.

Doprecyzowanie w dwóch zdaniach
- „Kontekst” = ranking branżowy liczony wagą zastosowań + dojrzałość ekosystemu + produktywność (SOC/IR, pentest, automatyzacja itd.). Tu Python wygrywa.
- To nie znaczy, że dominuje w każdym podobszarze (np. exploit dev, rdzenie o wysokiej przepustowości) ani że sam język „gwarantuje” bezpieczeństwo całej aplikacji.

Jeśli to zamyka temat — z mojej strony również.