What is our primary use case?
It was adopted in response to the events of SolarWinds, where API credentials were leaked into Git repositories or other developer tools. We, at the time, had no detective or preventive controls to prevent this sort of disclosure, so CloudGuard Code Security was implemented into the pipelines themselves to detect secrets being disclosed.
How has it helped my organization?
We have had a number of real events where developers accidentally made commits of API keys, and we were able to detect and begin response actions in minutes. We had the API key revoked in less than five minutes in such events. If we did not have CloudGuard Code Security, we would not have known about it for who knows how long. There is absolutely a very meaningful difference.
CloudGuard Code Security is great for protecting our code and assets from exposed API keys, tokens, or credentials. It does exactly what is advertised, and it does it reliably. It is a great solution.
The scanning of code throughout development helps save developers time. One of the important attributes of the shift-left movement was getting developer feedback as quickly as possible to reduce cycle time and context switching. CloudGuard Code Security very much improves that by allowing the mistakes to be detected almost immediately and remediation efforts to be implemented. In terms of time saved from not having to redo problematic production code, context switching is about a 30-minute loss for most developers. Each incident is 30 minutes. Hopefully, it is infrequent. There are two pieces. There is secrets detection, which is not an efficiency play. It is risk mitigation because of the enormity of the impact that it could lead to. The other side of it is the configuration management side. That is where you do have ongoing feedback as people use TerraForm or other infrastructure as code languages, and getting that feedback to them quickly is certainly valuable. It saves a lot of time there.
CloudGuard Code Security helps identify high-risk security misconfigurations in our code during the development phase. On the merge event, for the infrastructure as code, it analyzes the configurations. It looks for known adverse configurations and comments on the merge request. It usually prevents the merge request from happening to begin with, and then you have a commit, which hopefully remediates the issue. It probably has had some beneficial impacts on product security, but it did not necessarily create new visibility that did not exist before. CSPM tools from Check Point give us visibility into adverse configurations, but we saw them later on or down the line, and we had to deal with making people go back and fix them, so I do not know if it had a massive change on the outcome, but it has impacted the efficiency of getting to the outcome.
CloudGuard Code Security has helped our development team adopt a security mindset. It keeps security on top of mind when dealing with infrastructure as code or secrets and ensures that it does not get lost or overlooked. If they are aware of security and it is on top of mind, hopefully, they will make better decisions.
The time taken by CloudGuard Code Security to scan our codebase depends on the size of the Git Repo, but on average, it is between ten seconds to a minute.
CloudGuard Code Security does not impede the development flow because the inflection point for the most part is on the merge request creation. In most organizations, especially if they are in any sort of highly regulated space, the creation of the merge request is usually followed by approvals from peers or partners on the merge before it is merged. With a latency of ten seconds to a minute, most of the time, approvers have not even opened the page before the contextually rich security information is already there waiting for them to make a good decision. So, it does not impede the development flow at all. It just means that the approvers have the ability to make rich decisions with all of the information already laid out for them.
What is most valuable?
Secrets detection is the bread and butter.
We have used the infrastructure as code as well. It was really early in the market and had comprehensive coverage across Terraform, cloud formation, and ARM. We used that as well but not as heavily. It was more of an ancillary benefit.
What needs improvement?
There are a lot of opportunities for how they can use their technology to do more. That would be more like sensitive data discovery and other things besides Git Repos, but then you are expanding the scope of what necessarily their product is. If we talk about what problem we are trying to solve, which is secrets disclosure, perhaps even validation of configuration management inside of Git environments, it is a very comprehensive solution. It is what it is, and it does a great job.
For how long have I used the solution?
We have been using CloudGuard Code Security for three and a half years.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
It uses Lambda as its backend, so it is really a question about the scalability of AWS, which is bulletproof.
It is integrated into our Git Repo, so it is a Git-level control. The users of Git exist across locations, departments, and knowledge domains. It is a universally applied control irrespective of the employees. It broadly affects any user of Git across the company.
How are customer service and support?
When we first launched this, it was a brand-new product, and there was very hands-on support. We had a couple of issues that they worked through very effectively and efficiently. They were super responsive. For the last two years, I have not talked to their support at all because it has just worked.
We have got great service from Check Point. I would rate them a nine out of ten.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
We did not use any other solution previously.
How was the initial setup?
The deployment was very fast. It probably took my team a day to wire in the integration with the Git side. We did a little bit of SOAR work to make sure our response was efficient. It was a very quick and painless setup.
In terms of the deployment model, it is a webhook from a Git Repo into a Lambda function hosted in our AWS account that scans and then replies back. That would be considered a self-hosted public cloud.
It was very simple. It was done three years ago. I am sure things have changed, but at the time, it was a cloud formation stack set that was deployed into an account, and then there were a couple of configuration pieces in Git Repo where you need to point the webhook to the Lambda function you have stood up, and that was it. You were done. I imagine there is a slightly different process today for CloudGuard Code Security than three years ago. It is probably a little bit more fully managed on their end today, but I do not know that for sure.
What about the implementation team?
We did not take any external help. It was very easy.
What was our ROI?
The thing we are trying to stop is a really bad SolarWinds type of event, which would cost an organization millions of dollars, so the ROI is preventing that outcome. It is a risk mitigation play. There is not necessarily a strong ROI from a non-event.
What's my experience with pricing, setup cost, and licensing?
It is extremely affordable and high value for cost.
Which other solutions did I evaluate?
When we bought it three years ago, as far as I know, there were no other options. This was the first to market.
What other advice do I have?
To those evaluating CloudGuard Code Security, I would advise doing a PoC. It is easy to integrate. It takes a day to get it all set up and working. Do some testing on merging things that you know would be bad and watch what happens. The product sells itself.
I would rate CloudGuard Code Security a ten out of ten.