Canonical contracts are the product boundary
The Workbench should not need to know whether an incoming evidence object came from Verno, Dreadnode, AppCheck, OpenTelemetry, or a future partner. Likewise, the SecEng scanner should not contain AppCheck-specific fields. Three canonical models sit at that boundary:
- Finding — a security finding from a scanner, test engine, analysis engine, or normalized external scanner.
- Evidence / Attack Trace — a provenance-bearing observation, explicitly separating observed state, grounding eligibility, provenance, and taxonomy mappings from anything inferred.
- Attack Path Result — SecEng's canonical return structure for evidence-qualified attack clusters, grounded vs. speculative boundaries, validation state, chokepoints, and retest conditions.
Protocol-first, then vendor binding
If two vendors share an interchange protocol, the protocol is implemented once, not once per vendor:
| Protocol | Vendors on it today |
|---|---|
| SARIF | AppCheck-compatible workflow, StackHawk-compatible workflow, GitHub/GitLab code scanning |
| OpenTelemetry | Verno and Pallma lineage; future agent/runtime platforms |
| ATIF | Dreadnode; future trajectory-producing systems |
A vendor binding may rename fields, normalize enums, preserve vendor identifiers, and select protocol capabilities — it should not reimplement JSON Schema validation, provenance mechanics, or generic severity normalization; those live once in the protocol layer.
Four-stage claim boundary
Every vendor binding is explicit about how confirmed its claims are:
| Stage | Meaning |
|---|---|
| Vendor documented | A field, endpoint, or behavior explicitly documented by the vendor. |
| SecEng projection | A SecEng-defined representation shaped to interoperate with the publicly documented vendor model — not asserted to be a valid native request. |
| Partner confirmation required | A write path, private API, webhook body, or ingestion schema that public material does not establish. |
| Native partner confirmed | A contract supplied or explicitly confirmed by the partner — the only stage a native adapter should be built against. |
This is why current Verno and AppCheck adapters do not claim a final native schema, webhook contract, or confirmed rescan/ingestion path — see partner pilots.
Scanner extension
The partner owns scan orchestration, customer/target context, product interface, finding lifecycle, remediation workflow, and first-line support. SecEng adds AI-native code and workflow analysis, structured findings, SARIF where supported, and evidence references.
Offensive-platform enrichment
The partner owns attack generation, campaign workflow, execution, and the operator interface. SecEng adds architecture and authority context, evidence and sequence qualification, chokepoint analysis, and structured return objects — while keeping grounded and speculative steps distinct.
Pilot before native integration
A native adapter is never the first deliverable. First prove input compatibility, output usefulness, identity/provenance retention, and lifecycle fit — see partner pilots.