Narzędzia open source

Bezpieczeństwo open source, według zadania.

Skanuj kod, sprawdzaj zależności, wykrywaj ujawnione sekrety lub zabezpieczaj agentów AI. Wybierz projekt i poznaj wymagania wdrożenia oraz jego granice.

Znajdź narzędzie Zacznij od wskazówek OWASP

Większość narzędzi wymaga programisty lub osoby z IT do konfiguracji i przeglądu wyników. Przy każdym projekcie znajdziesz oficjalne repozytorium i instrukcję rozpoczęcia pracy. Materiały OWASP poniżej pomogą ustalić, co sprawdzać.

Chcesz połączyć te narzędzia w jeden proces bezpieczeństwa?

Wybierz narzędzie dla konkretnej luki, wyznacz osobę do obsługi i ustal, jak wyniki stają się sprawdzonymi naprawami. Zacznij od obecnego rejestru zadań i dowodów; porównuj koordynację lub zarządzane wsparcie dopiero, gdy ta praca staje się wąskim gardłem.

Zbuduj proces wokół posiadanych narzędzi

Wybierz zadanie

Znajdź punkt wyjścia

Źródła sprawdzono: 2026-10-29

Szukaj projektu lub zadania

Tylko projekty Shielda

Kategoria projektu

Widoczne projekty: 12 / 12

Tygodniowa praca zespołu: plan dla 1–25 osób

Scenariusz planistyczny: 1–25 osób, do 25 urządzeń, 1–3 repozytoria i jedno małe środowisko chmurowe, jeśli dotyczy. Po konfiguracji początkowej, bez aktywnego incydentu i dużych zaległości. Czas oznacza łączną tygodniową pracę zespołu klienta, nie czas na osobę ani czas działania skanera.

Zakresy obejmują rutynowy przegląd, administrację i przypisywanie dalszych zadań. Osobno dolicz wdrożenie, wykonywanie napraw, incydenty, duże aktualizacje, ćwiczenia odtwarzania i pracę audytową lub prawną. Narzędzia wykonują różne zadania: nie sumuj nakładających się szacunków ani nie traktuj ich jako rankingu szybkości.

To redakcyjne budżety czasu, nie deklaracje dostawców, zaobserwowane średnie ani zobowiązania usługowe. Sumujemy pokazane przedziały dla dwóch powtarzalnych zadań. Podlinkowana dokumentacja wyjaśnia zadania, nie liczbę godzin. Zastąp założenie rejestrem czasu z własnego pilotażu; większe lub bardziej złożone środowiska wykraczają poza ten scenariusz.

Skanuj kod źródłowy

Semgrep Community Edition

Znajduj podejrzane wzorce i typowe błędy w kodzie za pomocą konfigurowalnych reguł.

Zastosowanie: Programista, który potrzebuje kontroli kodu lokalnie lub w pull requeście.

Tygodniowy nakład pracy zespołu klienta

~1–3 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd nowych wyników z właścicielami repozytoriów: 30–90 min/tydz.
Utrzymanie reguł i sprawdzenie zakresu skanów: 30–90 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Wybierz reguły dla swojego języka, przeskanuj jedno repozytorium i omów wyniki z właścicielem kodu.
Kto obsługuje: Konfiguracja przez programistę; dobór reguł i przegląd wyników.
Co warto wiedzieć: Analiza CE ogranicza się do funkcji lub pliku. Silnik LGPL jest open source; reguły utrzymywane przez Semgrep mają odrębną licencję ograniczoną do użytku wewnętrznego. Funkcje platformy mają osobne warunki.

Semgrep & contributors LGPL-2.1 (engine); separate rule licenses

Jak zacząć GitHub Zaplanuj z tym narzędziem

Sprawdź zależności

OSV-Scanner

Dopasuj pakiety używane przez projekt do znanych podatności w bazie OSV.

Zastosowanie: Pierwsza kontrola zależności repozytorium, pliku blokady wersji lub obrazu kontenera.

Tygodniowy nakład pracy zespołu klienta

