OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Default lookup for helper rules


It would be cleaner to simply have the same defaulting semantics in this case, in my opinion. We have recently worked through a round of last minute clean-up in the spec related to non-obvious differences in default behaviors.

 

Michael

From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
Sent: Thursday, April 25, 2019 3:43 PM
To: 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; Michael Fanning <Michael.Fanning@microsoft.com>
Cc: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>; Harleen Kaur Kohli <harleen.kohli@microsoft.com>
Subject: Default lookup for helper rules

 

Hello Yekaterina,

 

In the description comment for Issue #381, Michael wrote this:

 

Add threadFlowLocation.taxa, an array of reportingDescriptorReferences, the default location of which (in case where only the RDR index is provided) is the relevant tool component rules data.

 

Here’s what he meant:

 

A reportingDescriptorReference object (say, one that points to an analysis rule) can contain a property named toolComponent which identifies the tool component that defined the rule. The spec says that if reportingDescriptorReference.toolComponent is missing, you look up the tool in the “driver” tool component. This is a sensible “happy path” optimization: most rules are defined in drivers rather than plugins; many tools don’t even have a plugin model.

 

But Michael reasoned that helper rules are probably defined in the same tool component that defined the analysis rule, so he felt that this was a better default for those reportingDescriptorReference objects that occur in threadFlowLocations.taxa.

 

He might be right, but I wanted to confirm with you. Because it occurred to me that – if Fortify has a plugin model – that your driver might define all the helper rules, as part of your engine. And perhaps plugins can define new analysis rules but not new helper rules.

 

If that were true, then the usual default for looking up a reporting descriptor from a reference would still make sense: look in the driver by default.

 

So my questions are:

 

  1. Does Fortify have a plugin model?
  2. If so, can Fortify plugins define both analysis rules and helper rules? Or only analysis rules?

 

Thanks!

Larry



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]