Perfect, this works!
The sink rule is associated with a code flow, but either way this works!
Thanks!
k
From: Larry Golding (Comcast) [mailto:
larrygolding@comcast.net]
Sent: Friday, June 08, 2018 2:25 PM
To: 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com>; 'Michael Fanning' <
Michael.Fanning@microsoft.com>
Cc:
sarif@lists.oasis-open.org Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
No problem – codeFlow s have property bags too. So you could do:
{ # A result object.
"ruleId": "xxxx", # The "sink" rule that identifies the "violation of correctness"
...
"codeFlows": [
{
"threadFlows": [
...
],
"properties": {
"fortify/helperRuleId": "yyyy"
}
},
{
"threadFlows": [
...
],
"properties": {
"fortify/helperRuleId": "zzzz"
}
}
]
}
I can’t tell from what you’ve said so far whether the “sink” rule is also associated with one of the
codeFlow s, but it’s no problem if it is.
Larry
From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org >
On Behalf Of O'Neil, Yekaterina Tsipenyuk
Sent: Friday, June 8, 2018 1:10 PM
To: Larry Golding (Comcast) <
larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >; 'Michael Fanning' <
Michael.Fanning@microsoft.com >
Cc:
sarif@lists.oasis-open.org Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
Hi Larry,
The example you provided below makes sense, so I guess we are ok for CSD.1.
In general though, for Fortify dataflow results, each of the ruleids is basically associated with a codeflow, meaning that each codeflow is generated either by the analyzer directly when it has access to all
the source code or with a rule if the analyzer encounters a call to a library function for which the source code is not provided or if the rule adds additional information to the trace for later use. So, if we follow the solution proposed below, then the connection
between ruleids and codeflows is lost, unless we follow a convention we come up with.
k
From: Larry Golding (Comcast) [ mailto:
larrygolding@comcast.net ]
Sent: Friday, June 08, 2018 10:47 AM
To: 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >; 'Michael Fanning' <
Michael.Fanning@microsoft.com >
Cc:
sarif@lists.oasis-open.org Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
Yekaterina,
Do you think there are any changes that are needed for CSD.1?
Larry
From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org >
On Behalf Of Larry Golding (Comcast)
Sent: Friday, June 8, 2018 9:02 AM
To: 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >; 'Michael Fanning' <
Michael.Fanning@microsoft.com >
Cc:
sarif@lists.oasis-open.org Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
I filed Issue #190: “Distinguish ‘tool-specific’ from ‘generic’ properties” for CSD.2:
Some properties, like result.ruleId ,
can only be filled by the analysis tool (let's call them "tool-specific properties"). Others, like run.baselineInstanceGuid and result.fingerprints ,
can be filled by other components of the SARIF ecosystem, such as the result managements system (let's call them "generic properties").
Today, the spec says that the analysis tool " SHOULD NOT " fill result.fingerprints ,
which is too strong a statement. We need to explain the concept of tool-specific vs. generic properties, and encourage tool vendors
to fill only the tool-specific properties -- without making a normative statement. Perhaps we can explain this in a non-normative Appendix.
The whole idea is to make it as easy as possible for tools to emit valid SARIF, by minimizing the amount of work they have to
do.
Larry
From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org >
On Behalf Of Larry Golding (Comcast)
Sent: Friday, June 8, 2018 8:50 AM
To: 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >; 'Michael Fanning' <
Michael.Fanning@microsoft.com >
Cc:
sarif@lists.oasis-open.org Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
Michael, a couple of comments:
-
You wrote “maybe we’re too draconian with SHALL NOT”. The spec says “SHOULD NOT,” not “SHALL NOT”. But Yekaterina argues that even that is confusing. I will file an issue to revisit the issue of distinguishing “tool-specific” from “generic”
properties in CSD.2. It might be a non-normative Appendix.
-
I agree with Yekaterina, I don’t think a hierarchical rule works here. She wrote “[the]
majority of our dataflow rules, for example, are helper rules that don’t result in any finding on their own – they just help the analyzer do its job
… only the sink rule corresponds to a ‘specific criterion of correctness verified by a static analysis tool’ ”. I don’t think it makes sense to qualify the id of the “sink rule” with the ids of the helper rules that
helped the analyzer find the violation.”
Instead, I suggest that Fortify use the property bag to store the helper rule ids:
{
"ruleId": "xxxx", # The "sink" rule that identifies the “violation of correctness”
...
"properties": {
"fortify/helperRuleIds": [ "yyyy", "zzzz" ]
}
}
Larry
From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org >
On Behalf Of O'Neil, Yekaterina Tsipenyuk
Sent: Thursday, June 7, 2018 6:15 PM
To: Michael Fanning <
Michael.Fanning@microsoft.com >
Cc: O'Neil, Yekaterina Tsipenyuk <
katrina@microfocus.com >; Larry Golding (Comcast) <
larrygolding@comcast.net >;
sarif@lists.oasis-open.org Subject: Re: [sarif] Change bars for Issue #158 (result.correlationId)
I am confused about #2. Do you mean use result.ruleId property as a hierarchical property? Can you give an example?
K
On Jun 7, 2018, at 5:18 PM, Michael Fanning <
Michael.Fanning@microsoft.com > wrote:
If you think you have a finished fingerprint that is extremely resilient, agree you should populate it. Perhaps we can clarify the spec text to note that the SHOULD NOT designation here is to discourage per-tool fingerprinting (in favor
of standards/SARIF-driven fingerprinting, which uses a broad range of SARIF data in concert with partial fingerprints). I agree with Larry’s point that, in the main, SARIF producers NEED NOT populate it. But maybe we’re too draconian with SHALL NOT. If you
think you can compute a finished fingerprint, why not? On the other hand, what we really want tools producers to do is to think about their specific partial fingerprints that derive from a tool’s particular understanding of things (and which excludes things
like file locations which are ‘understood’ already in the format because we have placeholders for them).
Your item #2 sounds like a hierarchical tag to me, i.e., you would tag results with the various contributors to the finding, organized under a common root so that you can treat them as a set.
From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org >
On Behalf Of O'Neil, Yekaterina Tsipenyuk
Sent: Thursday, June 7, 2018 4:55 PM
To: Larry Golding (Comcast) <
larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >;
sarif@lists.oasis-open.org ; Michael Fanning <
Michael.Fanning@microsoft.com >
Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
Hi Larry,
Ok, understood, but it does feel like a re-phrase of some sort would be helpful. Yeah, we indeed don’t mean the same thing by the term “rule”. Not all of our rules result in a specific finding on their own. In fact, majority of our dataflow rules, for example, are helper
rules that don’t result in any finding on their own – they just help the analyzer do its job. So, the dataflow finding is generated by a set of rules, and only the sink rule corresponds to a “specific criterion of correctness verified by a static analysis
tool”.
k
From: Larry Golding (Comcast) [ mailto:
larrygolding@comcast.net ]
Sent: Thursday, June 07, 2018 11:20 AM
To: 'O'Neil, Yekaterina Tsipenyuk' <
katrina@microfocus.com >;
sarif@lists.oasis-open.org ; 'Michael Fanning' <
Michael.Fanning@microsoft.com >
Subject: RE: [sarif] Change bars for Issue #158 (result.correlationId)
Importance: High
Michael – please read this carefully to see if I’ve correctly conveyed your philosophy for analysis tool design.
Hi Katrina,
1. First of all, don’t worry, you can indeed populate
result.fingerprints . “SHOULD NOT” means “don’t do it unless you have a good reason,” and I guess your tool has a good reason