Help: Netskope's 'Insider Threat' alerts are 90% false positives from our devs using Git.

Yeah, we saw the same thing during our trial. The Git stuff set off everything because of the data patterns in commits.

We got our security team to exempt certain IPs for our dev subnet from the high-risk data movement alerts. Also, we made a custom DLP profile that excludes common dev file types like .java and .py from the "source code" policy. That cut down the noise a lot.

Did you try setting up a test policy for a single dev team first? Might be easier to tune.

That sounds really frustrating. We're only just starting with Docker and our team is small, but I can imagine the alert fatigue is real.

The custom DLP profile idea that was mentioned for common dev file types seems smart. Did you find it tricky to define what "normal" Git activity looks like for your policies? Like, would a bulk clone of a new repo still get flagged?

Thanks for sharing this, it's helpful to see what to watch out for.

Totally get where you're coming from with a small team. The >define what "normal" Git activity looks like part is exactly where I'd get stuck too. From what I've read, the volume of data moved during a bulk clone could still look suspicious if the policy is just about data transfer size, right? Maybe you need a separate rule for allowed destinations like your internal GitLab server.

Did the person who mentioned exempting dev IPs have to whitelist public GitHub as well, or is that considered too risky?

You've hit on a classic problem where generic data loss policies conflict with legitimate development workflows. The core issue is that most insider threat models treat any high-volume data movement to an external cloud service as suspicious, which is exactly what `git push` and `git clone` are.

Instead of blanket IP exemptions, I'd suggest a more nuanced approach using Netskope's contextual attributes. Create a policy rule that combines user group (e.g., "engineering") with the specific SaaS application instance (your corporate GitHub/GitLab URL) and a protocol filter for git-related traffic (SSH on port 22, HTTPS on 443 to those destinations). This allows normal Git operations while still catching a developer exfiltrating to a personal repository.

The custom DLP profile for source code extensions (.java, .py) is a good start, but you must also exclude the `/.git/` directory path to prevent alerts on internal object storage transfers. A study from the 2021 USENIX Security Symposium on "Operationalizing Insider Threat Detection" found that filtering on directory structure reduced false positives by over 70% in dev environments compared to file-type alone.

Have you examined the exact alert types? Are they "High-Risk Data Movement" or "Anomalous Upload Volume"? The tuning strategy differs significantly.

>Did the person who mentioned exempting dev IPs have to whitelist public GitHub as well

That's the million-dollar question. Whitelisting the entire `github.com` domain is too risky in my book - a dev could push to a personal repo just as easily as the corporate one. The IP exemption approach is a bit blunt.

For public GitHub/GitLab, we got better results by using the *instance* feature in Netskope. You can whitelist your organization's specific URL (e.g., `github.com/YourCompany`) rather than the whole service. This still lets you monitor for traffic to other instances. It's not perfect, but it's more precise than an IP range.

On bulk clones looking suspicious, you're right. If your policy triggers on data volume alone, a fresh clone will set it off. We added a time-of-day factor (e.g., lower sensitivity during work hours) for our engineering group as a temporary fix, but it's a band-aid. A better rule really does need to account for the destination being your known, approved repo.

Good point on whitelisting just your organization's instance. That's definitely a more surgical approach than a full domain exemption.

Your mention of the time-of-day band-aid is interesting. We've seen teams adopt similar temporary measures, but it often just shifts the alert fatigue to after-hours reviews. It feels like a policy based on the specific, sanctioned repository URL is the more sustainable fix, even if it takes more initial setup.

You're hitting the classic problem of behavioral policies misinterpreting high-volume, authorized data movement. The crux is that `git push` to a sanctioned repository *is* normal data movement, not an exfiltration attempt.

The solution involves layering context, not just IPs or domains. You need a policy rule that combines:
- The user's group (e.g., "Development")
- The specific, sanctioned SaaS instance (`github.com/YourOrg`, `gitlab.yourcompany.com`)
- The protocol/port (SSH 22, HTTPS 443)
- An activity type that excludes "clone" and "pull" operations if volume-based alerts are the main culprit

This carves out a safe corridor for legitimate Git workflows. You can then keep stricter, volume-based DLP policies active for traffic to other instances, like a developer's personal GitHub account.

Agreed, layering context is the only way it works. Your list is spot on.

Don't forget to also exclude your build/CI systems from the "user" context. Our Jenkins agents triggered a ton of alerts before we added a service account group to the safe rule. Their git fetches look identical to a bulk exfiltration.

Oh man, I feel you on the alert fatigue. We're just starting to look at Netskope too, and this exact scenario is my biggest fear. My team would revolt if every git push became a security incident.

The layered context idea from the later posts seems like the right direction, but setting that up feels daunting for someone new. When you tried making those custom DLP profiles for dev file types, was it a long process to get the right file extensions? I'm worried I'd miss something like .ts or .jsx and just create a different alert flood.