sarif — archive

RE: Relationship kinds

From: Laurence Golding
To: [email protected]
Date: Sat, 20 Apr 2019 01:32:00 -0000

Oooh! Let’s define "relevant" like we did for reportingDescriptorRelationship.kinds so that – again, like reportingDescriptorRelationship.kinds –the default for location.relationshipKinds is [ "relevant" ] . Having done that – and it hurts me to say this – I see that our location relationship design is inconsistent with our reporting descriptor relationship design. We should have done this for consistency: Define an object locationRelationship with these properties: target of type integer , required, minValue : 0 kinds of type string[] , optional, default: [ "relevant" ] . In the location object: Add a property id of type integer, optional, minValue : -1, default: -1 ( no change from current design – relocated from physicalLocation ) Add a property relationships of type locationRelationship[] , optional, default: [] . In the physicalLocation object: Remove the id property ( no change from current design – moved to location ) Sorrier than I can say (and only partially facetious about that), Larry From: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Friday, April 19, 2019 5:49 PM To: OASIS SARIF TC Discussion List <[email protected]> Cc: Harleen Kaur Kohli <[email protected]> Subject: [sarif] Relationship kinds As part of our acceptance of #375 (location relationships), I took an action to drive a mailing list discussion about values for location.relationshipKinds , beyond the two values "includes" and "isIncludedBy" that the issue defines. So… any ideas? I will take 30 seconds now to ponder… Some taint-related values? Like "isSourceOfTaintedDataUsedBy" , "isSinkForTaintedDataUsedBy" , and "sanitizesTaintedDataUsedBy" . (pretty verbose, but I wanted to be clear about the relationships). Thanks, Larry