~0,5–2 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd nowych komunikatów i dotkniętych wersji: 15–60 min/tydz.
Sprawdzenie danych skanu i przypisanie aktualizacji: 15–60 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Przeskanuj katalog źródeł lub obsługiwane pliki pakietów. Sprawdź dotknięte wersje i przetestuj proponowane aktualizacje.
Kto obsługuje: Wiersz poleceń lub konfiguracja CI przez programistę.
Co warto wiedzieć: Pokrycie zależy od obsługiwanych ekosystemów i danych o podatnościach. Czysty wynik nie obejmuje błędów własnego kodu ani każdego wdrożonego komponentu.

Google & contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Sprawdź zależności

OWASP Dependency-Check

Raportuj znane podatności powiązane z zależnościami aplikacji.

Zastosowanie: Zespoły potrzebujące raportów o zależnościach w procesie budowania, np. Maven lub Gradle.

Tygodniowy nakład pracy zespołu klienta

~0,5–2 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd nowych komunikatów i dotkniętych wersji: 15–60 min/tydz.
Sprawdzenie danych skanu i przypisanie aktualizacji: 15–60 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Dodaj integrację z procesem budowania lub uruchom CLI. Aktualizuj dane o podatnościach i sprawdzaj dopasowania pakietów.
Kto obsługuje: Konfiguracja przez programistę, pamięć podręczna danych i przegląd wykluczeń.
Co warto wiedzieć: Identyfikacja pakietów może dawać błędne dopasowania. Poświadczenia źródeł i limity zapytań wpływają na skan; projekt zdecydowanie zaleca klucz API NVD.

OWASP project contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Sprawdź zależności

OWASP Dependency-Track

Śledź ryzyko komponentów w aplikacjach na podstawie wykazów składników oprogramowania (SBOM).

Zastosowanie: Zespół potrzebujący stałego przeglądu wielu projektów, a nie jednorazowego skanu.

Tygodniowy nakład pracy zespołu klienta

~1–3 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd wyników komponentów w projektach: 30–90 min/tydz.
Sprawdzenie przesyłania SBOM i stanu usługi: 30–90 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Generuj SBOM-y podczas budowania, przesyłaj je do usługi i wyznacz osoby przeglądające zmiany.
Kto obsługuje: Ktoś musi utrzymywać usługę i przesyłanie SBOM-ów.
Co warto wiedzieć: Wymaga kompletnych, aktualnych wykazów i źródeł komunikatów. Nie zastępuje przeglądu kodu ani kontroli wdrożenia.

OWASP project contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Znajdź ujawnione sekrety

Gitleaks

Utrzymanie: tylko poprawki bezpieczeństwa

Znajduj potencjalne hasła, klucze API i tokeny w historii Git lub plikach.

Zastosowanie: Sprawdzenie repozytorium przed udostępnieniem lub zapobieganie kolejnym commitom z sekretami.

Tygodniowy nakład pracy zespołu klienta

~0,5–1 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd podejrzanych sekretów z właścicielami: 15–30 min/tydz.
Sprawdzenie pokrycia repozytoriów i wyjątków: 15–30 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Przeskanuj repozytorium i dodaj kontrolę przed commitem lub w CI. Unieważnij lub zmień potwierdzone ujawnione poświadczenia.
Kto obsługuje: Konfiguracja przez programistę i właściciel poświadczeń odpowiedzialny za naprawę.
Co warto wiedzieć: Wykrycie nie unieważnia poświadczeń. Opiekun ogranicza obecnie wydania Gitleaks do poprawek bezpieczeństwa; sprawdź README przed wdrożeniem. Odrębna akcja GitHub ma własne warunki.

Gitleaks contributors MIT (CLI)

Jak zacząć GitHub Zaplanuj z tym narzędziem

Testuj aplikację webową

ZAP

Sprawdzaj działającą aplikację webową pod kątem typowych podatności.

Zastosowanie: Testowanie zachowania aplikacji przez HTTP jako uzupełnienie kontroli kodu i zależności.

Tygodniowy nakład pracy zespołu klienta

~1–3 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd wyników aplikacji i odtworzenie priorytetowych problemów: 30–90 min/tydz.
Sprawdzenie zakresu testów, logowania i konfiguracji skanu: 30–90 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Zacznij od własnego środowiska testowego. Skonfiguruj logowanie i zakres, aby skaner docierał do sprawdzanych funkcji.
Kto obsługuje: Konfiguracja przez programistę lub testera; skany po zalogowaniu wymagają dodatkowych ustawień.
Co warto wiedzieć: Aktywne skany wysyłają testowe ataki i mogą zmieniać stan aplikacji. Skanuj wyłącznie dozwolone cele; logika biznesowa i zasady dostępu nadal wymagają testów ręcznych.

