[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] RE: your thoughts on DARIF
|
Thank you all for so enthusiastically responding! I, however, would still argue that DARIF should be separate from SARIF. In Fortify’s experience, what you need to describe dynamic results is very different from what you need to describe static results. And
I would argue against extending SARIF, especially considering there is a talk of incorporating other types of analyses. I am wondering, however, whether it would be possible to create a suite of standards under the same umbrella and structure it in such a
way that one is able to implement/use part of the suite according to their needs. Is it possible to create something like a Program Analysis Results Interchange Format (PARIF) that contains sections for SARIF, DARIF, CCARIF (“code coverage”), MARIF (“metrics”)
, etc.?
Thoughts? k From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org]
On Behalf Of Larry Golding (Myriad Consulting Inc) Actually, if we can maintain back compat (only adding to the schema, no changes or deletions) then according to
Semver DARIF could go out as a minor revision 2.2.0:
Ø
Bug fixes not affecting the API increment the patch version,
backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. That would go down much more easily for existing customers of SARIF 2.1.0. And it wouldn’t prevent us from bug-fixing the current spec as 2.1.1. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
It seems like we’ve got the nucleus of an interesting moving forward plan.
1)
Invoke the OASIS machinery to expand the charter of this technical committee to include dynamic analysis results/metrics.
2)
As part of this process, remap the ‘S’ in SARIF to ‘Software’ to retain the brand. Bless the new proposed standard as a v3 effort to indicate it is a major revision.
3)
Explore moving forward funding/staffing of the technical committee. David pointed out offline that convening a moving forward v3 effort might also create more flexibility in bug-fixing the v2 spec along the way (a point I agree with). I will float this idea around MS a bit.
On a separate note, a different team approached me on producing a standard that attempts to codify a complete data model for end-to-end engineering, including static analysis. Think models to express projects,
people, release pipelines, deployment environments, analysis results, etc. etc. and linking them together. For quality, compliance, auditing, chain-of-custody purposes. Michael From: Paul Anderson <paul@grammatech.com>
All: We're very interested too. We've had some success with expressing dynamic properties in SARIF already. I would argue that we should work to have one standard that can satisfy both needs. Perhaps the 'S' should stand for just 'Software'. Having said that,
someone here is also looking at using it to express properties in HDLs. To express test coverage results it will be important to express metrics in the format. For example, a commonly used metric is the Test Effectiveness Ratio (TER), which is percentage of the function that got covered by the test suite. It would be super useful
to be able to express that in SARIF. (Some organizations have rules that require TER to be greater than some threshold, and violations of that rule can then be expressed as SARIF results.) Many other dynamic results (e.g., profiling) are also expressed as
metrics, so I believe that's the biggest gap in SARIF for dynamic use. -Paul On 7/18/2019 6:53 PM, Larry Golding (Myriad Consulting Inc) wrote:
-- Paul Anderson, VP of Engineering, GrammaTech, Inc. 531 Esty St., Ithaca, NY 14850 Tel: +1 607 273-7340 x118; http://www.grammatech.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]