Technical Tip: How FortiCNAPP code security handles exceptions across pull requests

Key concepts:

FortiCNAPP Code Security supports several exception types:

• File path-based exceptions: Exclude all findings in a specific file path.
• Instance exceptions: Exclude a specific finding, such as a particular SAST weakness or SCA CVE instance.
• Policy exceptions (Infrastructure as Code): Disable a policy across all repositories or specified repository groups.
• Pipeline-based scan exceptions: Scoped to recent CI/CD scans for a given repository.

Exceptions are scoped per repository. An exception created for one repository does not affect other repositories.

SCA exceptions are tied to CVE identifiers within a given repository.

SAST exceptions are tied to specific code weaknesses (rules/CWEs), and optionally file paths and locations.

Once an exception is configured, matching findings are not included in subsequent scans for that repository, including scans triggered by new pull requests.

For additional background, refer to the Exception management.

Core behavior:

If a new finding matches the scope of an existing exception (same repository and same exception criteria), it will not be reported again in future pull requests.

If the new finding is outside the scope of that exception (different repository, different file, different weakness type, or different CVE), it will be reported as a new issue.

The behavior differs slightly between SCA vulnerabilities (CVEs) and SAST weaknesses.

Behavior for SCA Vulnerabilities (CVEs):

SCA exceptions are per-repository and per-CVE-identifier.

If an exception is created for a specific CVE in a repository (marked as Accepted risk, False positive, Compensating controls, or Patch incoming), any future occurrences of that same CVE in the same repository will be suppressed in subsequent scans, including new commits, branches, and pull requests.

If the same CVE appears in a different repository, it will not be covered by the exception and will be reported.

Example:

• CVE-2023-11111 is marked as an accepted risk in repo-a.
• A new pull request in repo-a introduces another dependency affected by CVE-2023-11111. The CVE will not be reported again in repo-a.
• If repo-b introduces CVE-2023-11111 for the first time, the CVE will be reported in repo-b.

Behavior for SAST code weaknesses:

SAST exceptions can be file path-based (all SAST findings in that file for the given scanner) or instance-based (a specific weakness at a specific location in the file).

The exception applies if the repository and exception criteria match (file path and/or specific instance).

The same weakness in another repository will not be affected by the exception and will be reported.

If a specific weakness instance or file path is excluded in fileA, the same weakness pattern appearing in another file (e.g., fileB) is treated as a new issue and will be reported.

Exceptions are applied at the level of the specific weakness/rule, not all security issues in a file, unless a file path-based exception is created.

If an exception is created for a specific SAST finding (same file path, same rule/weakness, same code location), and a new pull request keeps or reintroduces that exact same code issue in that location, the exception will still match, and the issue will not be reported again.

If the same weakness type appears elsewhere in the same file, behavior depends on how the exception was defined:
File path-based exception: All SAST findings in that file will be suppressed in future scans.
Instance-based exception: Only the original instance (location) is suppressed. A new instance in a different location in the same file is treated as a new issue and will be reported.

Practical examples:

Example 1 – SCA CVE across pull requests in the same repository.

• A dependency in repo-a has CVE-2023-22222.
• The team marks this CVE as an Accepted risk for repo-a.
• A later pull request introduces another library version with the same CVE.

Result: The CVE is not reported again in repo-a.

Example 2 – SAST weakness in a single file.

• A SAST scan finds an unsafe SQL query in src/user_service.py line 120.
• An instance exception is created.
• A later pull request does not change that line; the same unsafe query is still present.

Result: The finding at line 120 remains suppressed in subsequent scans and pull requests.

If another unsafe SQL query is added at line 200 in the same file:

• If the exception was instance-based: The new weakness at line 200 will be reported.
• If the exception was file path-based: The new weakness at line 200 will be suppressed.

Example 3 – Same weakness type, different file.

• A SAST weakness (e.g., shell injection) is excepted in scripts/maintenance.sh.
• A new pull request introduces the same shell injection pattern in scripts/deploy.sh.

Result: The weakness in scripts/deploy.sh will be reported.

Common issues:

• A finding marked as a false positive will not reappear as long as it is in the same repository and matches the scope of the exception (same CVE, or the same SAST instance/file path and weakness). If the finding appears in a different repository, file, or as a different weakness type, it is treated as a new finding.

• Exceptions are applied per repository. A CVE or weakness excepted in one repository does not automatically suppress the same issue in another repository.

• Exceptions remain active for all future pull requests. New findings that match the exception criteria are suppressed in new commits, branches, and pull request-based scans.

• Exceptions can be reviewed and managed in Code security -> Exceptions and Code security -> Infrastructure (IaC) -> Violations (for IaC/policy-related exceptions). The interface displays exception value and criteria, repository and scanner type, reason and comments, and suppressed vulnerabilities and scan details.

For further details, refer to Exception management.

Summary.

• SCA (CVE) exceptions are per-repository and per-CVE. Once excepted, that CVE will not be reported again in the same repository, including in future pull requests.
• SAST weakness exceptions are scoped to file paths and/or specific instances in a repository.
• File path-based: suppress all SAST findings in that file.
• Instance-based: suppress only that specific weakness instance; new occurrences in other files or locations are still reported.
• Across pull requests: If a new pull request introduces a finding that matches an existing exception, it will be suppressed. If it is outside the exception’s scope, it will be reported as a new issue.