> 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.md).

# Allow and deny lists for dependencies

Allow and deny lists help you control which dependencies your organization accepts or blocks. Fortify SCA and Open Source Select use these lists in automation rules to evaluate dependencies by name, version, or package URL.

Use allow lists to approve known-good components. Use deny lists to block components that your organization does not allow.

#### **How allow and deny lists work** <a href="#howdoallowanddenylistswork" id="howdoallowanddenylistswork"></a>

Allow and deny lists contain dependency entries. Automation rules evaluate dependencies against those entries and apply the configured action.

List entries do not trigger actions by themselves. You must reference the lists from an automation rule for the lists to take effect.

#### **Supported dependency formats** <a href="#whatdependencyformatsaresupported" id="whatdependencyformatsaresupported"></a>

You can define dependency entries in 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 want exact package matching across ecosystems. Use name-based entries when you want broader policy coverage.

#### **Use cases** <a href="#whatusecasesdoesthisfeatureaddress" id="whatusecasesdoesthisfeatureaddress"></a>

This feature supports these governance workflows:

* Block specific components that your organization does not allow.
* Require vetted open-source dependencies in conservative environments.
* Sync 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.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.
