What is a one sentence summary of your feature request?
Restrict or Monitor Enterprise Code Transfers
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
As of today, users can still copy or move organization source code to personal GitHub repositories or other external platforms without centralized visibility. This creates a significant security and intellectual property risk for product companies.
We request a feature that either:
Restricts organization code from being transferred to personal repositories or external platforms, or
Provides comprehensive monitoring and audit logs showing exactly where the code was copied, pushed, or transferred, including the destination repository/platform, user details, and timestamp.
This capability would greatly improve source code governance, help prevent data exfiltration, and strengthen security and compliance for organizations managing sensitive intellectual property.
How do you currently solve the challenges you have by not having this feature?
Currently, there is no reliable native mechanism to prevent or fully track source code transfers to personal repositories or external platforms. We rely on a combination of repository access controls, branch protection rules, audit logs, code review policies, and periodic monitoring. However, these measures do not provide end-to-end visibility into where organization code is ultimately copied or transferred outside GitHub. As a result, detecting unauthorized code exfiltration is difficult, investigations are time-consuming, and organizations must depend on manual processes
My opinion is that if a DPI feature is added to CAP - GitHub, it seems possible to implement external/internal repositories.
I think it would be an ideal approach to block all GitHub transfers and allow connections only to internal or tusted repositories via DPI Allow Domain.
Currently, Netwrix EPP’s GitHub detection is limited to the “file system” level, so there are many false positive logs, and I do not consider them to be meaningful.
Setup: CAP policy with browsers as exit points; Domain and URL denylist containing github.com and github.com/*; DPI Allowlist containing org-path carve-outs (github.com/``<org>/*, Sign in to GitHub · GitHub , etc.); DPI Monitored URL Categories empty; DPI enabled on the endpoint.
Observed behavior on a single machine, same session:
support.github.comis intercepted and enforced — path-level DestinationBlocked events are logged (e.g. /ticket/personal/0/4579528), and interception is confirmed.
github.comis not intercepted at all — the browser presents GitHub’s original certificate (issuer: Sectigo Public Server Authentication CA DV E36), not our EPP CA (CN 172.31.46.161). Personal repository pages (github.com/``<user>/<repo>) load with no block and generate no log events.
Troubleshooting already performed: EPP CA verified as trusted in the macOS System keychain (security find-certificate confirms); QUIC disabled in Chrome (chrome://flags/#enable-quic → Disabled); Encrypted Client Hello disabled; full browser quit and system reboots between tests; DPI bypass / temporarily allow-listed websites list checked for github entries; behavior reproduced in both Chrome and Safari, so it is not browser-specific.
Questions:
Why would github.com specifically bypass DPI interception while its subdomains are intercepted on the same client and policy? Is there a built-in exclusion, pinning-related bypass, or known issue for github.com on macOS client 2602.x?
Is macOS 26.5 fully supported by client 2602.2.2.0 for DPI?
Does the DPI Allowlist support URL path entries (e.g. github.com/orgname/*) as carve-outs within a denied domain, or is matching domain-level only? If paths are supported, what is the exact required syntax?
There’s no built-in exclusion for github.com, and the agent shouldn’t bypass it under normal conditions. I’ve seen this behavior once before, caused by an old DPI bypass setting that stayed in place on the machine after a config change. Reinstalling the client resolved it.
Client 2602.2.2.0 was released before macOS 26.5, so I can’t confirm full compatibility. In my experience, minor Apple OS updates rarely affect the agent, but if possible, I’d recommend updating to the latest EPP client version (2605.2.2.0) to rule this out.
URL path entries (e.g. github.com/orgname/*) aren’t supported in the DPI Allowlist at the moment. Matching is domain-level only.
If you are still encountering issues after reinstalling the agent, preferably the latest one, I’d suggest collecting debug logs and opening a support ticket for one of engineers to investigate.