Findings exclusion

Last updated: Oct 27, 2026

Fluid Attacks has the NOFLUID feature. With this feature, you can exclude from reports some lines that are possibly not secure. These lines can be in the source code of your application or in your infrastructure-as-code (IaC) configurations. Thus, you do not get findings that are possibly not related to your context.

The procedure depends on the type of vulnerability that you want to exclude. This page describes the different ways to declare an exclusion and when to use each one.

NOFLUID gives you useful control of scan results, but it is very important to use it responsibly. When you exclude findings, you can hide possible vulnerabilities or incorrect configurations in your code. Always make sure that you fully understand what happens when you exclude a finding. Exclude a finding only when you have a clear justification.

Exclude with comments

To exclude a finding in your code, add the NOFLUID comment to the line before the line that the scanner flagged. Include a short explanation of why you exclude this issue. Example:

import * as CryptoJS from "crypto-js";

function hasCryptoJsFunctions(arg) {
  // NOFLUID This report is irrelevant, controlled variable.
  const Utf16LE = CryptoJS.enc.Utf16LE.parse("a23ijl");
}

You can also use NOFLUID in dependency declaration files with a format that accepts comments. Example:

buildscript {
  ext {
    lombokVersion = '1.18.16'
  }
 }
dependencies {
  // NOFLUID Assumed risk.
  compile "io.springfox:springfox-swagger-ui:2.6.0"
}

Or use it in your IaC configuration file:

resource "test_cluster" "main" {
  cluster_identifier = "test"
  database_name      = "test"
  master_username    = var.clusterUser
  master_password    = var.clusterPass

  cluster_type    = "single-node"
  # NOFLUID The cluster is adequately hardened
  publicly_accessible  = true
  ...
}

After you add the NOFLUID comment, run the static analysis again. Then, the scanner ignores the possible security issue.

Exclude with a configuration file

You can define a .fluidattacks.yaml file at the root of your project for these scans:

• Software composition analysis (SCA). SCA scans files that cannot contain comments, such as package-lock.json or Cargo.lock.
• Static application security testing (SAST) and secrets scanning on files that you do not want to change, such as generated or vendored code.
• Dynamic application security testing (DAST), for URL environments.

In this file, you can specify exclusions for specific advisories, source code locations or endpoints.

The file format is as follows:

sca:
  exclusions:
    - CVE: advisory identifier
      paths:
        - relative/path/to/lock/file

sast:
  exclusions:
    - path: relative/path/to/source/file
      lines:
        - line number

ss:
  exclusions:
    - path: relative/path/to/source/file
      lines:
        - line number

DAST:
  - endpoint: url endpoint
    target_findings:
      - finding_code: short description of the reason to exclude reports from this specific finding

Each entry in sca.exclusions has one advisory identifier (such as CVE or GHSA) and a list of lock file paths. The scanner does not report that advisory in these paths. The scanner excludes the finding only when the advisory and the path match. Thus, if you add a CVE for one path, the scanner continues to report it in other lock files.

Each entry in sast.exclusions has one file path and a list of line numbers in that file. The scanner does not report static analysis findings in these lines. It is an alternative to NOFLUID comments in many files at the same time. You can also use it for files that you cannot edit. The scanner excludes a finding only when the path and the line number match.

Each entry in ss.exclusions has one file path and a list of line numbers in that file. The scanner does not report secrets findings in these lines. Use it for files where the NOFLUID comment is not practical, such as generated or vendored files. It is also an alternative to inline comments in many files at the same time. The scanner excludes a finding only when the path and the line number match.

finding_code is the location of the vulnerability that you want to exclude. You can get it from the output of your previous scan.

Example

sca:
  exclusions:
    - CVE: CVE-2024-21501
      paths:
        - front/package-lock.json
    - CVE: GHSA-2023-0071
      paths:
        - cli/Cargo.lock
        - server/Cargo.lock

sast:
  exclusions:
    - path: src/legacy/crypto_utils.py
      lines:
        - 17
        - 103

ss:
  exclusions:
    - path: src/config/settings.py
      lines:
        - 42
        - 58

DAST:
  - endpoint: myapp.com
    target_findings:
      - f043: not relevant report
      - f086: will upgrade after next release
  - endpoint: web.example.com
    target_findings:
      - f313: certificates are secure enough

In this example:

• The scanner excludes the advisory CVE-2024-21501 only for front/package-lock.json.
• The scanner excludes the advisory GHSA-2023-0071 for cli/Cargo.lock and server/Cargo.lock. If the advisory is in other lock files, the scanner continues to report it.
• The scanner does not report static analysis findings in lines 17 and 103 of src/legacy/crypto_utils.py.
• The scanner does not report secrets scanning findings in lines 42 and 58 of src/config/settings.py.
• The scanner excludes the vulnerability types f043 and f086 for the myapp.com endpoint and the type f313 for the web.example.com endpoint.

Exclude with tags in your AWS resources

To exclude a finding on your AWS resources, add a tag to the resource with the possible vulnerability. The key of the tag must be NOFLUID. The value must include the reason for the exclusion and the code of the weakness, in this format:

<finding_code>.<finding_code>..._<reason>

This screenshot shows an example:

To read exclusion tags from your resources, the IAM role that the Fluid Attacks scanner assumes must have these permissions:

• iam:ListUsers
• iam:ListUserTags
• iam:ListRoles
• iam:ListRoleTags
• tag:GetResources

You can define exclusion tags directly in your IaC templates (for example, Terraform or CloudFormation). This is especially useful for resources with a short life, because the tags are added automatically.

This is an example:

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  tags = {
    Name    = "test"
    NOFLUID = "f001.f002_non_relevant"
  }
}