Address false warnings raised for known renderable classes specified with fully qualified paths

[that-jill]

We noticed some instances of Brakeman raising warnings in our application when there wasn't a clear issue. Demonstrating them here instead of in an issue so that I can show failing specs and help tackle the root cause. (Happy to open an issue as well, but failing specs I think are clearer than any written explanation of the situation).

About our app:

it's quite old and large (Brakeman reports finding 1216 controllers and 1865 models). We use CBRA to help manage it, with lots of organized modules / components. It's usual for our developers to specify a fully-qualified path (::MyViewComponent vs MyViewComponent) due to our unique architecture. In this case, the fully-qualified path specifications were causing Brakeman to raise warnings while rendering ViewComponents across the app.

Will start working on a fix; definitely open to questions/opinions on the best way to tackle this.

[dryrunsecurity[bot]]

Hi there :wave:, @dryrunsecurity here, below is a summary of our analysis and findings.

DryRun Security	Status	Findings
AppSec Analyzer (beta)	:white_check_mark:	0 findings
Secrets Analyzer (beta)	:white_check_mark:	0 findings
Authn/Authz Analyzer	:white_check_mark:	0 findings
Configured Codepaths Analyzer	:white_check_mark:	0 findings
Sensitive Files Analyzer	:white_check_mark:	0 findings

[!Note] :green_circle: Risk threshold not exceeded.

[!Tip] Get answers to your security questions. Add a comment in this PR starting with @dryrunsecurity. For example...

@dryrunsecurity What are common security issues with web application cookies?

Powered by DryRun Security

[presidentbeef]

I'm really leaning towards either making this entire check optional (non-default) or stop warning about anything that's not string interpolation. It's just becoming too noisy with some of these newer patterns.