Add support for code suppression fields

[z4ce]

This changes the issue count, adds a card for suppressions, and also moves any suppressed issues to the end of the list.

• Tests written and linted ℹ︎
• Commits are squashed and tidy and are suitable to become release notes

What this does

Customer with code consistent ignores and who are using snyk-to-html want to see the fact they have ignored things be reflected in the snyk-to-html output. This PR does three things:

1. Displays a card on each suppressed vulnerability showing the details of the suppression
2. Modifies the issue count to remove suppressed issues from the count
3. Alters the order of the displayed vulnerabilities such that suppressed issues are always at the bottom

Notes for the reviewer

Instructions on how to run this locally, background context, what to review, questions…

More information

• Link to issue

Screenshots

Visuals that may help the reviewer

unified-ignores.html.zip

[thisislawatts]

issue: We should add explicit fallback values here for each of the optional values. This would be particularly useful for the ignoredBy property which is an object we use in templates. For example:

ignoredBy: suppression.properties?.ignoredBy || {
  name: 'unknown',
  email: '?'
}

Alternatively we could return null for ignoredBy and then the templates should guard against this scenario by gating each ignoredBy.propertyName lookup with a #if suppression.ignoredBy

[thisislawatts]

suggestion: We only need to perform this sort option if one or more of the project vulnerabilities had suppression data. So we could skip this step if hasSuppressedVulns = false within the forEach loop.

Suggested change

	OrderedIssuesArray.forEach(project => {
	project.vulnerabilities = project.vulnerabilities.map(vuln => {
	if (vuln.suppressions && vuln.suppressions.length > 0) {
	vuln.suppression = processSuppression(vuln.suppressions[0]);
	}
	return vuln;
	}).sort((a, b) => {
	if (a.suppression && !b.suppression) return 1;
	if (!a.suppression && b.suppression) return -1;
	return 0;
	});
	});
	OrderedIssuesArray.forEach(project => {
	let hasSuppressedVulns = false;
	const projectVulns = project.vulnerabilities.map(vuln => {
	if (vuln.suppressions && vuln.suppressions.length > 0) {
	hasSuppressedVulns = true;
	vuln.suppression = processSuppression(vuln.suppressions[0]);
	}
	return vuln;
	});
	if (!hasSuppressedVulns) {
	project.vulnerabilities = projectVulns;
	return; // Early return if no suppressions
	}
	// Sort only if necessary
	projectVulns.sort((a, b) => {
	if (a.suppression && !b.suppression) return 1;
	if (!a.suppression && b.suppression) return -1;
	return 0;
	});
	project.vulnerabilities = projectVulns;
	});

[thisislawatts]

praise: This gating is good and will ensure our other customers do not get the information.

[thisislawatts]

suggestion: To better protect ourselves from introducing a regression we could add a guard assertion to one of our existing test cases to check that the output doesNotHave <div class="suppression-card"> in the output.

[thisislawatts]

question: Should this be namespaced under .suppression-card?

[z4ce]

@thisislawatts I thought I had pushed these changes a week ago.. I think this addresses everything we talked about