Why Gateway cannot inspect package traffic without decrypting TLS
Package downloads usually look like ordinary HTTPS traffic until the proxy can read the HTTP request. Gateway identifies the registry protocol from the request URL, then extracts package coordinates from the request path and metadata. If TLS stays intact end to end, those fields remain hidden.
That matters across developer laptops and CI/CD jobs alike. A policy that never sees the package name or version cannot block a bad release, pin a safe one, or treat one registry path differently from another. The traffic may still flow, but it is opaque to package-aware policy.
This is also why hostname checks are too blunt on their own. The registry protocol is what Gateway uses, not just the site name. A single registry host can carry many package paths, and the useful control sits inside the request, not at the outside of the connection.
The package fields Gateway can actually see after decryption
Once TLS is decrypted, Gateway can work with package-aware selectors. The useful ones are pkg.ecosystem, pkg.name, pkg.version, and pkg.namespace. That gives enough detail to separate a whole package family from a single release, which is the point of doing this in the first place.
Ecosystem, name, version, and namespace are the useful selectors
The supported ecosystems include npm, PyPI, RubyGems, Cargo, Go, Maven, and NuGet. For npm, the namespace is the scope, such as @babel. For Maven, it is the group ID. For Go, it is the module path. pkg.namespace only appears where the ecosystem has a namespace to expose, so it is not something to assume will exist everywhere.
pkg.version is the sharpest part of the set when a policy needs to allow one release and block another. That is the difference between blanket registry blocking and a rule that follows the supply chain path more closely. Gateway also supports Allow and Block actions with these selectors, which makes the policy readable without making it gentle.
PURL stays in the API, which matters if you script policy
pkg.purl is the Package URL derived from the detected coordinates, but it is API-only. That matters if policy is generated or checked by automation, because the dashboard view is not the whole story. If a script expects to use PURL, it needs to work through the API, not the console.
Nested package fields also depend on selecting a single ecosystem first. That is a practical limitation, not a cosmetic one. Broad rules are easier to write, but they are less precise, and precision is the whole reason package-aware inspection exists.
Where the policy boundary sits in Artifactory, Nexus, and self-hosted mirrors
Gateway can match package traffic that passes through public registries, Artifactory, Nexus, and self-hosted mirrors. The control point still sits at decryption. If the registry traffic is encrypted in a way Gateway cannot inspect, the package selectors never come into play.
That matters in mirrored or private registry setups, where the host can look familiar and the path can still be different. A mirror may hide the package source behind the same HTTPS front door, but Gateway still needs decrypted HTTP to read the registry protocol and coordinates. Without that, the policy boundary is outside the content and therefore too coarse to be useful.
For private registries, the sensible default is simple: turn on TLS decryption, then write the package rules. If decryption is left off, the policy may still match some broad web traffic, but package registry security will not do its job.
Turn decryption on, then verify the registry traffic is being matched
Turn TLS decryption on before relying on any pkg.* selector. Then test with known package downloads from the ecosystems you care about, and check that the requests are actually being matched as package traffic rather than plain HTTPS. If nothing is matching, the rule is not wrong enough to be interesting, the proxy just cannot see the content.
Use one narrow allow rule and one block rule as a test case. Pick a single ecosystem, a known package name, and a version that you can distinguish easily. If the traffic only matches after decryption is active, the control boundary is where it should be.
