Skip to main content
Corgea uses AI to analyze potential vulnerabilities and determine if they are likely to be false positives. The false positive analysis considers various factors, such as the context of the code, the nature of the vulnerability, and any relevant coding patterns or best practices. The model then provides a result indicating whether the vulnerability is likely to be “valid” or a “false positive”, along with a reasoning explaining its assessment. When the model determines that a vulnerability is a false positive, the reasoning provides an explanation for this assessment. By providing this false positive analysis alongside the vulnerability explanation and proposed fix, Corgea aims to help developers quickly identify and prioritize genuine vulnerabilities while avoiding unnecessary effort on false positives.

​
Marking a finding as a false positive

When marking a finding as a false positive, provide a meaningful explanation of why it is not a real vulnerability, such as unreachable code, sanitized input, or code used only in tests. A label such as “false positive” or filler such as “N/A” is not enough. This applies to individual findings, bulk decisions, and requests made through pull request comments. If your explanation is rejected, add the missing context and try again. These are a sample of some of the false positives that Corgea can detect:
  • Cross-Site Scripting: Checks if user input is properly sanitized or encoded before being reflected in the webpage using established libraries or frameworks.
  • SQL Injection: Checks if database queries use fully sanitized parameterized statements or prepared statements in a best-practice manner, without including any user-provided or external input that could be manipulated.
  • Information Exposure: Checks if the sensitive information disclosed is generic or occurs in a development environment.
  • Uncaught Exception: Checks if the unexpected condition or status is handled through alternative means like logging or monitoring in non-critical parts of the application.
  • Hard-Coded Password: Checks if the hard-coded password is intended for a non-production environment or used for automated testing.
  • Password in Configuration File: Checks if the storage of the plaintext password is protected through alternative security measures like encrypted storage or access controls.
  • Hard-Coded Cryptographic Key: Checks if the hard-coded cryptographic key is used for testing purposes only.
  • Cross-Site Request Forgery: Checks if anti-CSRF tokens are implemented and validated on the server-side, or if the code is an API where CSRF protection is not applicable.
  • Missing Support for Integrity Check: Checks if the integrity check is implemented through alternative means like digital signatures or hash validations.
  • Hard-Coded Credentials: Checks if the hard-coded credentials are used for testing purposes only.
  • Code Injection: Checks if the code injection point is limited to a controlled environment or if input validation and output encoding are applied.
And many more…