Consider adding bucketized 'justification' field for suppression object.

[michaelcfanning]

A suppression is a filter on an existing result. Although we have a free-form justification field for arbitrary textual descriptions of a suppression, this data isn't easily parsed/bucketed. We should consider providing a useful set of tags to help sort/differentiate suppressions. As with other areas of SARIF design, we should consider buckets that assist in routing information to specific actors in end-to-end result management systems.

ToolNoise for example filters a result because it comprises a false positive. The primary responder to this class of suppression is a tool vendor (with other actual code owners in a secondary role to guarantee the finding is, in fact, incorrect).

VulnerabilityNotFeasible designates a vulnerability that looks accurate on surface which can't be realized/exploited in production due to factors/context that aren't (or can't be) considered by the quality tool. The appropriate responders are other code owners to confirm a vulnerability does not impact production (with tool vendors in a secondary review role to look for opportunities to improve/refine analysis).

NotForRelease filters a result because it fired against code that doesn't ship (and therefore affords no quality/security risk). The appropriate responder/reviewer for this class of suppression might be an automation owner who can adjust tool configuration to not scan non-shipping code.

FixDeferred acknowledges a result as a true positive but simply requests time to resolve. The appropriate responders are security reviewers and leads accountable for prioritizing/scheduling work items.

RiskAccepted acknowledges a result as a true positive but definitively proposes not to act on it. Appropriate responders include security reviewers/leads accountable for signing off on quality + risk.

The buckets we create here will benefit from being a clear, minimal set than handle prominent routing/response use cases. It is possible, for example, that ToolNoise and VulnerabilityNotFeasible could be collapsed into a single FalsePositive designation. The rationale for preserving both is the distinction between the primary responder for the two cases (tool vendor vs. code owner).

[sthagen]

Suggest to Pascalize also the Nonshipping to ease use → NonShipping
→ has been renamed to NotForRelease 👍

[michaelcfanning]

From, Paul, add an 'external' or '3rd party' designation. Is it useful to differentiate 'off-team but within company' vs. 'dependency outside our organization entirely'?

Also from Paul, 'ToolMisconfigured'.

[schlaman-ms]

Document location for issue:

§3.35 suppression object
§3.35.7 justificationType (proposed)

michaelcfanning:

"We should consider providing a useful set of tags to help sort/differentiate suppressions. As with other areas of SARIF design, we should consider buckets that assist in routing information to specific actors in end-to-end result management systems."

Propose new justificationType property that SHALL have one of the following values:

• ToolNoise
• VulnerabilityNotFeasible
• NotForRelease
• FixDeferred
• RiskAccepted