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.
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.