Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent vulnerability findings due to fluctuating system resources #1562

Open
metekeltek opened this issue Apr 9, 2024 · 3 comments
Open
Labels
enhancement New feature or request

Comments

@metekeltek
Copy link

We discovered that using the bearer scanner in an environment with less computing power can lead to fewer findings by the scanner.

We ran bearer scan in debug mode and saw that the reason for this is the fixed File Timeout found in this settings file.

This can lead to vulnerabilities not being discovered by bearer if scanning a file with a vulnerability takes longer than 30 seconds.
E.g. 2024-04-09 14:14:57 DBG error processing public/lib/prism.js: file processing time exceeded process=main . Here prism.js could not be scanned by bearer in 30 seconds which led to 2 high findings not being discovered by the scanner.

I would suggest adding a flag --file-timeout (similar to --domain-resolution-timeout), where a custom file timeout can be set.

This way, even less powerful environments can unlock the full potential of bearer.

@metekeltek metekeltek added the enhancement New feature or request label Apr 9, 2024
@cfabianski
Copy link
Collaborator

Thanks @metekeltek for the feedback.
I think it would be a matter of reverting this commit #477 which has been done in an attempt to reduce the noise in the flags.

@kovacs-levent
Copy link

I agree that this would be useful.

I think in general, a tool should allow users to scan any file they want with the proper configuration and without having to modify the source code. Based on the PR you linked @cfabianski, file-size-max and timeout also got hardcoded. This would mean that a user has no option to scan a large file, only by changing the hardcoded values in the source code. While I agree, the size is pretty large, in extreme cases, these large files are missed. This could be especially problematic with legacy codebases, it could happen that there are larger code files than 2MB are kept around in a repository.

Let users decide if they want to scan these large files as well by giving this as an option. So I'd suggest to not have any controls in place without configuration options which in extreme cases would block the tool from scanning some file.

@undergroundwebdesigns
Copy link

I also think #477 should be reverted. I'm in the process of rolling out bearer as a security tool at my workplace, and it's disconcerting to say the least to discover that it can skip security findings with just a debug message due to resource constraints, especially when there's no way to configure it otherwise or increase the timeout / memory limit / etc. Ideally those options would be configurable, but I also think the scan should log a finding if the scan is aborted due to resource constraints so that at least the user knows the scan could not be completed and some findings may not have been detected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants