Busting the Myths About DevSecOps
There are a lot of assumptions about adding security to cloud applications, including that there is only one right way to approach the DevSecOps process or that adding security will slow down development in the native cloud. But just because that’s been the way things were done forever doesn’t make it true. In fact, some of these myths surrounding cloud-native security could be setting back your overall cybersecurity efforts.
Speaking to a Check Point CPX360 audience, Micki Boland, cloud security architect at Check Point, set out to debunk those myths. Instead of believing that security slows down the DevOps process and adds more expenses to an organization’s overhead, rather approach it as code to get security from end to end.
“If you start thinking like a service provider, you can offer security-as-a-service to all of your stakeholders,” said Boland.
Popular Myths Around Cloud-Native Security
A DevSecOps security myth could be unique to your company—something that has become part of the workplace culture—or it could be common across the industry, hurting security operations in hundreds of organizations. Some of the more common ones out there include:
Myth: DevSecOps simply rebrands your old security tools with a new name.
Truth: Your existing security tools may be older than DevSecOps and won’t integrate. And there is no one-size-fits-all tool, so what may have worked well for your on-prem security applications won’t be compatible with a cloud-native environment.
Myth: DevSecOps is cloud-native only.
Truth: While a cloud-native infrastructure and DevSecOps do go together, it can be used outside of a container environment. There are features in DevSecOps that interact well with microservices architecture, according to Enterprise Talk.
Myth: DevSecOps is always a shift left approach.
Truth: Shift left is an important concept, especially when considering Boland’s point of an as-code approach to security, but it also ignores that security has to take place in every step along the way. Don’t ignore the right and the middle.
Myth: Security isn’t important to DevOps teams.
Truth: DevOps teams want to build secure applications, but they are under pressure to produce their products quickly and get them out to market, so security gets pushed to the side. Chances are the DevOps team and the security team have the same goals in getting an app without vulnerabilities and flaws through production as fast as possible, but the stumbling block is corporate leaders who are looking only at the bottom line.
Breaking Through the Myths
Boland offered the following suggestions on how to approach security in cloud-native applications:
• Think like an MSP by delivering innovation, agility and risk reduction across the organization. When you think like a service provider, you can think of delivering security-as-a-service.
• Stop deploying code that is insecure. It’s your job to show business leaders that you are compliant and are actively taking steps to reduce risk.
• Reduce your exposure window. This is best done with automation, which offers high-speed cloud visibility and real-time misconfiguration discovery and mitigation.
• Use continuous compliance and enforcement to align with regulation requirements. If you believe the myths, Boland said, you aren’t going to achieve your goals.
There will always be backtracking to mitigate the risks and the security flaws that get missed the first time.
“You don’t have to trade off your security,” Boland said. Rather, think of your security as part of the code, as a service that you are building into the app. Don’t fall for the myth; rather, be the security myth buster.
