Hey, thanks for your feedback.

Right, Policy Reporter currently only detects new events, not really changes or removals. Thats why it doesn't update stuff in e.g. Security Hub.

I could try to implement it but it will never be 100% accurate, the problem is when the pod restarts or you do e.g. an upgrade. In this cases Policy Reporter doesn't have the previous state and don't know when a resource in between changed or was removed. This is something you could keep in mind.

@fjogeleit in this case, maybe fields like titles itself could've be potentially configurable?
What do I mean by that - in my case I can see potential combination usage
${rule_name}-${namespace} as for the title, and if new events would just update it - that would be great. Otherwise I will receive a lot of potentially old messages and have their in my system which wouldn't be efficient for further analysis.
I am not so sure if in case if titles are actual keys to update to - that's specification of API which may be needed to be checked, but I guess in case if people would be able to specify actual key ( override ) by themself that would remove additional frustration on further maintenance.
In my case, I have also added customField to stand for cluster name, so I can have combination done in a manner
${cluster_name}-${rule_name}-${namespace}
Maybe there're other possibilities, maybe somebody would want to have it different. There's a potential to build your own integration of a such with the Webhook integration usage, though, I assume it would be much more efficient and less frustrating to have such a possibility to be built in initial SecurityHub integration.

Thanks for your feedback, I will see if theres something I could improve.

Current state hardly would've be usable in scale in case if there's a bigger cluster and lots of policies violation ( which shouldn't be, but lets assume somebody just added new integration and now they've 1000 events where each is unique, generated - and they will continue to stream, some of these will naturally become outdated )
Maybe having possibility even to specify event key title, if title is actual key in security hub, per namespace, might be handy ( for some use cases, where kube system is treated different from other namespaces )

In generell the key is a combination of name/namespace/policy/rule and it should not create multiple events for the same violation. Not sure which impact the Title have. Admittedly I don't have much experience with SecurityHub because I am not a AWS user at all.

I can still try to provide an webhook call for resolved violations but as mentioned it can't be 100% accurate but enough to reduce to much outdated entries.

@vponoikoait @riramalho

I implemented a first version of cleanup handler.

In case of SecurityHub, PolicyReporter will fetch the current findings for a given resource and check which are no longer be part of the policy report, in this case the finding will be archived.

The current implementation can have the following drawbacks:

• I reached an API request limit for the GetFindings API, this can happen because it needs to fetch findings per report, its not possible to search for multiple reports at once. I added a configurable delay between report handlings.
• While it will update findings for changed resources between a PolicyReporter downtime, its not possible to update findings for resources which where deleted during a PolicyReporter downtime.

Any feedback is welcome.