Vladi is the Co-Founder and CEO of Lightspin, a company that helps cloud and security teams remove risks in their Kubernetes and cloud settings.
I recently spoke with a CISO at a large FinTech firm which stated that everything they do is focused on time-to-market. This is echoed by the 63 percent of CEOs who say that cyber risk is slowing companies down and harming company growth.
Of course, the emphasis on speed is unsurprising. We all want value right now. This technique could be an excellent way to understand the changes we're witnessing in cloud security, which I thought intriguing to ponder.
Security Tools Are Coming To The Rescue Too Late
Consider this scenario: If you were preparing a cake and accidentally used salt instead of sugar, when would the best time to discover this be? While you're still preparing and combining the ingredients, or after the cake has been plated and presented to your guests?
The answer is simple, yet many enterprises still rely on cloud workload protection platforms for cloud security. Unfortunately, these can only detect security flaws after the intruder has already entered your environment. And it will be too late by then.
Why wait until production starts generating notifications and alerts when all of the problems begin at the deployment stage? The attacker has gained a foothold and maybe moving laterally across your network at this time.
Make It Easier On Yourself By Shifting To The Build
There's no denying that security and DevOps have a long history together. The balance between creativity and caution will always be a difficult one to strike. DevOps may be accused of forsaking best practices for the sake of speed, whereas security may be charged with requesting a new deployment as a result of a false positive.
Only 30% of organizations presently take "cross-organizational initiatives to drive a business-led approach to digital risk," according to a recent Gartner report (via Industry Week). In contrast, when teams can join together and function as a unit, we can see actual results in terms of risk reduction.
That's why cloud security should be included as early as feasible, not during deployment (and certainly not during production), but the development phase. It will always be more challenging to get DevOps to handle security vulnerabilities that are reported during the deployment stages. It's like trying to pull every last grain of salt out of that mixing bowl and replacing it with sugar.
DevOps may far more efficiently address a problem if it is discovered during the build stage. It's akin to informing the chef that they grabbed the wrong ingredients when cooking the dish. DevOps is already in troubleshooting mode at this stage. There are already technological issues to address, so adding security chores to the mix isn't a big deal.
Misconfigurations and vulnerabilities, such as resource and limit issues or any other defect in the code, are added to the list. Allowing Dev teams to add security parameters to automated unit tests, for example, is an example of a process change. As a result, security checks are simply one of many DevOps tasks to complete before a product or update is ready to go live.
Put DevOps And Security On The Same Team
This strategy provides a lot of additional advantages in addition to speeding up secure deployment. First, mitigation and policy enforcement is easier to implement during the construction phase. Second, you're not interfering with DevOps' job once they believe it's over, and you're allowing security to be more than simply an afterthought for DevOps.As a result, the link between the two teams is strengthened and improved, allowing them to work as a cohesive unit.
It also shifts the conversation away from after-the-fact cloud workload protection technologies and enhances overall cloud security posture management. As a result, your cloud environment is more secure, your teams are happier and more collaborative, and you have a faster time to market for new features and releases.