sarif — archive

RE: Relationship kinds

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

Let me modulate my message there. The two designs are indeed not consistent, and one way to make them consistent – if we think that’s desirable – is what I described. But I make no proposal about what, if anything, we should do about it. Larry From: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Friday, April 19, 2019 6:32 PM To: OASIS SARIF TC Discussion List <[email protected]> Cc: Harleen Kaur Kohli <[email protected]>; Michael Fanning <[email protected]>; James Kupsch <[email protected]> Subject: [sarif] RE: Relationship kinds Importance: High 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