Blocking vulnerable downloads

A per-tenant policy that refuses to serve package versions carrying open malicious or high and critical vulnerabilities.

Download blocking is a per-tenant policy of the Seal Artifact Server. When it is enabled for your tenant, the server refuses to serve a requested package version that carries an open vulnerability matching the policy, and returns an error to the build instead of the artifact.

There are two independent policies:

• Malicious: blocks any version Seal has flagged as malicious.

• High and critical: blocks any version whose highest open vulnerability scores 7.0 or above, which is the same severity score the Seal Platform shows for that version.

Each policy is a tenant-wide setting, not a per-build choice. Both are opt-in and off by default, and they can be enabled separately. Contact your Seal account team to enable either policy for your tenant.

This page assumes your package manager is already pointed at the Seal Artifact Server. See Configuring package managers for the basic setup.

What the build sees

A blocked download fails with HTTP 400 and a plain-text body naming the package version and the reason:

blocked by your organization's Seal security policy: ejs@2.7.4 has an open critical vulnerability

The reason is malicious, critical, or high. When both policies are enabled and a version matches both, it is reported as malicious.

How much of that reaches the developer depends on the package manager. Some clients print the response body, some print only the HTTP status, and some report the failure as a generic download or resolution error. When the message is not visible, run the build with the client's verbose flag, or look up the package version in the Seal Platform to see its open vulnerabilities.

Where the block applies

The block lands on the request for the concrete artifact, not on resolution. Metadata and index responses are unaffected, so a blocked version still appears in the npm packument, the PEP 503 index, maven-metadata.xml, the RubyGems compact index, and the NuGet registration. The build resolves the version as usual and then fails when it fetches the file.

Download blocking currently applies to these ecosystems:

Ecosystem	Blocked request
npm	the package tarball
Python	the file download served from the PEP 503 index
Maven	the artifact request
NuGet	the .nupkg download
Go	the module .zip. The .info, .mod, and @latest endpoints are not blocked
RubyGems	the .gem download

Composer, RPM, DEB, and APK are not covered yet.

What is not blocked

• Versions with no matching open vulnerability. A version whose open vulnerabilities are all below 7.0, and which is not flagged as malicious, is served normally.

• Sealed versions that resolve the vulnerability. A sealed version is only blocked when it still carries an open vulnerability of its own. A vulnerability Seal has already sealed in that version does not trigger the policy, so replacing a blocked origin version with its sealed version is the way to unblock the build.

• Versions Seal has no record of. If Seal holds no vulnerability data for the requested version, the download proceeds.

Related

• Transparent safest relocation: the per-tenant mode that serves the safest sealed version for a plain origin-version request.

• Editing dependency files: pinning a sealed version in your manifest to replace a blocked origin version.

• Configuring package managers: pointing your package manager at the Seal Artifact Server.