Current End-to-End SARIF consumption MVP scenario

[Michael Fanning <Michael.Fanning@microsoft.com>]

Hello, everyone,

 

Thanks to some help from Ed, I recovered the end-to-end scenario that weâre actively engaged in. ð Iâd copied it to a Slack channel (since thatâs persisted for me, as Zoom comment threads are not).

 

Despite the specifics of a GHAS integration + CodeQL as a SARIF-generating tool, a lot of our progress here should generalize. i.e., just replace âGHASâ with âout-of-band analyzer/SARIF result storeâ and âCodeQLâ with âSARIF-exporting toolâ.

 

This scenario does have a concrete goal of actively exploring (and driving improvements into) the UX for working with complex findings that produce code flows.

 

As mentioned in the call, MS will be leveraging this scenario definition to render some internally generated fuzzing results. Sounds like we could possibly explore a results retrieval/overall experience with Nathanâs system (which provides crash details).

 

For completeness, we also have the Semmle/CodeQL legacy LGTM system to explore (MS has an instance of this internally) and MS will look at a parallel effort for Visual Studio. I suspect we actually *will* invest in the latter, as VS support for maintaining code location fix-ups in SAST results during code authoring looks to be ahead of where VS Code is at (item #6 below).

 

Thanks! If this sounds interesting to anyone and youâd like to be on the next Zoom call to see progress, deepen discussion, let me know,

 

MCF

 

Working branch for VS Code exploration.

microsoft/sarif-vscode-extension at ghas (github.com)

 

### End-to-End MVP scenario
1. Developer opens a folder within VS Code that maps to a GIT (GitHub) repository/branch for which GHAS code scanning is enabled.
2. Developer receives a VS Code pop-up reporting that GHAS CodeQL SARIF results are available.
3. SARIF viewer retrieves and renders CodeQL results within the IDE.
4. Developer effectively reviews various CodeQL issues, including complex results with code flows that span multiple files, etc.
5. Developer makes a fix to resolve one or more issues, and marks them as presumed fixed, removing them from the viewer.
6. As files are edited, SARIF viewer maintains accurate source locations for remaining issues, allowing the developer to continue to review results and make fixes.
7. Developer pushes changes to the branch.
8. Developer is notified of new CodeQL results, when available, and refreshes the viewer.
9. SARIF viewer clears stale results and loads new (if any). (edited)