-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Return affected resource FQDN in results JSON #58
Comments
We've deliberately been baking in both project-id and resource name into the So the error messages should look like: Output jsons seem to have that information too, I can see it eg when adding the json to https://heimdall-lite.mitre.org/ |
OK, makes sense. So in that case, we can treat this as a standardized message, so we can parse it I guess.. |
Yeah we wanted the message to be descriptive enough to help investigations, so we're following this approach across all our profiles. |
The problem is, a lot of code messages don't follow this format or are not uniform across various controls though, for example:
So how do we parse it in a more general way, instead of having to create a regex for each control that's different? |
Why parse and not just share the message as-is? |
@binamov this is because we'd like to build additional automation around it, as explained :) I.e. we'd like to have a programmatic way to the findings that are machine-readable, as opposed to human-readable.. |
I'm not sure adding eg
inside of each describe, but still that |
@aaronlippold any thoughts on this? |
Hi guys, I would have to look at the describe blocks in question to dig in ... but it seems like the use of a The idea of using a rspec explicit subject - https://relishapp.com/rspec/rspec-core/v/3-9/docs/subject/explicit-subject - is to use the describe message as the 'context of the idea Secondly, using the more detailed rspec |
Hi Team,
We're trying to make sense of all of the CIS findings in some of our projects, and how to begin to address them.
Currently, to even identify the affected resources, all we have is a message like this:
As you can see,
{instance}
can only be identified programmatically by parsingcode_desc
message.It would be really helpful if, for each finding, the CIS benchmark also returned the FQDN of the affected resource:
This would allow us to quickly detect which resources are affected, and possibly set up some automation for it, which is much harder to do if all we have is a human-readable suggestion.
Thanks!
The text was updated successfully, but these errors were encountered: