feat: Add impact and resolve fields in sarif output.

[ipapast]

CC-517

• Ready for review
• Follows CONTRIBUTING rules
• Reviewed by Snyk internal team

What does this PR do?

This PR adds the 'resolve' and 'impact' fields in the results of the sarif output in order to give more useful information to the users and show that to the Github Security page (coming from the registry's AnnotatedIssues object).

Where should the reviewer start?

Check the two new fields in `iac-output.ts. The resolution is added to the 'help' field and the impact is included in the full description.

How should this be manually tested?

• Run iac test --sarif and see the results

• Check Github Security

Any background context you want to provide?

We are using the reportingDescriptor object, more info on the docs here Github Security SARIF Docs

What are the relevant tickets?

Jira CC-517

Screenshots

CLI Output:

Github Security:

[aron]

This is fantastic, I think now seeing the output in the GitHub UI, the description isn't the best place for the impact.

The help field where we show the resolution looks like a better spot to put all of this information and describe to the user the issue, impact and resolution as we do in the Snyk UI.

What do you think?

[aron]

Nice, looks fantastic. I think it might be easier to keep the nice template literals but to trim the leading whitespace from each line with a replace() function.

[aron]

We're going to have the same issue here as we had with the markdown. The string is going to look like:

The issue is...
        ${issue.iacDescription.issue}

        The impact of this is...
        ${issue.iacDescription.impact}
        
        You can resolve this by...
        ${issue.iacDescription.resolve}

[ipapast]

Correct me if I'm wrong, but my understanding is, that if the markdown field exists, then the sarif output will display that. The text field is only mandatory if the markdown field does not exist.

In this case, I think we can even have an empty string as a text field and the output would still be the same.
In summary, I think the best thing is to do is to display text: ' ' and then markdown as we have already formmated it.

[aron]

As you have it is absolutely fine, we want both as it means that the content can be output anywhere as plaintext but also enhanced as markdown if the client understands it. All I meant by my comment was that the plain text version is going to be indented after the first line. Imagine if this Sarif file was printed by a command line tool as plain text to the terminal, it would look odd if the first line of subsequent sections were indented.

Lets chat if this still doesn't make sense :)

[ipapast]

Sorry for the back and forth - I was talking for the specific purposes of Github Security display and you were talking about the case of the plain output. I get you now :) I'll do that change now

[ipapast]

Updated the original PR comment with the most updated screenshots for any future reference.
Added a replace function to the help fields.
Squashed the commits and will merge as soon as the checks passed.

[github-actions]

Expected release notes (by @ipapast)

features:
Add impact and resolve fields in sarif output. (bb2a470)

• I hereby acknowledge these release notes are 🥙 AWESOME 🥙

[snyksec]

🎉 This PR is included in version 1.437.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