Conditions are the rules that define the policy. Our policy rules architecture allows for conditions to be combined by using operators, similar to SQL. This allows for the creation of very simple or very sophisticated policies. The following are several examples of conditions and their purpose.
A single condition that will by triggered by any scan with more than 0 High severity vulnerabilities
A combined condition that will by triggered by any scan with more than 0 High severity vulnerabilities OR a CVSS3 score >= 6
A combined condition that will by triggered by any scan with more than 0 High severity vulnerabilities OR a CVSS3 score >= 6 but ONLY if the count of vulnerabilities that match are >=10. The Auto Adjust flag automatically reduces the condition value "10", to continually lowers the watermark for triggering this policy
Subordinate Conditions
Subordinate conditions are qualifiers and apply for all of the conditions contained in the policy. Like conditions, multiple subordinate conditions may be combined with AND/OR operators.
Each subordinate condition must be met for the policy to be triggered, even if all conditions are met. Note the following examples:
This is identical to the last example, above, except that this policy will not trigger unless the Release Stage is Production.
In this example, the Scope condition is set to "Component" which requires all of the conditions to apply to a single component vs being applied to all scan results.
Project tags ensure that your policy is only triggered for projects with the include tags.
Scope conditions apply to current and subordinate scope based on the context of the policy. Organization policies will apply to all entities and projects. Entity policies will be applied to projects for that entity and all projects of subordinate entities. Project-level policies will be applied to that project alone.
