This message was deleted.

and is anybody pivoting to run more checks after deployment (e.g., auditing) because you've run into issues trying to validate things against a set of static rules up-front

We use a combination of Checkov (Developer's IDE connected to Prisma Cloud Backend) + At CI stage, BridgeCrew (now Prisma Cloud Code Security) + TerraScan (for Custom tests)

For Clientside validation of Kubernetes we use CUE, it’s a config language with built-in validation so we don’t need another validator on top of this ref

I'm biased because I work at Harness.io - but one of the main reasons people choose Harness is because you can governern pipelines, steps and jobs with OPA and super granular situation based RBAC. Incl. Terraform jobs. There is also an overlay for ArgoCD, which have been crucial for the financial instructions we're working with.

We see a growing number of organizations using security test tools as part of this kind of flow, usually motivated by frameworks such as SLSA (https://slsa.dev) and architectural models such as the CNCF’s secure software factory https://www.cncf.io/blog/2022/05/20/announcing-the-secure-software-factory-reference-architecture-paper/ Also keen to talk to people who are interested in hooks for initiating and querying external security scanning/verification tools!

@Harry thanks! are you largely using CUE to check for proper Kubernetes configuration errors, or are there any application or vertical-specific compliance/security checks you've tried to implement? would you use a different tool to check for a new security policy your team wants to introduce?

@Tatiana Cooke We have implemented both security and compliance checks in our CUE libraries.

would you use a different tool to check for a new security policy your team wants to introduce?

Yes, we use a bunch of other tools too for scanning things after the fact. But if it’s a configuration level policy, we most likely default to adding it in CUE