Create and manage dependency allow and deny lists

Create and manage lists

Use dependency allow and deny lists to define approved and blocked dependencies and then reference those lists in automation rules.

This topic explains how you add list entries, set dependency scope, and update lists through the API.

Before you start

Before you create dependency lists, make sure that:

• You can edit the configuration file used by your automation rules.

• You know which dependencies you want to allow or block.

• You know whether you want to evaluate direct dependencies only or direct and transitive dependencies.

Create list entries

Add dependency entries to the allow or deny section in your debricked-config.yaml configuration file.

Example configuration:

policies:
  allow:
    packages:
      - "lodash"                   # Name
      - "pkg:npm/lodash@4.17.21"   # PURL
      - "lodash=4.17.21"           # Exact version
      - "lodash>=4.17.21"          # Single constraint
      - "lodash>=4.17.21 <=5.3.4"  # Range
  deny:
    packages:
      - "n8n" 

For more information about debricked-config.yaml configuration file, see the Manage or override results section in File fingerprinting.

A list entry can use one of these formats:

Format	Example	Match behavior
PURL	pkg:npm/lodash@4.17.21	Matches one exact package and version
Name only	lodash	Matches all versions and package managers for that dependency name
Name and version	lodash@4.17.21	Matches one exact name and version
Name and version range	lodash@>=4.0.0	Matches versions that fall within the range

Use PURL when you need exact matching. Use name-only format when you want broader coverage.

Reference lists in automation rules

After you define the lists, create automation rules that evaluate dependencies against them.

To create a rule:

1. Open Automation.

2. Select Create rule.

3. Choose a dependency condition.

4. Select whether the dependency is in an allow list or deny list.

5. Choose the target list.

6. Select the action.

7. Save the rule.

Example rule patterns:

• If dependency is in deny list, then fail the check.

• If dependency is not in allow list, then mark the repository as non-compliant.

• If dependency is in allow list, then continue the workflow.

Set dependency scope

Automation rules support two dependency scope modes:

• Direct and transitive dependencies

• Direct-only dependencies

Use direct-only dependencies when you want to control only components added directly by the project. Use direct and transitive dependencies when you want full supply chain coverage.

Manage allow and deny lists through the API

You can update dependency lists through the API when you want to sync external approval data or manage lists at scale.

A typical workflow is:

1. Export approval or block data from an external system.

2. Convert the data to a supported dependency format.

3. Update the allow or deny list through the API.

4. Run automation evaluation.

5. Review the result in Fortify SCA or Open Source Select.

This workflow supports integrations such as Sonatype Firewall approval data and other component governance systems.

Use cases

Dependency allow and deny lists support these workflows:

• Block specific components that your organization does not allow.

• Require vetted open-source dependencies in conservative environments.

• Reuse component approval data from external systems.

• Reduce rule duplication by managing many components in shared lists.