Configure Netskope for PTC

Netskope Configuration Guide

Netskope is one of the SASE solutions supported by Package Traffic Controller (PTC). Like Zscaler ZIA, Netskope SSL-inspects matching public registry traffic and redirects it to your Artifactory /package-reroute endpoint, so policy checks and logging happen in one governed path. Netskope owns the Security Cloud portal navigation and labels, which can vary by tenant and release—use this as a workflow guide and confirm exact options in Netskope's documentation.

Complete Configure Artifactory for PTC before proceeding, and review Configure SASE for PTC for how shared and vendor-specific setup fit together.

All Netskope configuration is performed in the Netskope Security Cloud portal under Policies → Profiles and Policies → Real-time Protection.

Netskope Requirements

• Netskope client: Install the Netskope client on each developer workstation. On macOS, allow Full Disk Access and enable the Endpoint Security Extensions for Netskope.
• Certificate: The Netskope client installs its CA certificate. Some Python-based clients require a certificate that includes the required critical extensions—see Known Limitations.
• Workstation trust and install-script requirements are shared across SASE; see Prerequisites and Installation Script.

The integration is three Netskope steps: create a Destination Profile, create an HTTP Header Profile, and create a Real-time Protection policy that redirects matching traffic to Artifactory.

Complete the following procedures in order (after Configure Artifactory for PTC):

• Step 1: Create a Destination Profile
• Step 2: Create an HTTP Header Profile
• Step 3: Create a Real-time Protection Policy

Step 1: Create a Destination Profile

A destination profile defines the public registry domains Netskope should intercept. Create a separate profile per ecosystem (rather than one combined profile) so you can manage and roll out each package type independently.

To create a destination profile for PTC:

1. Navigate to Policies > Profiles > Destination.
2. Click New Destination Profile.
3. Destination Profile Name: Enter a descriptive name, for example jfrog-npm.
4. Match Type: Select Exact (Case Insensitive) for explicit domains, or RegEx if you need pattern matching.
5. Definition: Enter the registry domains for the ecosystem, one per line.
6. Click Save.

Use the domains for each ecosystem you enable (align with Supported Package Types (GA)):

The destination profile is ready to attach to a real-time protection policy.

Split per ecosystem: Avoid putting all registries in a single profile (for example registry.npmjs.org, registry.yarnpkg.com, pypi.org, files.pythonhosted.org together). Separate npm and Python profiles let you scope and roll out each package type independently.

Step 2: Create an HTTP Header Profile

An HTTP header profile identifies browser traffic. The real-time protection policy then lets browser visits to a registry domain pass through to the website, while rerouting all other (package-manager / CLI) traffic to those domains to Artifactory. This mirrors the Zscaler approach of redirecting only non-browser traffic, and avoids breaking registries that also serve a website on the same domain.

To create the HTTP header profile for PTC:

1. Navigate to Policies > Profiles > HTTP Header.
2. Click New HTTP Header Profile.
3. Name: Enter a descriptive name, for example jfrog-browsers.
4. On the Request tab, match browser user agents:
   • Host: Use RegEx .+ (host scope is already handled by the destination profile), or a specific registry domain.
   • User-Agent: Add a RegEx that matches browsers, for example Mozilla.*. Browsers send a Mozilla-based user agent; package managers such as npm, pip, and uv do not, so they fall outside this match and are rerouted.
5. Click Save.

All header fields are AND'ed together, and all values within a single field are OR'ed together.

Why match browsers: some registries serve their public website on the same domain used by the package manager. Matching browser user agents lets the policy pass those browser visits through to the site and reroute everything else (terminal/IDE package-manager traffic) to Artifactory. Confirm the exact browser user-agent values against the traffic you observe in your environment.

Step 3: Create a Real-time Protection Policy

Create two web access policies for the destination profile: one that lets browser traffic pass through, and one that redirects everything else to Artifactory. Order the allow rule above the redirect rule so browser traffic is matched first. For a pilot, scope the source to your own user first.

1. Allow browser traffic (pass-through):

1. Navigate to Policies > Real-time Protection and create a web access policy.
2. Source: the users or groups in scope, plus the browser HTTP Header profile created in Step 2.
3. Destination: the Destination Profile created in Step 1.
4. Action: Allow. Browser visits to the registry websites pass through to the public site normally.

2. Redirect all other traffic:

1. Create a second web access policy, ordered below the allow rule.
2. Source: the same users or groups in scope (no HTTP header profile, so it matches the remaining non-browser traffic).
3. Destination: the same Destination Profile.
4. Profile & Action: Set Action to Redirect, and enter the redirect URL:

https://<YOUR_ARTIFACTORY_URL>/package-reroute?url={{cs-uri-scheme}}://{{cs-host}}{{x-cs-uri-path}}&user=

5. Save and apply. Allow a few minutes for the policy to propagate.

Where:

• <YOUR_ARTIFACTORY_URL>: Your JFrog Platform hostname (for example acme.jfrog.io)
• {{cs-uri-scheme}}://{{cs-host}}{{x-cs-uri-path}}: Netskope variables that reconstruct the original request URL, passed as the percent-decoded url parameter
• &user=: Currently sent empty—see Known Limitations

Avoid redirect loops: The redirect URL must not be the same as the source URL, or Netskope will create an infinite loop. The Artifactory /package-reroute host should be excluded from this policy's destination scope.

Matching package-manager traffic is now redirected to your Artifactory /package-reroute endpoint, which resolves the request through the configured remote repository.

Scope of Support

Netskope PTC targets the public native registry for each package type (for example registry.npmjs.org for npm, pypi.org/files.pythonhosted.org for Python, registry-1.docker.io for Docker, huggingface.co for Hugging Face)—not private repositories. Each supported package type ships its own Netskope destination, header, and policy configuration. Add ecosystems as you roll them out, aligned with Supported Package Types (GA).

Known Limitations

• Certificate critical requirement (Hugging Face and Poetry): Python uses strict (RFC 5280) certificate verification. If the SASE CA certificate does not include the required critical flag / key-usage extension, Hugging Face and Poetry installs fail through Netskope. pip, uv, npm, and yarn are unaffected. Use a CA certificate that includes the required critical extensions. See also Limitations and Troubleshooting.
• Per-user audit (user= is empty): Netskope does not currently populate the user identity into the redirect, so the &user= parameter is sent empty and Artifactory logs do not attribute the request to a specific user. This is an audit nice-to-have, not a blocker for redirect, proxy, and Curation.

Frequently Asked Questions

This section provides answers to frequently asked questions about configuring Netskope for Package Traffic Controller (PTC).

Related Topics

• Package Traffic Controller (PTC) overview
• Configure SASE for PTC
• Configure Artifactory for PTC
• Configure Zscaler ZIA
• Limitations and Troubleshooting