Acting chair: David
Chat transcript from room: sarif From 2017-09-20 16:36 UTC until 17:59 UTC
Chair: Called the meeting to order @ 16:36 UTC.
All participants recorded their attendance on the OASIS meeting calendar - quorum was reached.
All participants were kindly encouraged to registrate themselves to optimize the use of the shared time during the meeting in one of two ways:
Either click the link with the text "Register my attendance" on the top of the event page or directly visit the per event direct "record my attendace link":
Note: Inaugural call special rule applies - registrated before some date and present in first meeting leads to voting member status already in that meeting.
Andrew Pardoe (Microsoft) David Keaton (Individual) Douglas Smith (Kestrel Technology) Jim Kupsch (SWAMP) Kevin Greene (DHS Office of Cybersecurity and Communications (CS&C)) Larry Hines (Novell) Laurence Golding (Individual) Luke Cartey (Semmle) Mel Llaguno (Synopsys) Michael Fanning (Microsoft) Paul Anderson (GrammaTech, Inc.) Stefan Hagen (Individual) Vamshi Basupalli (SWAMP) Yekaterina ONeil (Novell)
Also present OASIS Staff Contact:
Robin Cover (OASIS)
Note: Despite the (mis-)calculations of the tool in the TC workspace, it is sufficient to participate in two subsequent meetings of a TC to obtain voting rights after that meeting.
Henny Sipma (Kestrel Technology) Pooya Mehregan (Security Compass) Sunny Chatterjee (Microsoft)
Note: Observers of this committee that are ready to become Members should follow the specific instructions displayed the OASIS Open Notices tab.
Andrew Browne (Oracle) Vadim Okun (NIST)
David: Shorty presented the tentative agenda:
1. Opening Activities 1.1 Opening comments (Co-Chair Keaton) 1.2 Introduction of participants/roll call (Co-Chair Cartey) 1.3 Procedures for this meeting (Co-Chair Keaton) 1.4 Approval of agenda (Co-Chair Keaton) 1.5 Approval of previous minutes [Minutes of 2017-09-06 Meeting#1 (Inaugural)] (Co-Chair Keaton) 1.6 Review of action items and resolutions (Secretary Hagen) 1.7 Identification of SARIF TC voting members (Co-Chair Cartey) 1.7.1 Prospective members attending their first meeting 1.7.2 Members attaining voting rights at the end of this meeting 1.7.3 Members losing voting rights if they have not joined this meeting by the time it ends 1.7.4 Members who previously lost voting rights who are attending this meeting 1.7.5 Members who have declared a leave of absence 2. Future Meetings 2.1 Discuss future meeting schedule (Co-Chair Keaton) The following list is proposed as a starting point. This takes us just over half way into the expected SARIF schedule, and then provides for a face-to-face meeting where the remainder of the work can be planned. Teleconferences (Wednesdays 09:30 Pacific): September 27 October 11 October 25 November 8 November 29 December 13 January 10 Face-to-face meeting: January 22-23 (possibly Phoenix?) 3. Selection of Working Draft 3.1 Acknowledge contributions and review any new contributions (Co-Chair Keaton) 3.2 Vote to select a working draft (Co-Chair Keaton) Reminder that this is the starting point for further work, not the end point. 3.3 Reminder to read the working draft for discussions beginning at the next meeting (Co-Chair Keaton) 3.4 Procedures for issue tracking and revisions to the working draft (Editor Fanning) 4. Adopt Driving Principles 4.1 Discuss what principles will guide the work (Editor Fanning) Suggested approach: refine, add to, or subtract from the following list SARIF is primarily designed to advance the industry by providing the best direct production format possible. Aggregating results from other formats is another important scenario but secondary to direct production. SARIF defines a range of data that shall be expressed in order to best support static analysis tooling. Our specification describes a JSON implementation of this standard. It should be possible to define other implementations (such as XML). SARIF is designed for static analysis tools and any concept that generally applies for this scenario shall be considered for the format. SARIF can clearly be used for many dynamic analysis scenarios and we should consider augmenting the format for this class of tooling, but not in cases where what is proposed is applicable to the dynamic analysis domain only (excluding static). If a motion is made to adopt the principles as amended, consider the motion. 5. Other Business 6. Resolutions and Decisions reached (by 10 minutes prior to scheduled meeting end) 6.1 End debate of other issues by 10 minutes prior to scheduled meeting end and follow the agenda from this point (Co-Chair Keaton) 6.2 Review of Decisions Reached (Secretary Hagen) 6.3 Review of Action Items (Secretary Hagen) 7. Next Meeting 8. Adjournment
David: No objections. Agenda approved unchanged as published.
David: No objections. Minutes approved unchanged as published
Laurence: I move to approve the list of meetings. Kevin seconds.
Laurence: asks if possibly Phoenix or definitively?
David: clarifies, the motion fixes only the list and the idea of a face to face, not yet who will pay for the venue etc.
Yekatarina: asks if a shift to a different week day than Wednesday would be ok
Some mention, that Fridays would be better
Yekatarina: could be available Wednesdays in part only
Some suggest meeting earlier on Wednesdays to accommodate
Suggested currently possibly 08:30 PDT (15:30 UTC)
Stefan: suggests a doodle for long term and next week like a compromise
Stefan I move to amend in that sense
no objection to meet one week from today same time and have a doodle poll for remaining times
Two members signal problems joining next week
David: asks if October 11 would be an option? Yekatarina still has an issue?
Yekatarina: could join, if meeting one hour earlier
David: asks if one hour earlier next week
Two members have problems with next week (still)
Yekatarina: possibly not present next week then.
David: suggests to continue with the motion to amend a doodle for long term and next week like a compromise
no objections we will meet September 27 at the same time
A doodle poll for the remaining meetings will be set up after the meeting
Motion as amended is to meet next week at the same time
no objections the motion carries
Update after the meetingThe doodle poll https://doodle.com/poll/khs54abdxfvmdgpa has been created and the URL distributed on the TC mailing list on "Mon, 25 Sep 2017 04:13:12 -0700 (PDT)": https://lists.oasis-open.org/archives/sarif/201709/msg00026.html
Michael: I move to chose the contribution from Microsoft (the single one) to accept as first working draft. Laurence seconds.
no objections, unanimous consent, the contribution has been approved as first working draft candidate
David: Reminder that this is the starting point for further work, not the end point.
Laurence: has transcribed the HTML input into the provided working product format from OASIS which he will subsequently post to the kavi
Update after the meeting Laurence has uploaded the starter document including the transcribed contributed content as https://www.oasis-open.org/committees/download.php/61618/sarif-v1.0-wd01.docx.
Michael: shares his screen and walks all through the proposed workflow and thanks the OASIS administration for the timely provisioning of a github hosted TC repository
Robin: Issues now: https://github.com/sarif-standard/sarif-spec/issues
Stefan: New target repo is: https://github.com/oasis-tcs/sarif-spec
Suggested approach: refine, add to, or subtract from the following list:
- SARIF is primarily designed to advance the industry by providing the best direct production format possible. Aggregating results from other formats is another important scenario but secondary to direct production.
- SARIF defines a range of data that shall be expressed in order to best support static analysis tooling. Our specification describes a JSON implementation of this standard. It should be possible to define other implementations (such as XML).
- SARIF is designed for static analysis tools and any concept that generally applies for this scenario shall be considered for the format. SARIF can clearly be used for many dynamic analysis scenarios and we should consider augmenting the format for this class of tooling, but not in cases where what is proposed is applicable to the dynamic analysis domain only (excluding static).
If a motion is made to adopt the principles as amended, consider the motion.
Michael: walks through the suggested principles (listed above)
Henny: suggests if one could add more positive ("safe") results as type - which could contradict the results of other heuristic tools, but this could assist in triaging in case of conflict
Michael: thinks this is an interesting and welcome suggestion.
Laurence: discusses details on positive results as observations
Michael: continues listing the present means of the SARIF draft to contain and purport characterizations
Laurence: adds, that the target architecture e.g. where the rule was in some run not tested against, could not be purported - issues to track this will be added
Jim: adds that metrics and other info might need structure added?
Michael: seconds that as a good thing to discuss
Kevin: metrics are hard to produce
All discuss pro and con of introduction of new top level objects (complexity vs. clients needing to grab to much in property bags)
Jim: suggests to support more than just CWE taxonomies - maybe a generalisation to apply additional labelling to some weakness
Kevin: agrees with Jim
Laurence: proposes another principle. In the past he opposed to CWE because of not being domain agnostic, but generalising CWE (idea from Jim Kupsch) could be very good way to go
Luke: suggests to offer in any case a consistent way of storage inside SARIF, so we do not end up with the same kind of info added in two different ways
Luke: also talks on optional features in SARIF
Luke: asks if groupings as sets of optional features have been considered?
Laurence: states, that this has been considered, it was in an annex, that was removed some time ago; he thinks of profiles as the way to resolve this
Michael: suggests to put this also on the list for discussion
Yekatarina: suggests to in any case generalise - people use different taxonomies and the mappings among them may be off topic for the format
Kevin: thinks it's important to consider the targeted users... and what features/functionality may most resonate with them
Michael: wraps up the multiple CWE suggestions wighted against parsing complexity issues
Henny: likes the idea of generalising the taxonomies considered; based on C-Standard Kestrel already has such a taxonomy in use
Michael: thinks this is doable, and adds it as important to for any introduced "placeholder" there must be a concise notion (so this does not blur the semantics, thus no ambivalence in where to store what is introduced)
Michael: Sample: Memory Safety Taxonomy
Jim: thinks it would be nice, if we could represent CWE, Memory Safety Taxonomies, etc. inside SARIF so no one needs to repeat them in full and in parallel to provide
Laurence: likes the generalised taxonomy idea, and within providing explicit support for well-known ones. He still offers, that the format should be domain agnostic
Kevin: agrees with Laurence
Stefan: Time-check (invitation set to 90 minutes, but call planned for 120)
Henny: suggests we clarify what it means, when we agree on some taxonomy representation in SARIF, if semantics are included or if we only provide a stiff container without semantics
Laurence and Michael: are in favour of including the semantics applicable - so meaning should always be associated in some way
Michael: mentions many possible rankings as driving principle, to minimise any ranking display / storage as to reduce the noise and focus on the core facts (that do not change too much)
Laurence: moves to postpone decision to a later meeting
Michael: has collected notes and will combine with the minutes to produce suggested principles for the next meeting
David: Suggests to meet every other week
All: Next meeting will start 2017-09-27 16:30 UTC with a duration of 2 hours
No other business
The meeting was adjourned at 17:59 UTC.