Skip to main content

Automatic Quarantine Release

You may configure quarantined components to be automatically released when components no longer have failing violations for certain policy condition types. Auto-release monitors components that have been quarantined in the last 14 days. When new information resolves the policy violation that caused the quarantine, the component is automatically released from quarantine.

Auto-Release Dashboard

The Auto Release Dashboard displays an activity summary and components that have been auto-released from quarantine. This view is accessed from the Firewall Dashboard. These results will not include components that have been manually released from quarantine.

Auto-Release_Dashboard.png

Auto-Release Activity Summary

The auto-release quarantine dashboard displays information pertinent to auto-released components and shows the repository configurations. The dashboard includes:

Table 4. Activity Summary

Auto Released (Month to Date)

Components auto-released from quarantine in the current month

Auto Released (Year to Date)

Components auto-released from quarantine in the current year

Auto Release from Quarantine Status

Summary and configuration of policy condition types enabled for auto release from quarantine.



Auto-Release Component View

The auto-release quarantine results contain repository components across all repositories that were auto-released from quarantine. The results are navigated using page controls to load different results. The results are comprised of:

  • Component - The component quarantined in a repository

  • Quarantine Date - The date the component was quarantined

  • Repository - Repository the component belongs to

  • Date Cleared - The date the component was automatically released from quarantine

Clicking on a row of the table will display the Component Information Panel for that component. Clicking on the Refresh button on the top of the table will refresh the results and will respect any filtering or sorting already applied to the results.

Manually Trigger Automatic

The Re-Evaluate Repository option in the Repository Results screen will trigger the automatic quarantine release. This will release all components eligible for Automatic Release - not only components blocked by release integrity.

Auto Release from Quarantine Configuration

The configuration for auto-releasing quarantined components is found on the Firewall dashboard under View auto-release components > Auto Release from Quarantine window. Select Configure from the right side of the display.

Screenshot_2024-02-07_at_1_21_30_PM.png

Modifying the auto-release functionality requires the Edit IQ Elements permission set at Orgs and Policies > Repository Managers access level.

Screenshot_2024-02-07_at_11_20_29_AM.png

Policy Condition Types Supporting Auto Release

Policy violations are triggered by specific conditions defined in the policy. The condition types are used to correlate to component information.

The policy condition types that can be enabled for monitoring with auto-release from quarantine are:

  • Integrity Rating (Enabled by default)

  • License

  • License Threat Group

  • Match State

  • Security Vulnerability Severity

  • Security Vulnerability Category

  • Security Vulnerability Custom Remediation

  • Security Vulnerability Custom CVSS

  • Security Research Type

Learn more about policy types from the policy documentation.

Auto Releasing Components

Auto release of a quarantined component occurs when the component data changes, within a reasonable time frame, which clears all policy violations that caused the quarantine. Once there are no longer any violations keeping the component in quarantine, the component is automatically released from quarantine without user intervention. This allows the component to be consumed from the underlying repository.

The short time frame of the data change is a prerequisite for a component to be automatically released. Suppose a component remains in quarantine for an extended period. In that case, the value of releasing that component drops dramatically, since a different component is probably in place, or the component isn’t required.

The component information having a higher likelihood of being changed in a reasonable time frame are license and security information. Further research can result in the component data being updated, whereby the initial quarantined policy violations would be cleared.

Note

Repository components are checked for changes to policy violations on a nightly basis. They will be automatically released if no violations exist. Auto release from quarantine only evaluates components that have been quarantined in the past 2 weeks on a nightly basis.

The auto-release task runs hourly by default. The schedule interval can be configured using the following property of Configuration REST API.

automaticQuarantineReleaseTimeIntervalInMinutes

Block Unknown Components

Sonatype's data service continuously learns the identity of components as they are uploaded to public repositories by the community. There is a brief window when new components have just been added and Sonatype data services has not yet learned about them.

To protect your infrastructure from using them before they are analyzed for risk, Repository Firewall can quarantine the unknown components and auto-release them once they have been reviewed.

The Repository Firewall can block components with an unknown Match State and auto-release them once they're identified. This is recommended for npm and PyPi.

You will need to add or use the default policy for Unknown Components to enable this behavior.

  • Create a policy with the condition: Match State is Unknown

    policy condition match state
  • Add a condition to restrict this behavior to npm and PyPi the condition: Component Format is npm/PyPI

    policy condition component format configuration
  • Set the Actions field to Fail at the proxy stage

Adding the Component-Unknown-Release-Integrity policy

Policy Name

Component-Unknown-Release-Integrity

Threat Level

8 Critical

Constraints

Add a constraint for each supported format.

Set 'all' for the conditions.

Set condition to Format is npm

Set condition to Match State is Unknown

Set condition to Proprietary is false

Set condition to Data Source has support for identity

Set condition to Format is pypi

Set condition to Match State is Unknown

Set condition to Proprietary is false

Set condition to Data Source has support for identity

Actions

Set the 'Action' for the 'Proxy' stage to 'Fail'