The recent release of sekoia-automation-models on PyPI marks a meaningful step forward for security teams seeking to automate threat detection and response workflows with greater reliability. By publishing a standalone library of Pydantic models that underpin the Open Cybersecurity Schema Framework (OCSF) asset-connector, Sekoia provides a shared foundation that its various services and the sekoia-automation-sdk can consume directly. This approach eliminates the need for each component to define its own data structures, reducing the risk of mismatched fields and ensuring that every piece of the platform speaks the same language when handling asset information. For organizations that rely on Sekoia’s orchestration capabilities, the availability of these models translates into faster onboarding of new data sources and fewer integration headaches. Moreover, because the models are versioned and distributed via the standard Python package index, teams can lock dependencies with precision, facilitating reproducible builds and smoother CI/CD pipelines. In a landscape where security automation must keep pace with evolving threats, having a stable, well‑typed contract between services is not just convenient—it is essential for maintaining confidence in automated decisions.
Pydantic has become the de facto standard for data validation and settings management in modern Python applications, and its adoption in sekoia-automation-models underscores the library’s focus on correctness and developer ergonomics. By leveraging Pydantic’s declarative syntax, each model defines fields with explicit types, constraints, and default values, which are then automatically enforced at runtime whenever data is instantiated or parsed. This means that malformed asset records—whether they originate from a cloud provider, an on‑premise scanner, or a custom feed—are caught early, preventing silent failures that could otherwise lead to gaps in detection coverage. Beyond validation, Pydantic offers powerful serialization capabilities, allowing models to be effortlessly converted to JSON, dictionaries, or other formats required by downstream services. The library also supports rich error reporting, making debugging straightforward when incoming data deviates from the expected schema. For developers accustomed to manual validation boilerplate, the shift to a model‑driven approach reduces cognitive load and frees mental bandwidth to focus on the logic of detection and response rather than the mechanics of data handling.
The OCSF asset-connector model included in this package represents a concrete implementation of the Open Cybersecurity Schema Framework’s ambition to create a common language for describing assets across disparate security tools. Assets—ranging from virtual machines and containers to user accounts and IoT devices—are fundamental building blocks of any security analytics pipeline, yet they are often described using inconsistent naming conventions and attribute sets. By adopting OCSF, Sekoia aligns itself with an industry‑wide effort to normalize these descriptions, thereby simplifying correlation rules, enriching threat intelligence feeds, and enabling smoother data exchange between platforms that might otherwise speak different dialects. The asset‑connector model captures essential attributes such as asset ID, hostname, IP addresses, operating system details, ownership tags, and vulnerability counts, while remaining extensible enough to accommodate vendor‑specific fields through optional extensions. This balance between standardization and flexibility ensures that organizations can reap the benefits of a shared schema without sacrificing the ability to capture unique contextual information that may be critical for accurate risk assessment.
One of the most tangible advantages of distributing these models as a standalone package is the elimination of duplication across Sekoia’s micro‑services and the sekoia-automation-sdk. Previously, each service might have maintained its own copy of asset‑related data classes, leading to version drift where subtle differences in field names or types crept in over time. Such drift can manifest as serialization errors, failed assertions, or incorrect enrichment during playbook execution, all of which undermine trust in automated workflows. By centralizing the definition in a single, version‑controlled library, any update to the model propagates uniformly to all consumers, guaranteeing that a change made in the authentication service is instantly reflected in the alert‑correlation engine and the custom automation scripts built with the SDK. This uniformity also simplifies dependency management: security engineers can pin a specific release of sekoia-automation-models in their requirements.txt or poetry.lock file, confident that every component of their stack will resolve to the exact same implementation.
From a software engineering perspective, the availability of tightly typed models accelerates the development lifecycle in several concrete ways. First, IDEs equipped with type‑checking plugins (such as Pyright or MyPy) can provide real‑time autocompletion and inline diagnostics, reducing the likelihood of typographical errors that would only surface during runtime testing. Second, unit tests become more focused: rather than writing extensive assertions to verify the shape of every incoming payload, developers can rely on Pydantic’s built‑in validation and instead concentrate on testing business logic—such as whether a particular enrichment step correctly tags an asset based on its vulnerability score. Third, the contract‑first approach encourages API designers to think carefully about the data they expose, fostering clearer documentation and reducing ambiguity for consumers. Over time, these benefits compound, leading to shorter release cycles, fewer production incidents related to data mishandling, and a more predictable velocity for teams tasked with delivering new detection rules or response playbooks.
The release fits neatly into a broader market trend where model‑driven development is gaining traction as a means to increase both speed and safety in software projects. Industries ranging from finance to healthcare have embraced schema‑first approaches—think of OpenAPI for REST services, Protobuf for gRPC, or GraphQL schemas—to enforce contracts between loosely coupled services. In the security automation space, where the stakes involve real‑time threat mitigation, the cost of a schema mismatch can be measured in missed detections or false positives that waste analyst time. By offering a versioned, pip‑installable set of Pydantic models, Sekoia is effectively treating its internal data contracts as first‑class artifacts, a practice that mirrors the rise of ‘contract testing’ frameworks such as Pact. This shift signals to the ecosystem that reliability and interoperability are not afterthoughts but core design principles, encouraging other vendors to consider similar model‑sharing strategies for their own platforms.
Compatibility constraints are an important practical consideration for any Python library, and sekoia-automation-models targets Python versions 3.11 through the latest pre‑4 release, deliberately excluding older releases. This decision reflects the library’s reliance on language features and standard library improvements introduced in Python 3.11, such as enhanced error messages, performance optimizations in the built‑in data structures, and finer‑grained control over exception groups. By setting the floor at 3.11, the maintainers ensure that users benefit from these advancements without needing to back‑port compatibility shims that could complicate the codebase. The upper bound of ‘<4' is a conventional way to express compatibility with any future 3.x release while guarding against breaking changes that might arrive with a hypothetical Python 4.0. For organizations that still run legacy Python 3.10 or earlier environments, the requirement may necessitate an upgrade path, but the payoff is a more robust and future‑ready foundation for their automation workloads.
Although the package is hosted on PyPI and installable via the standard pip toolchain, its maintenance model is noteworthy: the project is described as being “developed and maintained by the Python Software Foundation and Python community, for the Python community.” This phrasing suggests that the library benefits from the governance and stewardship structures that underpin the broader Python ecosystem, including clear contribution guidelines, a transparent release process, and adherence to the Python Packaging Authority’s best practices. Such oversight can increase confidence among enterprise adopters who often scrutinize the provenance and long‑term viability of third‑party dependencies. Moreover, community involvement means that bug fixes, feature enhancements, and documentation improvements can emerge from a diverse set of contributors, reducing the risk of a single point of failure. For teams that value open‑source collaboration, this model offers an opportunity to not only consume the library but also to contribute back—whether by reporting issues, submitting pull requests, or participating in discussions about future versions of the OCSF asset‑connector model.
To illustrate how these models can be applied in a real‑world scenario, consider a security team that wants to ingest asset data from AWS EC2 instances into Sekoia’s platform for enrichment and correlation. Using sekoia‑automation‑models, the team can define a simple data‑ingestion function that retrieves the list of instances via the boto3 SDK, maps the relevant fields (instance ID, private IP address, public IP address, tags, launch time, and associated security groups) onto the OCSF Asset model, and then passes the validated object to Sekoia’s event pipeline. Because the model enforces type constraints—such as ensuring that IP address fields conform to the IPv4Address or IPv6Address types and that timestamps are proper datetime objects—any malformed data from the API call is caught before it reaches the correlation engine. The validated asset can then be serialized to JSON and sent over a message queue or HTTP endpoint, confident that downstream services will interpret the fields correctly. This pattern can be replicated for other sources such as Azure VMs, GCP Compute Engine, on‑premise vulnerability scanners, or even custom CMDB exports, creating a uniform ingestion layer that reduces custom code and increases reliability.
Getting started with sekoia-automation-models is intentionally straightforward, reflecting the library’s aim to lower the barrier to adoption for both seasoned Python developers and those newer to security automation. The first step is to add the dependency to your project’s dependency management file—for example, by running `pip install sekoia-automation-models==1.3.0` or adding the appropriate entry to a Poetry or Pipfile lock. Once installed, you can import the relevant models directly from the package, such as `from sekoia_automation_models import Asset`. From there, instantiating a model is as simple as calling `Asset(**data_dict)`, where `data_dict` contains the raw attributes you have gathered from a source. If the input fails validation, Pydantic will raise a ValidationError that includes a detailed list of which fields violated expectations and why, making troubleshooting a matter of reading the reported errors rather than guessing at the root cause. For teams that use asynchronous frameworks, the models remain compatible because they are plain Python objects; they can be passed between coroutines without any additional wrapping. This simplicity encourages rapid prototyping, allowing a developer to spin up a proof‑of‑concept ingestion script in under an hour and iterate quickly based on feedback.
While the benefits are substantial, it is prudent to be aware of potential pitfalls that could undermine the advantages of adopting a shared model library. One common issue is version drift caused by pinning to a overly permissive range (e.g., `>=1.0.0,<2.0.0`) instead of an exact version, which can lead to subtle incompatibilities when a new minor release introduces a change to a field’s type or removes a deprecated attribute. To mitigate this, teams should adopt a disciplined version‑pinning strategy in their CI pipelines, perhaps using tools like `pip-tools` or `poetry lock` to generate deterministic lockfiles. Another consideration is the temptation to treat the model as a closed box; while the OCSF asset‑connector provides a solid baseline, real‑world environments often require custom fields that are not part of the standard schema. The library supports extension through subclassing or by utilizing Pydantic’s `Field` with `extra='allow'`, but developers must document any deviations clearly to avoid confusion among consumers of the data. Finally, because the models are pure Python objects, they do not enforce any particular transport mechanism; teams must still decide how to serialize and transmit the data (e.g., JSON over HTTPS, Avro over Kafka) and ensure that the chosen format preserves the model’s fidelity across service boundaries.
Looking ahead, the introduction of sekoia-automation-models offers a clear pathway for organizations seeking to modernize their security automation stacks with a foundation built on reliability and interoperability. To make the most of this release, practitioners should begin by auditing their existing data pipelines to identify points where ad‑hoc data structures are currently in use, then replace those with the standardized Pydantic models wherever feasible. A practical first step is to create a small, isolated ingestion connector for a non‑critical data source—such as a internal asset spreadsheet—using the models, validate the end‑to‑end flow, and gradually expand to more sensitive feeds as confidence builds. Engaging with the broader community by monitoring the project’s issue tracker, participating in discussions about upcoming OCSF extensions, and contributing improvements not only helps the library evolve but also surfaces potential edge cases early. Finally, maintain a habit of regularly reviewing the library’s release notes and updating dependencies in a controlled fashion, ensuring that your automation environment remains both secure and resilient in the face of evolving threats and platform changes.