ZAP by Checkmarx & contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Sprawdź infrastrukturę

Trivy

Skanuj obrazy kontenerów, pliki i definicje infrastruktury pod kątem znanych podatności, sekretów i błędów konfiguracji.

Zastosowanie: Praktyczna pierwsza kontrola obrazu kontenera lub repozytorium wdrożenia.

Tygodniowy nakład pracy zespołu klienta

~0,5–2 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd nowych komunikatów i dotkniętych wersji: 15–60 min/tydz.
Sprawdzenie danych skanu i przypisanie aktualizacji: 15–60 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Wybierz cel i rodzaje kontroli, wykonaj skan i przypisz wyniki osobom mogącym zmienić obraz lub konfigurację.
Kto obsługuje: Programista lub właściciel infrastruktury; aktualizacja danych i dopasowanie reguł.
Co warto wiedzieć: Wyniki zależą od obsługiwanych pakietów i wybranych skanerów. Narzędzie nie zabezpiecza automatycznie działającej usługi ani nie potwierdza możliwości wykorzystania podatności.

Aqua Security & contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Sprawdź infrastrukturę

Checkov

Sprawdzaj pliki infrastruktury jako kodu pod kątem ryzykownej konfiguracji przed wdrożeniem.

Zastosowanie: Zespoły używające Terraform, CloudFormation, Kubernetes, Helm lub podobnych plików wdrożeniowych.

Tygodniowy nakład pracy zespołu klienta

~0,5–2 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd wyników konfiguracji z właścicielami infrastruktury: 15–60 min/tydz.
Utrzymanie zakresu skanów i wyjątków polityk: 15–60 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Przeskanuj katalog infrastruktury lokalnie lub w CI. Omów niespełnione reguły z osobą odpowiedzialną za środowisko.
Kto obsługuje: Wiedza o infrastrukturze; dopasowanie reguł i uzasadnione wyjątki.
Co warto wiedzieć: Skan konfiguracji nie potwierdza zgodności działającego środowiska z plikami. Usługi platformy i niektóre integracje danych mają odrębne wymagania.

Prisma Cloud / Bridgecrew & contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Oceń praktyki projektu

OpenSSF Scorecard

Sprawdzaj praktyki repozytorium, takie jak przegląd kodu, aktualizacje zależności i ochrona procesu budowania.

Zastosowanie: Wybór zależności open source lub poprawa sposobu utrzymywania własnego projektu.

Tygodniowy nakład pracy zespołu klienta

~0,5–1 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd zmienionych kontroli praktyk projektu: 15–30 min/tydz.
Przypisanie dalszych zadań dotyczących ustawień repozytorium: 15–30 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Przejrzyj poszczególne kontrole repozytorium i zdecyduj, które braki są ważne w Twoim zastosowaniu.
Kto obsługuje: Opiekun projektu lub programista rozumiejący ustawienia repozytorium.
Co warto wiedzieć: Kontrole są heurystykami i mogą dawać błędne wyniki. Wysoka ocena nie dowodzi bezpieczeństwa kodu ani braku podatności.

OpenSSF & contributors Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Monitoruj systemy i komunikaty

Wazuh

Zbieraj zdarzenia bezpieczeństwa i monitoruj urządzenia pod kątem konfiguracji, zmian plików i znanych podatności.

Zastosowanie: Zespół z osobą dostępną do obsługi monitoringu i analizy alertów.

Tygodniowy nakład pracy zespołu klienta

~3–6 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Analiza zdarzeń bezpieczeństwa i przypisanie reakcji: 120–240 min/tydz.
Utrzymanie agentów, reguł i stanu usługi: 60–120 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Wdróż komponenty centralne i agenty na urządzeniach, dopasuj reguły i określ, kto reaguje na alerty.
Kto obsługuje: Stała administracja systemami i obsługa bezpieczeństwa.
Co warto wiedzieć: Hosting, aktualizacje, analiza alertów i reagowanie pozostają po Twojej stronie. Licencje zależą od komponentu: obecne repozytorium zawiera kod GPL-2.0 i silnik AGPL-3.0.

Wazuh & contributors GPL-2.0 / AGPL-3.0 by component

