View Source

Część reguł Sonara działa na podstawie wzorca w kodzie i nie zna kontekstu: nie wie, co jest w zmiennej, jak Spring obsługuje dany typ ani czym jest nasza adnotacja. Takie zgłoszenia oznaczamy na serwerze zamiast zmieniać kod. Ta strona zbiera przypadki, które już przeanalizowaliśmy, oraz opisuje, jak oznaczać nowe.

Znane fałszywe alarmy

Reguła	Sytuacja	Dlaczego to nie jest problem	Status na serwerze
`java:S5443`	Plik tymczasowy tworzony przez `Files.createTempFile` (NIO) bez wskazania katalogu	Metoda losuje nazwę i atomowo tworzy plik z prawami tylko dla właściciela (`rw-------`). Opis reguły w Sonarze sam uznaje ten sposób za bezpieczny.	False Positive
`java:S6814`	Opcjonalny parametr REST typu `boolean`: `@RequestParam( required = false ) boolean`	Spring zamienia brak parametru typu `boolean` na `false`; błąd dotyczy tylko innych typów prostych (`int`, `long`). W nowym kodzie pisz `@RequestParam( defaultValue = "false" ) boolean` — reguła pomija parametry z `defaultValue`.	False Positive
`java:S6418`	Stała z `AUTH`, `TOKEN`, `SECRET` w nazwie, której wartość nie jest sekretem (np. nazwa pliku DLL)	Reguła zgaduje po nazwie zmiennej i „losowości” wartości.	False Positive
`java:S2229`	Metoda z `@SharkTransactional` woła w tej samej klasie metodę z `@Transactional`	Sonar nie rozpoznaje naszej adnotacji złożonej i uznaje metodę za nietransakcyjną. Transakcja Sharka istnieje.	False Positive
`java:S5867`	Zakres `A-Za-z` we wzorcu dla danych, które według specyfikacji są tylko ASCII (np. nazwy nagłówków HTTP)	Ograniczenie do ASCII jest celowe; klasa Unicode przepuszczałaby niepoprawne znaki.	False Positive
`findbugs:USO_UNSAFE_STATIC_METHOD_SYNCHRONIZATION`	Statyczne metody `synchronized` w `IndexFiles` (indeksowanie Lucene)	Blokadę może przejąć tylko kod w tej samej maszynie Javy (rdzeń albo wtyczki), nie z zewnątrz. Wspólna blokada na klasie jest celowa.	Accepted

Analizy: PWFL-14146, PWFL-14147. Te same przypadki są w skillu sonarqube-analysis, więc asystent AI rozpoznaje je bez ponownej analizy.

False Positive czy Accepted

False Positive — reguła się myli: w tym kodzie problemu nie ma (np. Spring obsługuje boolean poprawnie).
Accepted — reguła ma rację co do mechanizmu, ale świadomie akceptujemy ryzyko, bo w naszym kontekście jest pomijalne albo poprawka kosztuje więcej, niż daje (np. blokada dostępna tylko dla kodu w tej samej maszynie Javy).

Oba statusy wyłączają zgłoszenie z oceny bramki jakości.

Jak oznaczyć zgłoszenie

Oznaczaj dopiero po scaleniu zmian do mastera i analizie na serwerze — wcześniej zgłoszenia na serwerze nie ma.

W interfejsie Sonara:

Otwórz projekt PlusWorkflow → zakładka Issues i znajdź zgłoszenie.
Zmień status na False Positive albo Accept.
Dodaj komentarz z uzasadnieniem i numerem zgłoszenia w Jirze, w którym je przeanalizowano. Bez uzasadnienia nikt później nie odróżni świadomej decyzji od przeoczenia.

Przez asystenta AI: poproś np. „oznacz zgłoszenia S6814 w GadgetController jako False Positive z uzasadnieniem”. Asystent zmieni status i doda komentarz. Zmiana jest podpisana Twoim tokenem.

Nie ukrywaj fałszywych alarmów w kodzie adnotacją @SuppressWarnings ani komentarzem // NOSONAR. Takie oznaczenie nie ma uzasadnienia widocznego w Sonarze i wyłącza regułę także wtedy, gdy kod zmieni się tak, że problem stanie się prawdziwy.

Nowy fałszywy alarm

Jeśli przeanalizujesz nowy, powtarzalny przypadek, dopisz go do tabeli na tej stronie i do tabeli „Znane fałszywe alarmy” w skillu .claude/skills/sonarqube-analysis/SKILL.md (przez MR). Dzięki temu asystent AI nie będzie analizował go od nowa.