Security mark added before remdiation takes place

[onetwopunch]

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.

[tomscript]

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 ***@***.***> 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 <#197>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXRKKQID3AUZWFOZ4HQRSDSQKK4VANCNFSM4TYXVFOA> .

[onetwopunch]

Yeah I'm almost done with the Filter PR and then I can take this piece on.

[onetwopunch]

CC @KonradSchieban

[daniel-cit]

Setting a finding as remediated must also respect the dry_run configuration for each remediation.