Skip to main content

XSOAR Dependency Graph

Python package

XSOAR Dependency Graph is a Python utility to create a dependency graph of either an entire content repository or a single content pack.

Requirements

In order to create a dependency graph for you content, you need the content to be in Content Packs Structure. It is highly recommended to use a content repository similar to content-ci-cd-template as you probably want to use demisto-sdk to interact with or create content at some point.

Usage

This package is not meant to be consumed directly. Its primay purpose is to support functionality in xsoar-cli

Installation

Install with uv or pip. TODO: add better installation docs here.

How is the content graph constructed

The content repository path given as a constructor argument is analyzed. For each content pack, the following items are evaluated (in order):

  1. The Content Pack itself is added as a graph node
  2. Playbooks are added as nodes. Playbooks are parsed and nodes and edges are added for any script or playbook reference found.
  3. Layouts are added as nodes. Layouts are parsed and nodes and edges are added when they are found for e.g dynamic sections or buttons.
  4. Incident Types are added as nodes. Layouts are parsed and nodes and edges are added for script or playbook references.
  5. Integrations are added as nodes. The integrations are parsed and every command defined in the integration is added as graph nodes. Integration code as such is not yet parsed.
  6. Scripts are added as nodes. If there is no path between Content Pack (1) and script then an edge is created from Content Pack node to script node. The scripts themselves are parsed as an Abstract Syntax Tree. When calls to execute_command or demisto.executeCommand are found, the scripts being called are added as graph nodesth an edge back to the calling script.

I can create a content graph with demisto-sdk, so how does this differ?

I have a slightly different opinion on how the content graph should be constructed. One example is I don't want all content items in a content pack to have an edge back to the content graph as such. I also want edges between scripts so that I can easily see exactly which other scripts a script is dependent upon and not only a dependency back to the content pack. Furthermore, demisto-sdk will do all sorts of validation of content which I don't care about. If you have weird docker image definitions in your content that's your business. I also prefer to plot my graphs with matplotlib initially. Unlike demisto-sdk, I don't care about visualizing the graphs in Neo4j. I would much rather export (this feature is not yet implemented) the finished graph to a format Neo4j can read, so that people can decide for themselves how they would like the graphs to be used.

Metadata

Release files for xsoar-dependency-graph 0.4.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for xsoar-dependency-graph 0.4.0
File Size Uploaded
xsoar_dependency_graph-0.4.0.tar.gz 59.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for xsoar-dependency-graph 0.4.0
File Interpreter ABI Platform
xsoar_dependency_graph-0.4.0-py2.py3-none-any.whl Python 2, Python 3 none any Details

Total release size: 78.6 kB

Release files / xsoar_dependency_graph-0.4.0.tar.gz

Download URL xsoar_dependency_graph-0.4.0.tar.gz
Size 59.8 kB
Tags Source
SHA-256 checksum
How to use checksums
88172b50131de0f0c5db4c38df6e1734794c20d07edf3a7cb0f7d080ef0884a7
BLAKE2b-256 checksum
How to use checksums
706140e69a6ae8be1011027aff780ebbebaacdd0f5987a8232ab7257b1dd3af0
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 3, 2026.

Transparency log

Release files / xsoar_dependency_graph-0.4.0-py2.py3-none-any.whl

Download URL xsoar_dependency_graph-0.4.0-py2.py3-none-any.whl
Size 18.8 kB
Tags Python 2 Python 3
SHA-256 checksum
How to use checksums
6bbb380be20558dbbe72897994b92988450f64ff1e218af5b3291c806b599694
BLAKE2b-256 checksum
How to use checksums
3069b04a8c097c3442262e09c3df0de718e7f226341834a9811e39797a3fd4f8
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 3, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.0 This release

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.2

2 release files

0.1.1

2 release files

0.1.0

2 release files

0.0.3

2 release files

0.0.2

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page