Tasks are a guided workflow for creating manual overrides for violations that may affect the allowed or not allowed status of releases in your catalog.
Tasks only appear when enabled for a specific standard
For each standard, you can configure whether to create a task to review violations of that standard. Create tasks only if you want to reliably and regularly review all violations of the standard.
Without tasks, you can still view the violations (for example, they show up in reports or on the package page). Tasks are only needed if you want to manually confirm whether to allow releases based on each specific violation of the standard.
To create these manual review tasks for yourself, check "Create a task to review releases" in the standards configuration.
Tasks will only appear when an override could change the status of a release in your catalog
If you choose to create tasks, they only appear when the allowed or denied status of a release in your catalog could be changed by completing the task. This is because completing a task creates an override — you are choosing to override what decision your standard configuration would make on your behalf.
This comes up in two common cases:
1. If a violation (such as a vulnerability) doesn't affect any release in your catalog, then there's no task.
We would not send you a task to review for every single vulnerability in the world — that would be a lot of tasks! We would only send you a task for a vulnerability that violates your standard configuration on a particular release — if the release is in your catalog.
2. If a violation only affects releases that already have a "not allowed" override, then there's no task
The second case arises for example on certain releases that have lots of vulnerabilities. Initially, you would see tasks for all the vulnerabilities on the release. But if you review the task for one of the vulnerabilities and create an override manually disallowing it in your catalog ("No one at our org should use this release!"), then the rest of the tasks will disappear as well, because you've already made the decision that the release is not allowed.
This screenshot below shows an example of a release where this would come up. Because CVE-2022-42003 below has a manual override to "not allowed," this release would not lead to tasks for the other 5 vulnerabilities, because even if those vulnerabilities were all manually allowed the denial override on CVE-2022-42003 would still deny this release. However, if you click "Delete" on the override for CVE-2022-42003 then tasks would re-appear for all six vulnerabilities, because the tasks once again have the potential to make a difference in the release's status.
The overall status of a release will be set based on your standards and your manual overrides. In the above screenshot you can see that one medium-severity vulnerability would allow the release by configuration, while the five high-severity would deny the release by configuration. CVE-2022-42003 has a manual override confirming that the release should not be allowed. Any "not allowed" decision results in an overall "not allowed" status.
You could still choose to manually create overrides for all of the vulnerabilities if desired, but they no longer appear in the guided task workflow because they cannot affect the allowed/not-allowed status of any releases in your catalog.