# OpenAEV for adversary simulation campaign planning and execution > OpenAEV is a Java platform for planning, scheduling, conducting, and monitoring adversary simulation campaigns. It fits security teams that need coordinated exercises across injectors and threat-informed scenarios, but deployment, licensing, and operational dependencies require review before adoption. **OpenAEV-Platform/openaev** — Open Adversarial Exposure Validation Platform - Repository: https://github.com/OpenAEV-Platform/openaev - Website: https://openaev.io - Stars: 1,839 · Forks: 229 - Language: Java - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/openaev-platform-openaev ## OpenAEV's campaign problem and intended security teams OpenAEV addresses campaign-level adversary simulation rather than a single automated test. The README says organizations use it to plan, schedule, and conduct cyber adversary simulation campaigns and tests. Its intended users include public-sector bodies and private organizations running simulations, training, or exercises, ranging from technical work to strategic coordination. The central problem is operational: several participants need shared scenario definitions, teams, inject delivery, live status, statistics, and feedback instead of coordinating every step through documents and disconnected tools. The platform also targets purple-team work because it connects exercise content with threat knowledge. OpenAEV can draw on the OpenCTI platform to relate simulations to actual threats and expose security gaps. That relationship matters for adoption. A team considering OpenAEV because it already uses OpenCTI may find the integration more relevant than that of an isolated campaign scheduler, although the README does not document the exact connector configuration or data exchange. Communication and action channels sit alongside scenario planning. OpenAEV supports inject types connected to email, SMS, social media, and alarm systems, according to the README. It also names scenarios, teams, simulations, communication verification, and encryption among its modules. These details make it a control plane for exercises. It does not read like a packet-level attack framework or a source-code scanner: the documented object is a coordinated exercise with participants, injects, monitoring, and feedback. ## OpenAEV's scenario, team, and inject data flow Based on the README and repository layout, OpenAEV is a full-stack platform rather than a small Java library. The repository separates the frontend in `openaev-front/` from backend and domain components such as `openaev-api/`, `openaev-model/`, and `openaev-framework/`. It also contains Elasticsearch clients, OpenSearch code, an OCSF component, build services, and a custom Maven plugin. Those directories indicate separate UI, application, model, and search interfaces, although the README does not publish a complete deployment architecture or event sequence. A campaign appears to begin with scenario preparation, then proceeds through team participation and scheduled simulation execution. Injects provide the delivery mechanism for exercise actions. External integrations carry those actions into channels such as email, SMS, social media, and alarm systems. During execution, the platform provides real-time monitoring and statistics. Feedback then gives organizers a record for reviewing the exercise. The exact trigger rules, injector API contract, persistence format, and OpenCTI synchronization process are not documented in the README. The repository also suggests that external data services are part of deployment planning rather than optional details. Modules named `openaev-es8-client`, `openaev-es9-client`, and `openaev-opensearch-client` correspond to search and storage integration points. `openaev-ocsf` indicates a component related to OCSF, but the excerpt does not state which records it transforms or whether the mapping is mandatory. An evaluator should inspect those modules and the installation documentation before assuming a single-node or self-contained deployment. ## Installing OpenAEV and reaching a first scenario view The README routes installation to the official documentation and offers two paths: Docker or manual installation. It does not provide a verified `docker run` command, Compose file name, required port, Java startup command, or environment-variable list, so this article does not invent a first-run command. Obtain the exact deployment steps from the installation page linked by the README. The repository root contains a `Dockerfile`, and its build stages use Node and Yarn for `openaev-front`, Maven and Java 21 for the API build, and an Eclipse Temurin Java runtime for the application image. Those details describe the image build, not a complete container deployment. For a first real use, follow the documented installation procedure, initialize the platform, and inspect the areas named by the README: scenarios, teams, simulations, communication verification, encryption, monitoring, statistics, and feedback. The clearest initial exercise is to create or import a small scenario, assign a test team, schedule its simulation, confirm its expected communication channels, and review the resulting feedback record. This is a workflow rather than a claim about undocumented UI labels. The README confirms that those modules exist, but it does not publish a step-by-step tutorial with exact button names. Before sending a real inject, verify the injector ecosystem documentation for the selected channel. Also inspect the Enterprise Edition setting if advanced features are in scope. The README says the Enterprise Edition can be enabled directly in platform settings. It does not say whether the demonstration instance includes the same edition or whether all injector integrations work without additional services, so neither point should be assumed. ## OpenAEV edition boundaries and telemetry Licensing is the first edition-level decision. The README states that Community Edition is licensed under Apache License 2.0, while Enterprise Edition uses an Enterprise Edition license in the repository's `LICENSE` file. GitHub classifies the repository's licence as a custom licence because the project combines these terms. This matters for organizations that require every included component to use one known permissive licence. They should read the edition boundary in `LICENSE` and determine which files and features apply to their intended deployment. This is a licence-compliance checkpoint, not legal advice. The Enterprise Edition is not merely a differently named build in the description. The README says it provides additional features that require development investment and directs readers to the Filigran Enterprise Editions page for the feature comparison. Since this review does not reproduce that external page, it cannot identify which capabilities are exclusive or evaluate their operational cost. A prospective adopter should compare the required campaign functions against that feature list before enabling EE. OpenAEV also collects anonymous statistical data related to usage and health, according to the README. Details are placed in the telemetry documentation. This creates a separate deployment and governance question from edition selection. Review that page for event scope, retention, and configuration controls. The excerpt does not state whether telemetry can be disabled or whether its contents differ between CE and EE, so neither answer should be inferred. ## OpenAEV limitations for lightweight or offline exercises OpenAEV is the wrong shape for a small team that only needs to deliver a single inject or record a short technical test. Its documented scope includes campaign planning, teams, scheduling, monitoring, statistics, feedback, multiple inject integrations, and threat context. That breadth introduces platform deployment and operational coordination. A simpler mechanism may be easier when the exercise has one channel, one operator, and no requirement for shared monitoring or post-exercise review. Connectivity is another boundary. The README highlights OpenCTI knowledge, ecosystem injectors, email, SMS, social media, and alarm integrations. It does not describe an offline execution mode. The presence of several external integrations should not be mistaken for proof that every exercise depends on them, but a disconnected or air-gapped deployment would need documented confirmation from the installation and injector documentation. The demo also has a precise limit: the README says it is open to everyone and reset every night using reference data maintained by the OpenAEV developers. It is therefore useful for inspecting workflow, not for preserving an organization's campaign records or testing production integrations. Likewise, the repository has frequent releases and a last push on 2026-10-16, but release frequency does not remove upgrade work. The multi-module Java stack, frontend packages, search clients, base-image updates, edition split, and injector compatibility all need consideration during upgrades. ## OpenAEV versus a standalone injector runner A standalone injector runner is the clearest alternative. Such a tool can execute a defined action or adapter directly without providing a complete campaign workspace. OpenAEV instead centers the exercise around scenarios, teams, schedules, simulation monitoring, statistics, and feedback. Its injectors become delivery mechanisms inside a broader exercise process. The practical difference is control and administrative scope. Choose a standalone runner when the immediate need is narrow automation and low operational complexity. Choose OpenAEV when several people must coordinate a campaign, exercise outputs must be reviewed afterward, or inject delivery spans multiple channels. OpenAEV's OpenCTI connection also matters when threat intelligence should inform the scenario context. The README does not compare execution speed, injector compatibility, recovery behavior, or standalone runner features, so those points require direct comparison rather than inference from OpenAEV's broader feature list. ## Conclusion OpenAEV suits security organizations that need a shared campaign workspace, injector coordination, and exercise feedback rather than a standalone attack script runner. Organizations requiring proven offline operation, a uniformly permissive licence, or a lightweight tool should verify infrastructure dependencies, Enterprise features, telemetry behavior, and upgrade procedures first. The project-specific adoption threshold is whether a pilot can run a complete scenario through scheduling, inject delivery, monitoring, and feedback with the selected edition. ## FAQ ### How do I install OpenAEV? The README directs users to the official installation documentation and identifies Docker and manual installation as the supported paths. It does not include a complete deployment command. ### What is the difference between OpenAEV Community Edition and Enterprise Edition? Community Edition uses Apache License 2.0, while Enterprise Edition uses the repository's Enterprise Edition licence. The README says EE adds further features but points to an external page for the detailed comparison. ### Does OpenAEV collect usage telemetry? The README states that OpenAEV collects anonymous statistics related to platform usage and health. It refers readers to the usage telemetry documentation for details. ## Sources - [Issues](https://github.com/OpenAEV-Platform/openaev/issues) - [OpenAEV-Platform/openaev on GitHub](https://github.com/OpenAEV-Platform/openaev) - [Project website](https://openaev.io) - [README](https://github.com/OpenAEV-Platform/openaev/blob/main/README.md) - [Releases](https://github.com/OpenAEV-Platform/openaev/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openaev-platform-openaev