I like the idea, but checkov seems to have the same problem as most TF code scanners: it assumes it can see ALL of the terraform for your ENTIRE deployment. For modularity reasons, that is basically never the case. As a contrived example, if I create an aws_s3_bucket without setting up a log, it flags it. But, and again, this is contrived, maybe this is because I have a single "logging" repo where I set up a bucket for logging, and then add in a data source reference for every s3 bucket in my other repos with the logging stanza in that repo. That is definitely modular, but in a bad way, I agree. But it illustrates the point: for reasons of modularity, the things checkov needs to see might be in another code repo that it cannot see. So, could be useful for catching things, but would be a nightmare in CI. Death by a 1000 exceptions. Need to dig more deeply; maybe checkov has some inline options to ignore specific findings, such as putting the finding to ignore in a comment field above the stanza that would trigger it. Regardless, these are great videos! Been watching some of the AWS ones. I am OG/oldschool; I don't want to just learn how to press the buttons as most videos "train" you to do. I want to understand how it works and then assemble what I need from that understanding. Your videos go a LONG way towards that. Many thanks for putting this out here!
Most of these types of tools will include a way of suppressing. For Checkov, this is how you could do it: www.checkov.io/2.Basics/Suppressing%20and%20Skipping%20Policies.html But agreed, and this is also an issue with many CSPMs or other tools like that as well that scan and look for certain settings. ie: maybe we don't have a strong password policy in an account because we don't allow passwords to be created in the first place, yet the CSPM will ding you for it 😅. Most static analysis tools require quite a bit of upfront configuration before they become helpful, and a common mistake is folks will immediately deploy them to the entire team and flood them with noise instead of fine tuning and testing first, then rolling out.
Quick and informative. Thank you.
Glad you liked it! Thanks for the comment
Insightful walkthrough. Thanks
Glad it was insightful!
please make a video on Terraform.🙏🙏 pleeeease
I like the idea, but checkov seems to have the same problem as most TF code scanners: it assumes it can see ALL of the terraform for your ENTIRE deployment. For modularity reasons, that is basically never the case.
As a contrived example, if I create an aws_s3_bucket without setting up a log, it flags it. But, and again, this is contrived, maybe this is because I have a single "logging" repo where I set up a bucket for logging, and then add in a data source reference for every s3 bucket in my other repos with the logging stanza in that repo. That is definitely modular, but in a bad way, I agree. But it illustrates the point: for reasons of modularity, the things checkov needs to see might be in another code repo that it cannot see.
So, could be useful for catching things, but would be a nightmare in CI. Death by a 1000 exceptions.
Need to dig more deeply; maybe checkov has some inline options to ignore specific findings, such as putting the finding to ignore in a comment field above the stanza that would trigger it.
Regardless, these are great videos! Been watching some of the AWS ones. I am OG/oldschool; I don't want to just learn how to press the buttons as most videos "train" you to do. I want to understand how it works and then assemble what I need from that understanding. Your videos go a LONG way towards that. Many thanks for putting this out here!
Most of these types of tools will include a way of suppressing. For Checkov, this is how you could do it: www.checkov.io/2.Basics/Suppressing%20and%20Skipping%20Policies.html
But agreed, and this is also an issue with many CSPMs or other tools like that as well that scan and look for certain settings. ie: maybe we don't have a strong password policy in an account because we don't allow passwords to be created in the first place, yet the CSPM will ding you for it 😅. Most static analysis tools require quite a bit of upfront configuration before they become helpful, and a common mistake is folks will immediately deploy them to the entire team and flood them with noise instead of fine tuning and testing first, then rolling out.
Thanks