You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently PSRule supports suppression by name within options or by using a suppression group. These suppression options are typically set within the repository where the infrastructure as code lives.
For sensitive pipelines having more control over what can be suppressed and how that suppression should occur is helpful.
While we could provide a global disable suppression switch, many pipelines may need some level of suppression so more granular options are required.
Choice of how rules are suppressed
Suppression in ps-rule.yaml is quick and works for common cases, a YAML comment as the reason for suppression can be added also is not checked or enforced in anyway. Making this enforced might be challenging.
Suppression groups provide a powerful alternative way to suppress by a condition, and also provide an optional synopsis which can be used to describe the reason for the suppression. This synopsis is output during a PSRule run by default as a justification / reason why the suppression exists.
Because both of these methods are not equal the choice to one, both or the other would provide some additional controls.
For example:
execution:
suppressionByName: false # Ignore suppression set by namesuppressionByGroup: true # Process suppression with suppression groups
These control by themselves only minimally harden the pipeline.
execution:
suppressionReason: Error # Generate an error if a reason for the suppression is not set (applies to suppression groups)suppressionExpiry: Error # Generate an error if a suppression group does not have an expiry.
Unsuppressable rules
Consider also allowing rules to not be suppressed.
Currently PSRule supports suppression by name within options or by using a suppression group. These suppression options are typically set within the repository where the infrastructure as code lives.
For sensitive pipelines having more control over what can be suppressed and how that suppression should occur is helpful.
While we could provide a global disable suppression switch, many pipelines may need some level of suppression so more granular options are required.
Choice of how rules are suppressed
Suppression in
ps-rule.yaml
is quick and works for common cases, a YAML comment as the reason for suppression can be added also is not checked or enforced in anyway. Making this enforced might be challenging.Suppression groups provide a powerful alternative way to suppress by a condition, and also provide an optional synopsis which can be used to describe the reason for the suppression. This synopsis is output during a PSRule run by default as a justification / reason why the suppression exists.
Because both of these methods are not equal the choice to one, both or the other would provide some additional controls.
For example:
These control by themselves only minimally harden the pipeline.
Unsuppressable rules
Consider also allowing rules to not be suppressed.
For example:
The text was updated successfully, but these errors were encountered: