Why We Need to Reimagine Security for Cloud-Native | CDOTrends


The security game changed with cloud-native development. The problem is that many companies are operating as if it has not.

While Kubernetes and containers gave developers and companies more flexibility in application design, these also increased complexity and added security headaches. Essentially, including infrastructure as code (IaC) makes infrastructure configuration on top of code dependencies and container security a developer’s concern.

This makes traditional approaches to finding, fixing, and monitoring security issues during the software development life cycles (SDLC) woefully inadequate.

Snyk is part of a new generation of companies reimagining security as organizations shift left and adopt DevSecOps practices. Recently named Visionary by Gartner for application security testing, the company wants to help developers avoid becoming blindsided by security vulnerabilities brought about by misconfigurations and unpatched vulnerabilities that traditional security platforms often overlook.

“Traditional security platforms were not built for developers. This means developers struggle to integrate said tools into their toolchains, which is often why these tools do not have widespread adoption,” says Lawrence Crowther, head of solutions engineering for APJ at Snyk.  

Many of these tools were also built for different purposes: for auditors to scan applications and produce reports. “The issue with this is that developers need to switch context and figure out what needs to change and where. Effective AppSec tools should integrate directly into the tools that developers are using every day, such as their IDE (Integrated Development Environment) where they are writing the code, SCM (Source Code Management) like GitHub and CI/CD systems,” Crowther adds.

Building blocks for cloud-native AppSec

Snyk sees four basic building blocks that are essential for a new generation security platform.

They need to scan the proprietary code for vulnerabilities; scan all open source dependencies (direct and transitive) that applications use; scan Dockerfile definitions and actual container images before and after deployment to container registries; check IaC scripts for misconfigurations to uncover any security holes.

Such holes include “wrong network ports open, files being exposed, running as privileged (root) user or worse still having passwords and secret keys in plain text in the config file,” explains Crowther.

Culture also becomes critical. “Shifting left is not enough; the culture and structure of the organization need to adapt too. A successful DevSecOps approach needs to enable security to be built in continuously to align with the iterative DevOps model,” says Crowther.

This means that developers should not see security as simply an AppSec team mandate and not theirs. “The responsibility for security has to be initiated from development, with the application security team acting in a supporting, advising, and governance role for the model to scale — in a similar model to how the Operations team evolved when DevOps was introduced,” he points out.

Automation can help, and Crowther believes it is essential for DevSecOps. “Automation is the key to a successful DevSecOps initiative which makes CI/CD a critical piece of infrastructure that needs to be done right.” It helps to root out “around 95% of vulnerabilities and security issues” from entering production. It also allows auto-remediation so that the security issues are quickly addressed.

“When this is done right, and at scale, developers are not slowed down by security tools and can continually deliver value,” says Crowther, addressing a key complaint by developers. 

Catch Lawrence Crowther at a virtual roundtable session with the same title discussing his above observations with industry leaders on Sept. 21, 2021. As seats are limited, please contact Usha G. at [email protected] or register here.


Avoiding supply chain attack

Modernizing the application security platform allows companies to avoid such attacks as the Solar Winds Supply Chain Attack.

In this attack, hackers used passwords available in a public configuration file to break into a build server. They then injected a malicious payload into the software artifact before distributing it through the software supply chain.

“There is a need to not only check application code for vulnerabilities but also the infrastructure configurations for which the applications run on. You need a system to check for misconfigurations in your IaC assets, such as Terraform, Kubernetes YAML, and AWS CloudFormation files. This should be a priority for any CISO who wants to secure their whole software supply chain,” says Crowther, calling out a new mandate for security teams. 

He also adds tools alone will not help. CISOs need to reinforce their efforts by extending security education programs for developers to go beyond app security and into infrastructure security.

“This is really important as infrastructure becomes code, automation is used to deploy critical infrastructure components and the responsibility shifts to developers. CISOs need to set up automation, policies, and guardrails, but to balance this with developer productivity, that is the key to a successful DevSecOps program,” says Crowther.

Collaboration becomes essential

Snyk does not believe that security companies can continue to operate as islands if they want to help developers battle threat actors.

Instead, they need to see themselves as part of an ecosystem where intelligence is shared; after all, it is well known that threat actors collaborate on the Dark Web, so it only makes common sense that defenders do the same too. 

For its part, Snyk is building an intelligence database that covers 440% more vulnerabilities than any public commercial database. In addition, it collaborates with the community and operates bug bounties for new disclosures, resulting in hundreds of community disclosures.

Snyk has an in-house security threat intelligence team that constantly listens to chatter on security bulletins, Jira boards, Github commits to automatically identify vulnerabilities yet to be reported. It also partners with Berkeley, Virginia Tech, and Waterloo labs to exchange tools, methods, and data.

Snyk’s GTM strategy also depends heavily on partners, “whether that be so customers can consume Snyk easier in the cloud marketplaces like AWS, Azure or Google Cloud Platform or so that we have integrations with other third-party products that are popular in our customer install base,” says Crowther.

This list includes Terraform (by Hashicorp), BitBucker (by Atlassian), Docker, CircleCI, etc. “A lot of our technology partners embed Snyk into their applications as the default way to scan source code such as TrendMicro, which has Snyk available for open source scanning directly in their CloudOne portal and Hashicorp where Snyk is available directly in the Terraform Cloud portal.

Extending security to OT

Snyk is also addressing the new challenges that digitalizing operation technology (OT) brings. This is becoming a critical issue as threat actors shift to attacking infrastructure targets and exploit the disconnect between IT and OT security.

“Traditionally, Snyk has been focused on modern programming languages used to build Web and Mobile applications. However, many IoT and edge computing-related technologies use lower-level languages like C/C++, which Snyk did not support,” says Crowther. 

So, Snyk acquired FossID that specialized in scanning and looking for vulnerabilities in C/C++ applications. FossID also had a unique feature called snippets which would identify if developers had copied and pasted code from the internet (sites like stackoverflow.com) and included that in their projects.

“These snippets can also contain vulnerabilities! It reminds me of the movie Antitrust with Ryan Phillippe where a company was copying code from developer screens via cameras,” explains Crowther.  

Snyk believes that securing these types of applications shouldn’t be that different from modern web apps.

“They will still use the same source control and CI/CD systems. Their IDEs may be different, but the rest of the SDLC looks the same. It’s critical that these types of applications are secure also especially if they are powering the next generation devices found in vehicles, robots and health systems, etc.,” adds Crowther.

The future is ASPM



Read More:Why We Need to Reimagine Security for Cloud-Native | CDOTrends