CI/CD & DevSecOps Compatibility
Wantware outputs flow through standard toolchains. Where deeper integration is desired, teams can adopt additional governance controls without replacing existing SDLC workflows.
Native — plugs in with no change required. Standard — works against exported artifacts exactly like any other build output. Optional — benefits exist when teams want them, but aren't required for Phase 1 adoption.
Compatibility matrix
| Category | Common Tools | Support Level | Notes |
|---|---|---|---|
| Version control | Git, GitHub, GitLab, Bitbucket | Native | Use repos as-is. Export mode behaves like a standard repo workflow. |
| CI orchestration | Jenkins, GitHub Actions, GitLab CI, Azure DevOps | Native | Run pipelines unchanged. Wantware outputs become normal build inputs. |
| Build systems | Maven, Gradle, CMake, Ninja, Bazel | Native | Standard build steps. Can be wrapped for richer telemetry where needed. |
| Artifact repositories | JFrog Artifactory, Sonatype Nexus, package registries | Native | Publish artifacts normally — JAR/WAR, containers, binaries. |
| Container build & registry | Docker, BuildKit, GHCR, ECR, GCR, ACR | Native | Works with existing images and registries. No new platform required for Phase 1. |
| SAST | CodeQL, Fortify, Checkmarx, Semgrep | Standard | Applies cleanly to exported code. Runtime mode uses different assurance primitives. |
| DAST | OWASP ZAP, Burp Suite, AppScan | Standard | Works against deployed services normally — URLs and endpoints unchanged. |
| Dependency scanning | Snyk, Mend, Dependency-Check | Standard | SBOM plus dependency policies can be enforced as part of pipeline gates. |
| SBOM | Syft, CycloneDX, SPDX tools | Native | Generate SBOMs for exported outputs. Attach SBOMs to artifact releases normally. |
| Signing & provenance | cosign, Sigstore, in-toto, SLSA | Standard | Sign exported artifacts normally. Deeper runtime enforcement can complement signing. |
| Policy gates | OPA, Gatekeeper, custom CI checks | Optional | Choose which workloads must produce scan-ready builds vs adaptive runtime outputs. |
| Observability | OpenTelemetry, Prometheus, Grafana, ELK, Splunk | Optional | Standard logs and metrics in export mode. Richer audit trails with deeper integration. |
| Deployment | Kubernetes, OpenShift, VM fleets, edge devices | Native | Deploy outputs into current targets. No mandatory migration path. |
What this means in practice
For Build-First Teams
Nothing in your toolchain needs to change to start. Wantware generates outputs your existing Git / Jenkins / Nexus / Kubernetes stack already knows how to handle. You get the benefit of intent-driven generation without touching build, test, scan, or deploy infrastructure.
For Security-First Teams
SAST, DAST, dependency scanners, SBOM generators, and signing tools all operate on exported artifacts as they do today. Where teams want additional assurance — continuous runtime verification, purpose enforcement, lineage audit — those capabilities layer on without replacing existing scanners.
For Platform Teams
Policy gates, observability pipelines, and deployment systems continue to operate on their existing surfaces. The incremental opportunity is adding runtime policy enforcement and richer telemetry where allowed — but nothing in the existing platform has to move.
Wantware is designed to fit into the toolchain your team already runs. Phase 1 adoption is native — no new CI system, no new repository, no new scanner. Deeper integration is optional and earns its place workload-by-workload.