Jak zacząć GitHub Zaplanuj z tym narzędziem

Kontroluj agentów AI

Od Shielda

Agent Guard

Eksperymentalna wersja alfa

Biblioteki TypeScript ograniczające narzędzia dostępne agentowi AI, zasoby, na których działa, i wymagane zatwierdzenia.

Zastosowanie: Programiści dodający kontrolowane wykonywanie narzędzi lub integracje MCP do aplikacji agentowej.

Tygodniowy nakład pracy zespołu klienta

Jeszcze nie zmierzono

Potwierdź odpowiedzialność i czas w pilotażu

Eksperymentalna biblioteka z regułami dostępu i zatwierdzania zależnymi od aplikacji. Zmierz przegląd uprawnień, zmiany polityk i obsługę incydentów w swojej integracji; brak ustalonego tygodniowego punktu odniesienia.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Zarejestruj narzędzia, nadaj zadaniom dostęp i kieruj wywołania przez bibliotekę. Dodaj własny proces uwierzytelnionego zatwierdzania wrażliwych działań.
Kto obsługuje: Integracja w TypeScript i przegląd modelu zagrożeń.
Co warto wiedzieć: Eksperymentalna wersja alfa. Kontroluje zarejestrowane wywołania w jednym procesie; nie jest piaskownicą systemową ani uniwersalnym detektorem wstrzykiwania instrukcji. Trwała lub rozproszona kontrola wymaga dodatkowej infrastruktury.

ShieldaAI Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Monitoruj systemy i komunikaty

Od Shielda

Security Watch

Eksperymentalna wersja alfa

Dopasowuj komunikaty i wiadomości bezpieczeństwa do zadeklarowanej inwentaryzacji, zapisuj dowody i kieruj wyniki do Slacka lub poczty.

Zastosowanie: Mała instalacja potrzebująca wybranych komunikatów dotyczących własnych bibliotek i systemów.

Tygodniowy nakład pracy zespołu klienta

~0,5–2 godz./tydz.

Redakcyjny budżet czasu · 1–25 osób · cały zespół po wdrożeniu

Co obejmuje ten budżet czasu?

Przegląd dopasowanych komunikatów i przypisanie działań: 15–60 min/tydz.
Aktualizacja inwentaryzacji i sprawdzenie dostarczania wyników: 15–60 min/tydz.

Scenariusz i wyłączenia

Uruchomienie, nakład pracy i granice

Jak korzystać: Podaj nazwy pakietów i dokładne zainstalowane wersje, jeśli je znasz. Zacznij od trybu próbnego; ustrukturyzowane kontrole bibliotek mogą działać bez AI.
Kto obsługuje: Konfiguracja usługi Node.js, aktualna inwentaryzacja i osoba przeglądająca alerty.
Co warto wiedzieć: Eksperymentalna wersja alfa. Nie aktualizuje oprogramowania ani nie dowodzi bezpieczeństwa systemu. Brakujące wersje, nieobsługiwane zakresy i dopasowania nazw produktów wymagają przeglądu.

ShieldaAI Apache-2.0

Jak zacząć GitHub Zaplanuj z tym narzędziem

Wskazówki i listy kontrolne

Dowiedz się, czego szukać, z OWASP

Te materiały wyjaśniają ryzyka, bezpieczniejszą implementację i wymagania weryfikacji. Pomagają zaplanować przegląd i zrozumieć wyniki skanerów.

OWASP Top 10

Poznaj główne ryzyka aplikacji webowych i wykorzystaj je w rozmowie z programistą. To przewodnik edukacyjny, nie skaner ani kompletny plan testów.

Czytaj przewodnik

OWASP Cheat Sheet Series

Znajdź praktyczne wskazówki wdrożeniowe dotyczące uwierzytelniania, kontroli dostępu, sekretów, agentów AI i innych zagadnień bezpieczeństwa.

Czytaj przewodnik

OWASP ASVS

Zamień bezpieczeństwo aplikacji w określony zestaw wymagań i zadań weryfikacyjnych. Wybierz zakres z programistą lub recenzentem i zapisz dowody.

Czytaj przewodnik

Shielda utrzymuje projekty oznaczone „Od Shielda” i publikuje ten przewodnik. Opisy opierają się na dokumentacji projektów; nie są niezależnym certyfikatem bezpieczeństwa.

Potrzebujesz pełnego zestawu?