> For the complete documentation index, see [llms.txt](https://docs.debricked.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.debricked.com/product/automation/allow-and-deny-lists-for-dependencies/create-and-manage-dependency-allow-and-deny-lists.md).

# Create and manage dependency allow and deny 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** <a href="#beforeyoustart" id="beforeyoustart"></a>

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** <a href="#createlistentries" id="createlistentries"></a>

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

Example configuration:

```perl
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](/tools-and-integrations/cli/debricked-cli/file-fingerprinting.md).

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** <a href="#referencelistsinautomationrules" id="referencelistsinautomationrules"></a>

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** <a href="#setdependencyscope" id="setdependencyscope"></a>

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** <a href="#manageallowanddenylistsviatheapi" id="manageallowanddenylistsviatheapi"></a>

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** <a href="#usecases" id="usecases"></a>

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.debricked.com/product/automation/allow-and-deny-lists-for-dependencies/create-and-manage-dependency-allow-and-deny-lists.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.