OASIS Static Analysis Results Interchange Format (SARIF) TC

continuing the discussion from today's meeting

  • 1.  continuing the discussion from today's meeting

    Posted 03-25-2021 16:24
    Hi all,   I kept postponing making comments during the meeting, until we ran out of time :) So, I am gonna jot them down in an e-mail, so I don’t forget them before the next meeting…   Micro Focus is one of those big commercial vendors referred to on the call, however we do understand the value of SARIF, and everyone at Fortify is bought into it. Most of our customers use several tools / vendors, so it makes perfect sense for us to support the standard. In fact, our developers are excited about potentially substituting our proprietary format with SARIF eventually, considering performance gains it could bring. But of course, it’s all a matter of priority, and, unfortunately, so far we’ve only implemented the ability to consume SARIF as opposed to produce it. But Alex Hoole and I keep pushing :)   Here are a couple of pieces of feedback I heard from within the organization regarding SARIF that we might want to consider in our TC discussions going forward:   Making sure that standards mappings and taxonomies work well within the standard. Better understanding of how the standard could help with migration issues, when results generated by older versions of the tools get migrated for the use with newer versions of the tools. There is still confusion about fingerprints / partialFingerprints, so perhaps adding more examples of when and how exactly each of those attributes should be used would be helpful. From our interaction with GitHub, it became clear that producing SARIF is easier than consuming it because other producers might have stricter (or more relaxed) usages of the standard (like it was in the case of GitHub), so is there a way to help with this? Finally, everyone at Fortify feels that extending SARIF to include dynamic results does not make sense: static and dynamic results have different attributes associated with them, and lumping both sets into one standard will make it overly complex and bloated. Instead, it makes sense to abstract the common attributes into a meta-standard, and then make room for plugging-in appropriate standards depending on the types of results in question. That way, we could support not just static and dynamic, but have the ability to support other types of analysis results.   Hope this makes sense.   Looking forward to working with everyone, k