Skip to main content

otupy: OpenC2 Utilities for Python

Description

otupy (/'əʊtu:paɪ/) is an open-source implementation of the OpenC2 language written in Python. It is particullary suited for:

  • developers that are looking for a common interface to control their remote cybersecurity functions;
  • researchers that design new profiles for cybersecurity functions;
  • system integrators that need a common language for their cybersecurity frameworks.

The otupy framework is build around a pluggable and powerful core library, designed with flexibility and extensibility in mind. Profiles, transfer protocols, serialization formats, and actuators can be easily added without impacting the core library itself. The framework currently includes:

  • the core library that implements the OpenC2 Architecture and Language Specification;
  • json/yaml/xml/cbor serialization;
  • implementation of the HTTP/MQTT transfer protocol;
  • the definition of the SLPF profile;
  • the Context Discovery profile and its actuators for OpenStack and Kubernetes;
  • a dumb implementation of an actuator for the SLPF profile.

Usage and extension of otupy have a shallow learning curve because data structures are explicitly designed to follow the language specification.

Quick start

Before using otupy you must be familiar with the OpenC2 Language Specification. Even if not strictly required to getting started with the code, the OpenC2 Architecture Specification provides a good introduction to OpenC2 architectural patterns and terminology.

While the Language Specification is somehow confusing about the concept of profile and actuator, otupy makes a sharp distinction between these terms:

  • a profile is a language extension that abstract a specific class of security functions (this is also indicated ad Actuator Profile by the standard);
  • an actuator is the concrete implementation of a profile for a specific security appliance; it may be either integrated in the appliance itself or act as a proxy to a legacy implementation (in this last case it is also referred as Actuator Manager.

Software requirements

Python 3.11+ is required to use otupy.

Download and setup

Otupy is available as source code, Python package, and docker container.

PyPi

Install it and its dependencies from PyPi:

pip install otupy

Docker container

A base docker image is provided, which can be used to build containers for specific applications (e.g., MIRANDA Connector). This image does not provide any default CMD or ENTRY_POINT. The base image is available at:

ghcr.io/mattereppe/otupy

A latest tag is available to download the latest version; additional tags are provided for main releases.

To download the latest version of the base image:

docker pull ghcr.io/mattereppe/otupy:latest

Clone repository

Alternatively, dowload it from github:

git clone https://github.com/mattereppe/openc2.git

and install the necessary dependecies:

python3 -m venv .oc2-env
. .oc2-env/bin/activate
pip install -r requirements.txt

Usage

A few scripts are available in the examples folder of the repository for sending a simple commmand from a controller to a remote server (hosting the actuator).

Basic usage consists in instantiating the Provider and Consumer classes that implements the OpenC2 Provider and Consumer role, respectively. This includes the creation of a protocol stack, namely the serialization format and transfer protocol. The Consumer also loads the available Actuators. Note that in the otupy implementation, the security services and transport protocols are already embedded in each specific transfer protocol.

Create the Server

A Server instantiates and runs the OpenC2 Consumer.

The otupy module only includes the core libraries, while all extensions for serialization, transfer protocols, profile definition, and actuator implementations are grouped in specific modules (encoders, trasfers, profiles, and actuators).

import otupy as oc2

from otupy.encoders.json_encoder import JSONEncoder
from otupy.transfers.http_transfer import HTTPTransfer

import otupy.profiles.slpf as slpf
from otupy.actuators.iptables_actuator import IptablesActuator

First, we instantiate the IptablesActuator as an implementation of the slpf profile:

 actuators = {}
 actuators[(slpf.nsid,'iptables')]=IptablesActuator()

(there is no specific configuration here because the IptablesActuator is currently a mockup)

Next, we create the Consumer by instantiating its execution environment with the list of served Actuators and the protocol stack. We also provide an identification string:

consumer = oc2.Consumer("consumer.example.net", actuators, JSONEncoder(), HTTPTransfer("127.0.0.1", 8080))

(the server will be listening on the loopback interface, port 8080)

Finally, start the server:

 consumer.run()

Create the Controller

A Controller instantiates an OpenC2 Producer and to use it to control a remote security function. Note that the Producer is totally unaware of the concrete actuators and its implementation.

from otupy.encoders.json_encoder import JSONEncoder
from otupy.transfers.http_transfer import HTTPTransfer

import otupy.profiles.slpf as slpf

producer = oc2.Producer("producer.example.net", JSONEncoder(), HTTPTransfer("127.0.0.1", 8080))

Next we create a Command, by combining the Action, Target, Arguments, and Actuator. We will query the remote slpf actuator for its capabilities. Note how we mix common language elements with specific extensions for the slpf profile, as expected by the Specification:

pf = slpf.slpf({'hostname':'firewall', 'named_group':'firewalls', 'asset_id':'iptables'})
arg = slpf.ExtArgs({'response_requested': oc2.ResponseType.complete})
 
cmd = oc2.Command(oc2.Actions.query, oc2.Features(), actuator=pf)

Finally, we send the command and catch the response:

resp = p.sendcmd(cmd)

(print out resp to check what the server returned)

A more useful implementation of a Controller would also include the business logic to update rules on specific events (even by specific input from the user).

Advanced usage

See the full documentation available from readthedocs.io.

Authors and acknowledgment

  • The Context Discovery profile, its actuators and use cases have been developed by Silvio Tanzarella.
  • The Xbom Actuator Profile and its serialization have been developed by Fabio Lorenzato.

License

Licensed under the EUPL v1.2.

Metadata

Release files for otupy 1.1.38

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

Source distribution (sdist)

Source distribution for otupy 1.1.38
File Size Uploaded
otupy-1.1.38.tar.gz 7.0 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for otupy 1.1.38
File Interpreter ABI Platform
otupy-1.1.38-py3-none-any.whl Python 3 none any Details

Total release size: 7.5 MB

Release files / otupy-1.1.38.tar.gz

Download URL otupy-1.1.38.tar.gz
Size 7.0 MB
Tags Source
SHA-256 checksum
How to use checksums
4a7f0066aee11144fc4ef3f4a2169f032c2e35b9bb012bcef1626963181a1004
BLAKE2b-256 checksum
How to use checksums
224e482dffc9c93d4315683acaee467d58f48e7f4640703a7ecc07ac93d19b89
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

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 Oct 5, 2026.

Transparency log

Release files / otupy-1.1.38-py3-none-any.whl

Download URL otupy-1.1.38-py3-none-any.whl
Size 472.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
2a76a242965dfc447bd1b78384dd5da5248f93412722440553ff859692f6b4dc
BLAKE2b-256 checksum
How to use checksums
c424cad51056bb87315ed1d6088fb76b6797f5a379ac775702e94ad0f6d62a1f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

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 Oct 5, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

1.1.38 This release

2 release files

1.1.37

2 release files

1.1.36

2 release files

1.1.35

2 release files

1.1.34

2 release files

1.1.33

2 release files

1.1.32

2 release files

1.1.31

2 release files

1.1.30

2 release files

1.1.26

2 release files

1.1.15

2 release files

1.1.13

2 release files

1.1.0

2 release files

1.0.1

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