Ask the experts: Mitigating risk in securing cloud environments

Cloud environments are the future. In fact, Gartner estimates that over 85% of organizations will embrace cloud-first strategies by 2025. And it’s for a good reason – cloud environments put flexibility and efficiency at the forefront of the development process. However, the shift to the cloud comes with new risks and attack surfaces. Organizations planning to move to the cloud must prioritize security across all teams. 

Recently, I was joined by Aron Eidelman, AWS, and Alex Rice, HackerOne, to share some lessons learned and tales from the trenches of our experience securing cloud environments. Let’s walk through the three biggest takeaways from our conversation. 

Determine security ownership early on

Moving to the cloud provides many security benefits, including superior visibility and control, risk-reducing automation and access to experts who monitor systems. However, says Eidelman, in order to make the most of the additional flexibility provided by the cloud, customers still have a responsibility to run their own security programs. This is not just a matter of technical accountability. It also ensures that companies build a culture that focuses on security. Typically, the most friction is generated by a company’s security processes, rather than by technical challenges. 

Developer teams are trending toward taking on significant security responsibility. GitLab’s 2021 DevSecOps Global Survey found that over a third of developers surveyed feel fully responsible for security in their organizations, up from 28% last year. This puts developers under significant pressure to ship code rapidly, while also prioritizing security. However, while security is becoming more and more the responsibility of the developer, it is still very much a team sport. 

Open source is only as secure as your team

There’s incredible positive potential for the use of open-source security tools. It’s clear that any attempts to try to stem the usage of open source is a losing battle. Using open-source tools can seem counterproductive to security professionals, who understandably have a natural inclination to control and audit which tools are being used. However, open source can be critical for identifying and assessing the impact of exploits. 

When considering a new tool, it’s critical to carefully assess which tools you’re using. Be sure to answer the following: Who is responsible for maintenance? Are they reliable? Are we supporting their funding source? Rice notes that teams should take this opportunity as a checkpoint to clarify who is responsible for what. Open source is not going away – it’s only as secure as the developers on your team. 

Automation is a tool, not a replacement

Human security professionals and automated security tools are often mistakenly positioned as rivals. Though it can seem like they’re at odds, automated tools should be treated as supplements to human security experts, not replacements. After all, automation doesn’t exist without a human feedback loop.

Automated tools are critical for completing repetitive, simple tasks at scale, setting security baselines, and identifying anomalies. This takes some of the pressure off of human security experts, who are then free to conduct proactive security scans, and identify and fix more complex and nuanced security vulnerabilities. 

For more on managing security in cloud environments, be sure to check out GitLab’s webinar, Mitigate Risk in the Cloud with Ethical Hackers and DevOps, in partnership with AWS and HackerOne. 

Cindy Blake is director of product marketing at GitLab.