Repository navigation
bug: comportamento do matching de severity override mudou silenciosamente na refatoração para matchSeverityOverride #35
Description
Problema
O loop original de severity override embutido em classifyFinding usava um break incondicional fora do switch, então sempre parava no primeiro pattern que desse match — mesmo que override.Severity fosse uma string não reconhecida (caso em que a severidade simplesmente permanecia inalterada). Ao extrair essa lógica para Scanner.matchSeverityOverride (para reuso no teto de severidade dos secret matches), os return passaram a ficar dentro dos cases do switch, então um override que der match com uma severidade não reconhecida não interrompe mais o loop — ele continua verificando os overrides seguintes.
Cenário de falha
Isso normalmente não é alcançável via config YAML, já que config.Parse/Validate já rejeitam valores de severity inválidos em severity_overrides. Só é alcançável quando um config.Config é montado programaticamente, sem passar por Validate() — o que vários testes existentes já fazem via scanner.NewWithConfig. Nesse caso: dois SeverityOverrides dão match no mesmo arquivo, o primeiro tem uma Severity inválida/com erro de digitação, e o segundo é um override diferente e não intencional. Antes, o primeiro match (sem efeito) venceria, deixando a severidade pré-calculada intacta; agora o segundo override passa a valer silenciosamente.
Correção sugerida
Preservar a semântica de "parar no primeiro pattern que der match, independente da severidade ser reconhecida ou não" em matchSeverityOverride, ou decidir explicitamente (documentando e testando) que o novo comportamento — pular overrides com severidade não reconhecida e seguir para o próximo match — é intencional.
Contexto
- Encontrado durante o code review da branch
feat/secret-scanning(commit 40a4708). Este é um caso de borda, não alcançável via config YAML normal. - Arquivo:
internal/scanner/scanner.go:223(matchSeverityOverride)
Activity
[-]bug: severity-override matching changed silently when refactored into matchSeverityOverride[/-][+]bug: comportamento do matching de severity override mudou silenciosamente na refatoração para matchSeverityOverride[/+]joaooncode commentedon Sep 12, 2026
Corrigido em 2672b59.
O que estava errado: o loop original de severity override embutido em
classifyFindingtinha umbreakincondicional fora doswitch, então sempre parava no primeiro pattern que desse match — mesmo com umaSeveritynão reconhecida (nesse caso, sem efeito, severidade pré-calculada intacta). Ao extrair essa lógica paraScanner.matchSeverityOverride, osreturnpassaram a ficar dentro doscases doswitch, então um match com severidade não reconhecida deixava de interromper o loop, permitindo que um override seguinte (não intencional) vencesse silenciosamente.O que mudou:
internal/scanner/scanner.go—matchSeverityOverrideagora tem umdefaultexplícito noswitchque retorna("", false), preservando a semântica original de "parar no primeiro pattern que der match, independentemente de a severidade ser reconhecida ou não".Como foi verificado: adicionado
TestMatchSeverityOverrideStopsAtFirstMatchEvenWhenUnrecognizedeminternal/scanner/scanner_test.go, construindo umconfig.Configprogramaticamente (sem passar porValidate(), como já fazem outros testes viaNewWithConfig) com dois overrides que dão match no mesmo path — o primeiro com severidade inválida — e confirmando que nenhum override é aplicado.go build ./...,go vet ./...ego test ./...passando.Como o próprio issue observa, esse é um caso de borda não alcançável via config YAML normal (já rejeitado por
Validate()), então optei por preservar o comportamento original em vez de tornar o "pular para o próximo override" um comportamento intencional.fix(scanner): parar no primeiro match em matchSeverityOverride mesmo …