Am I configuring something wrong? False positives on in-house apps.

I've been evaluating Bitdefender GravityZone for our containerized build environments (Jenkins agents, mostly Docker-based). The goal was to add a layer of security scanning to our CI/CD pipeline before artifacts progress to staging.

However, I'm encountering a significant number of false positives on our in-house developed applications. The alerts primarily flag behavior like "Application.Generic" or "Cloud.Miner" on binaries built from our own Go and Python code. This is causing pipeline failures and requires manual override, which defeats the purpose of automated scanning.

My current configuration in the GravityZone console for the policy applied to these build machines is:

* **Scan Mode:** Balanced
* **Action on detection:** Deny (for CI, we want a hard stop)
* **Advanced Settings:** Cloud-based detection enabled, all scan engines active.

I'm particularly interested in the exclusions system. Has anyone crafted effective exclusion rules for CI/CD workloads that go beyond simple file paths? For instance, is there a reliable way to create a hash-based allowlist for binaries signed by our internal build system, or to exclude processes spawned from a specific parent (like our Jenkins agent JAR)?

The pipeline step is straightforward. A simplified Jenkinsfile stage looks like this:

```groovy
stage('Security Scan') {
agent { docker 'our-app-builder:latest' }
steps {
sh './build.sh' // This produces the binary that gets flagged
archiveArtifacts artifacts: 'output/app.bin'
}
}
```

The detection occurs when the built `app.bin` is executed during its own integration test suite within the same container.

Are these false positives a known challenge with GravityZone in devops contexts? Should I be looking at a different policy template, or is granular tuning of the "Advanced Threat Defense" modules the only path forward? I'm concerned that over-excluding will create a blind spot.