You asked in the OWASP #contribute channel back in June for crosswalk contributions, and I'd like to offer one. It has an odd shape though, so I'd rather check the direction with you before opening a PR.
The existing inbound crosswalks map a scanner's finding IDs onto AVE record IDs. I can't do that, because the thing I work on isn't a scanner and emits no finding IDs. It's an attestation predicate for execution evidence (in-toto/attestation#570) with a public conformance suite.
What I noticed is that AVE already carries fields in that territory: detection_stage, detection_layer, evidence_kind_default, evidence_basis_engines, and confidence_baseline. So the crosswalk I can offer maps your evidence vocabulary onto the predicate's evidence structure. For each way a record already describes how a finding was reached, what the corresponding signed, offline-verifiable record would look like.
Concretely, from your 59 published records: your 44 static_detection records correspond to an examination method, the 15 runtime_observed ones to interception or arming, and only the two records citing a sandbox engine (AVE-2026-00054 and 00056) can carry an intercepted basis, because only there did the component actually run.
The field with no counterpart is the interesting one. confidence_baseline is a float the record's author assigns. The predicate has no confidence field and won't gain one. It expresses trust structurally instead, through who stands behind the observation and whether the observer saw the event or inferred it. I'm not suggesting you replace one with the other. A reader learns what an author believed from yours and something independently checkable from mine, and the proposal is to keep both, with the second as an optional attachment.
Obvious disclosure: the predicate is mine, so this is useful to me too. And it's a draft, currently only implemented by us, so agreement between implementations is a drift check rather than corroboration.
If the direction is useful I'll open a PR with aee-to-ave.json and aee-to-ave.md in the crosswalks directory, matching the schema and shape of the existing ones. If it isn't, no hard feelings, since you'd be the better judge of whether this belongs in AVE at all.
You asked in the OWASP #contribute channel back in June for crosswalk contributions, and I'd like to offer one. It has an odd shape though, so I'd rather check the direction with you before opening a PR.
The existing inbound crosswalks map a scanner's finding IDs onto AVE record IDs. I can't do that, because the thing I work on isn't a scanner and emits no finding IDs. It's an attestation predicate for execution evidence (in-toto/attestation#570) with a public conformance suite.
What I noticed is that AVE already carries fields in that territory: detection_stage, detection_layer, evidence_kind_default, evidence_basis_engines, and confidence_baseline. So the crosswalk I can offer maps your evidence vocabulary onto the predicate's evidence structure. For each way a record already describes how a finding was reached, what the corresponding signed, offline-verifiable record would look like.
Concretely, from your 59 published records: your 44 static_detection records correspond to an examination method, the 15 runtime_observed ones to interception or arming, and only the two records citing a sandbox engine (AVE-2026-00054 and 00056) can carry an intercepted basis, because only there did the component actually run.
The field with no counterpart is the interesting one. confidence_baseline is a float the record's author assigns. The predicate has no confidence field and won't gain one. It expresses trust structurally instead, through who stands behind the observation and whether the observer saw the event or inferred it. I'm not suggesting you replace one with the other. A reader learns what an author believed from yours and something independently checkable from mine, and the proposal is to keep both, with the second as an optional attachment.
Obvious disclosure: the predicate is mine, so this is useful to me too. And it's a draft, currently only implemented by us, so agreement between implementations is a drift check rather than corroboration.
If the direction is useful I'll open a PR with aee-to-ave.json and aee-to-ave.md in the crosswalks directory, matching the schema and shape of the existing ones. If it isn't, no hard feelings, since you'd be the better judge of whether this belongs in AVE at all.