Open onetwopunch opened 3 years ago
Thanks Ryan! Ya at the least we should make it clear in the instructions. Although we should probably rethink how that mark is applied. Do you have cycles to do any of this? Thanks again for your help with this.
On Tue, Nov 17, 2020, 5:44 AM Ryan Canty notifications@github.com wrote:
In a bare installation where no findings are configured, SRA will still add the sra-remediated mark on findings. This is happening because the mark is added in the Router after a message has been published to the automation, but if the automation is not configured (i.e. if the user just copies the yaml as directed) they will see all supported findings marked with sra-remediated even though the remediation hasn't happened. This is not only confusing but can give a false sense of security if the user doesn't fully understand how to configure SRA.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/security-response-automation/issues/197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXRKKQID3AUZWFOZ4HQRSDSQKK4VANCNFSM4TYXVFOA .
Yeah I'm almost done with the Filter PR and then I can take this piece on.
CC @konradschieban
Setting a finding as remediated must also respect the dry_run
configuration for each remediation.
In a bare installation where no findings are configured, SRA will still add the
sra-remediated
mark on findings. This is happening because the mark is added in the Router after a message has been published to the automation, but if the automation is not configured (i.e. if the user just copies the yaml as directed) they will see all supported findings marked withsra-remediated
even though the remediation hasn't happened. This is not only confusing but can give a false sense of security if the user doesn't fully understand how to configure SRA.