Add a section on testing of Infrastructure as Code (IaC) about wstg

[adbrucker]

I believe that at the start, the project scope was broader - covering security testing more general. At this point in time, I created the issue, but sadly never had time to work on it. Given the development over the last six years, in which the guide developed a much more focused scope, I also agree that IaC testing (while being important), is out of scope.

[tek911]

Interested in possibly contributing to the project on this item.

[garthoid]

Sadly, this issue has been ghosted several times. This makes me sad. Therefore I will try.

[garthoid]

My question is this: If the section is to be "testing in a dynamic context" then how would this be different than other endpoints already covered in this guide? To me it is just another application / endpoint. How does IaC make it different? And if it is different how would all the forms of IaC be covered? Terraform, ARM Templates, CloudFormation, Helm charts, Dockerfile, Docker compose file and others, how would we consider testing different in these cases for the infrastructure?

If it is code review, then perhaps this question is better covered in ASVS? Or some other location if not here?

I have no opinion on this as I just want to help. But in terms of code review, I think it should be covered in depth somewhere other than a brief cheat sheet.

[victoriadrake]

Thanks @tek911!

[kingthorin]

@tek911 any news/progress?

[kingthorin]

@tek911 any news/progress?

[ThunderSon]

I believe this is safe to unassign as this the second call

This seems like an interesting topic that I would like to address. I can provide a more high level draft at first, but I consider it a pretty big topic. For example the first thing I could think of is accidentally exposed Kubernetes API, or being able to call it through the container.

If that fits you I will be happy to work on that.

[ThunderSon]

As it's a tremendous topic, let's go with what you're suggesting. We'll refine the first possible look for it and then let it grow :)

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 90 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[garthoid]

Continuing with the assumption that since this is about Infrastructure as CODE then we are reviewing and looking at code that builds infrastructure for security flaws. This should also include reference to open source tooling.

[kingthorin]

That seems reasonable to me.

@rbsec, @ThunderSon, or @adbrucker any other feedback or direction for @garthoid ?

[ThunderSon]

I wonder here, are we gonna be doing a code review, or are we gonna try to attack the setup that'll be created by IaC?
If it's the former, then I'm not sure we can fit it as a test guide, maybe more as an appendix. I don't think we should cover code reviewing in depth, especially for IaC. If this is the case as well, maybe this can be a better fit under the cheat sheet series project.
If it's the latter, then definitely happy to accommodate for it.

@garthoid let me know what you think about this here!

[rbsec]

My concern with this would be around scope. Because this is the web security testing guide, and if we're talking about infrastructure as code then it sounds like we might be getting somewhat out of scope.

I think you could argue that reviewing something like a Dockerfile could potentially be in scope, but even that's raising questions. Things like filesystem permissions, container versions and the user accounts that processes run under can certainly be issues, but they're much more on the infrastructure side than the web side. They're the kind of issues that you might find doing a build and configuration review of a server - which isn't something that we cover in the WSTG.

And when you move beyond that, it seems even more out of scope. Things like the Terraform used by build an AWS/Azure environment are potentially important, but they're very much infrastructure - because you're looking at issues like network design and segregation.

There's also the question of exactly what you would do as part of the web security testing guide. Are you just reviewing the code (because we don't really cover much on code review), or does it go beyond that into some more infrastructure testing.

The whole IaC and DevOps approach blurs the line between applications and infrastructure, and I'm not against the inclusion of something like this on principle. But I think there's a bigger question to consider about exactly what the scope of the WSTG should be, and where we draw that boundary.

Because if we're going to look at Dockerfiles and and Helm charts and Terraform, then why not the Apache configuration, or the Linux server, or the Cisco firewall it's connected to as well?

[ThunderSon]

I hear your thoughts.
I am in a similar flow as both of you.

I can't see IaC directly belonging into the guide without forcing it.

@kingthorin thoughts? If you're in agreement, I'm happy to close this ticket as out of scope.

An analysis can be done of some systems maybe that are at the basis of the infrastructure, and include them in tests (like instance metadata endpoints and IPs from cloud providers), or have an appendix. But IaC as a topic doesn't fit as a whole.

[garthoid]

I am interested in @kingthorin 's thoughts but I am aligned that IaC is out of scope for the WSTG. I will of course choose another ticket moving forward.

I have one questions though: Is there a project that covers IaC SAST in depth beyond the cheat sheets?

[kingthorin]

I don't have experience in this area. I'm quite willing to go with the majority which seems to be suggesting this is out of scope.

https://owasp.org/www-project-cloud-native-application-security-top-10/ might be a good fit however it doesn't seem to have moved much since 2021 per their project page.

It could also be something that's just developed and put in the OWASP community area: https://owasp.org/www-community/

[garthoid]

Then I move to make this item out of scope.