fix(scope): expectation signatures structured output is not keyed like configured in contract output element

Description

structured output sent as

{ "signatures" : { "targets".... } }

Contract output element is configured as

expectation_signature = ContractOutputElement(
    type=ContractOutputType.ExpectationSignature,
    field="expectation_signature",
    isMultiple=True,
    isFindingCompatible=False,
    labels=["scan"],
)

Environment

OS: { e.g. macOS 14, Windows 11, Ubuntu 22.04, etc. }
Version: { e.g. 1.2.3 }
Other environment details:

Reproducible steps

Steps to create the smallest reproducible scenario:

{ e.g. Run ... }
{ e.g. Click ... }
{ e.g. Error ... }

Expected output

Actual output

Additional information

An injector sends scan results with expectation signatures (Nmap, vulnerability scanner). The platform cannot match the signatures
against the expectations because the key is wrong → all injects show no result or uncertain state. Post-exercise reports show no detection signatures. The operator has no visibility on whether the control worked.

Fix: align the serialized key to the contract field declaration. The serializer should read the key from ContractOutputElement.field
rather than using a hardcoded string this prevents the same class of bug on other output elements.

Short term: fix "signatures" → "expectation_signature" in the serializer.Long term: enforce that all structured output builders derive their JSON keys from the ContractOutputElement.field value — no hardcoded strings.

related to OpenAEV-Platform/openaev#855

antoinemzs

antoinemzs and Denise (@DeniseMonreale)

Regarding the field name signatures vs expectation_signature,

isn't this more of an error in the injectors project PR (we wrongly used field="expectation_signature", and should amend the PRs for netexec, nmap and nuclei) and there is no need to change that in client-python
or is the structured_output updated to replace signatures with expectation_signatures ? (unsure in that case if we still need to update the PRs to change from expectation_signature to expectation_signatures)

I see that there are others change in the PR, we can cherry-pick it / create a new one with the proper issues in github for

the execution_status values (is there a reference for the values in the code ? we replicated the enum for execution_action since it was defined as InjectExecutionAction in Java, but execution_status seemed to be a plain String - this way we could add an Enum too in order to limit the values for execution status python-side)
the change from complete to command_execution for the post_execution_update (we may need more information regarding the meaning of the values in InjectExecutionAction if post-execution the status should be command_execution rather than complete)

Short term: fix "signatures" → "expectation_signature" in the serializer.
Long term: enforce that all structured output builders derive their JSON keys from the ContractOutputElement.field value — no hardcoded strings.

Do you want us to open a different issue to remind us of the more long-term solution?

Regarding the field name signatures vs expectation_signature,

isn't this more of an error in the injectors project PR (we wrongly used field="expectation_signature", and should amend the PRs for netexec, nmap and nuclei) and there is no need to change that in client-python

or is the structured_output updated to replace signatures with expectation_signatures ? (unsure in that case if we still need to update the PRs to change from expectation_signature to expectation_signatures)

it was perhaps a mistake to hardcode this key in the pydantic model, because this is supposed to be up to the contract creation to define which is the correct key name. In this siutation, the signatures contract output element can only have one field name: that which is hardcoded in pyoaev. That said, it's just a key and we can live with a hardcoded one, and my draft only sets my own preferred wording: expectation_signatures (which is more epxlicit).

I see that there are others change in the PR, we can cherry-pick it / create a new one with the proper issues in github for

the execution_status values (is there a reference for the values in the code ? we replicated the enum for execution_action since it was defined as InjectExecutionAction in Java, but execution_status seemed to be a plain String - this way we could add an Enum too in order to limit the values for execution status python-side)

the change from complete to command_execution for the post_execution_update (we may need more information regarding the meaning of the values in InjectExecutionAction if post-execution the status should be command_execution rather than complete)

regarding this other set of changes,

re the status: they are indeed string typed in the envelope, but do have enum constraints on the platform.
re the action: we have some debt on the platform that makes it difficult to use complete, we might have to add one more TBD

it was perhaps a mistake to hardcode this key in the pydantic model, because this is supposed to be up to the contract creation to define which is the correct key name. In this siutation, the signatures contract output element can only have one field name: that which is hardcoded in pyoaev. That said, it's just a key and we can live with a hardcoded one, and my draft only sets my own preferred wording: expectation_signatures (which is more epxlicit).

Explicit is better than implicit (PEP 20). I'll updated the PRs injector-side to add the missing s. And we'll open an issue for the more long-term fix.

* re the status: they are indeed string typed in the envelope, but do have enum constraints on the platform.

Looking at the front-end side I found this list :

    | "EXECUTED"
    | "EXECUTED_WITH_CLEANUP_FAILURE"
    | "WARNING"
    | "ACCESS_DENIED"
    | "ERROR"
    | "COMMAND_NOT_FOUND"
    | "COMMAND_CANNOT_BE_EXECUTED"
    | "PREREQUISITE_FAILED"
    | "INVALID_USAGE"
    | "TIMEOUT"
    | "INTERRUPTED"
    | "ASSET_AGENTLESS"
    | "AGENT_INACTIVE"
    | "AGENT_OVERLOADED"
    | "INFO"
    | "PARTIAL"
    | "MAYBE_PREVENTED"
    | "MAYBE_PARTIAL_PREVENTED";

Do you OK those values as the allowed ones for execution_status?

* re the action: we have some debt on the platform that makes it difficult to use `complete`, we might have to add one more TBD

In that case, to easier the tracking and potential rollback/fix once the situation evolves platform-side, would you mind splitting the PR in two? I can do it if you don't mind me rewriting a bit your current PR.

Looking at the front-end side I found this list : [...] Do you OK those values as the allowed ones for execution_status?

correct

In that case, to easier the tracking and potential rollback/fix once the situation evolves platform-side, would you mind splitting the PR in two? I can do it if you don't mind me rewriting a bit your current PR.

I don't mind at all, it's a draft to group together some hot fixes for progressing on the platform side,
in either case, we need the action to be something else than complete and none other currently fit the use case well (I was thinking something like data).

fix(expectations): rename expectation signature field (#294)

Navigation Menu

Repository navigation

fix(scope): expectation signatures structured output is not keyed like configured in contract output element #294

Description

Environment

Reproducible steps

Expected output

Actual output

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix(scope): expectation signatures structured output is not keyed like configured in contract output element #294

Description

Description

Environment

Reproducible steps

Expected output

Actual output

Additional information

Activity

DeniseMonreale commented on Jun 29, 2026

DeniseMonreale commented on Jun 29, 2026

guzmud commented on Jun 29, 2026

antoinemzs commented on Jun 29, 2026

guzmud commented on Jun 29, 2026

antoinemzs commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions