Package Management: Vulnerabilities and Licenses
Package Management: Vulnerabilities and Licenses
Sonatype Nexus Firewall uses a quarantine-based approach to managing open-source risk by blocking packages identified as unsafe. ProGet takes a different approach, focusing on vulnerabilities and license issues themselves rather than treating packages as isolated problems.
This article covers:
- limitations of quarantine-based package management
- vulnerability and license governance in ProGet
- configuring vulnerability and license controls
Vulnerabilities and Quarantine-Based Management
Quarantine-based security models are designed to isolate malicious files that are inherently unsafe. Vulnerabilities and license issues behave differently because the underlying risk often depends on package usage, dependency relationships, and organizational policies.
In quarantine-based systems, packages are treated as the primary problem rather than the underlying vulnerability or license issue itself. This creates several limitations:
- the same vulnerability may exist across many packages and transitive dependencies
- vulnerabilities are often discovered after packages have already been downloaded
- blocking one package does not address other affected packages containing the same issue
- already-pulled packages may remain accessible within the registry
License governance introduces similar challenges. Licenses are usage agreements rather than defects in code, meaning compliance issues cannot be resolved simply by quarantining individual packages or versions.
As repositories and dependency chains grow, managing vulnerabilities and licenses effectively requires governance models that evaluate risks across packages, versions, feeds, and dependencies rather than treating packages as isolated events.
Vulnerability and License Management in ProGet
ProGet manages vulnerabilities and licenses through registry-wide and feed-level governance policies.
Packages retrieved through proxied feeds are automatically scanned, and identified vulnerabilities are displayed within the package version’s Vulnerabilities tab. Risk profiles (at the global or feed level) determine how vulnerabilities are evaluated across packages, versions, and dependency chains. This includes assigning a category and deriving an assessment.
Categories classify the type and severity of the issue, while assessments determine how the vulnerability should be handled within the organization.
Assessment types include:
- Monitor
- Remediate
- Contain
Risk profiles can be customized globally or at the feed level to ensure consistent evaluation of vulnerabilities across all affected packages and versions.
Policy enforcement is then applied based on these assessments, ensuring that affected packages are handled consistently across the registry, including packages that have already been stored within feeds.
Licenses are managed through a similar workflow. ProGet detects package licenses and evaluates them against configured compliance policies. Administrators can:
- mark licenses as compliant or non-compliant
- apply registry-wide license restrictions
- configure feed-level exceptions for approved use cases

This allows vulnerability and license governance to remain centralized while still supporting project- or feed-specific requirements.
Vulnerability Assessments and Policies
Known vulnerabilities are displayed within the package’s Vulnerabilities tab, where administrators can review categories, assessments, and policy status.
In ProGet, vulnerabilities are evaluated through risk profiles, which determine the appropriate category and assessment type based on factors such as severity, exploitability, package usage, and organizational policy.

However, you can override assessments on a case-by-case basis to better reflect your environment.

Packages associated with vulnerabilities that violate configured policies are marked as non-compliant, and access to those packages can be restricted based on enforcement rules.

Because assessments apply to the underlying vulnerability itself, enforcement automatically extends across all affected packages and versions containing that vulnerability.
Configuring License Policies
License policies can be configured directly from package versions or through the Policies page.

Licenses can be marked as non-compliant, preventing downloads for packages associated with that license across the registry.

Feed-level exceptions can also be configured to allow approved packages or workflows where needed, giving organizations flexibility while maintaining centralized compliance policies.

Conclusion
ProGet manages vulnerabilities and licenses as registry-wide governance concerns rather than isolated package events.
Through risk profiles, categories, assessments, and feed-level enforcement rules, ProGet applies governance consistently across packages, versions, feeds, and dependency chains, including packages that already exist within the registry.
This approach allows organizations to manage risk proactively while maintaining visibility into dependencies and compliance across the software supply chain.
For more visibility into package dependencies and compliance across your builds, ProGet also supports SBOM generation and management workflows, covered in the next article.
