Orca Security Traces Cloud Vulnerabilities Back to Code

Orca Security today announced it added an ability to trace cloud security risks in production environments back to both the original code that created the issue and the developer that wrote it.

Avi Shua, chief innovation officer for Orca Security, said the Cloud to Dev capabilities added to the company’s cloud-native application protection platform ( CNAPP ) provide tools organizations need to bridge the historic divide between cybersecurity professionals and application developers.

That’s critical because despite ongoing efforts to shift more responsibility for security further left toward developers using DevSecOps best practices, no tools have been available that provide the exact context and a recommended fix developers need to remediate a vulnerability discovered by a cybersecurity team, he added.

For example, when a vulnerability is detected in a running container, the Orca Security platform will identify the source code repository, Dockerfile and owner responsible for adding the vulnerable package, Shua noted.

This capability should reduce the effort required to remediate cloud security issues by an estimated 80% by automatically identifying the exact line of code that is the root cause of the cloud security risk, the company claimed.

The Orca Security approach to cloud security makes use of the ability to create a risk profile using read-only access to the block storage accessed via a runtime hosted on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform. Dubbed SideScanning , that approach eliminates the need for DevOps teams to deploy and maintain agent software to ensure cloud security. The platform then scans both workloads and cloud configuration metadata to build a map of risks that better enable DevOps teams to prioritize cloud security efforts.

Cloud security remains a major challenge because, most of the time, infrastructure is provisioned by developers that have little to no security expertise. It’s all but certain mistakes will be made. Even when alerted to a security issue, many developers may not fully appreciate the severity of the issue. The harder it is to identify the code at issue, the longer it takes for a developer to find the time to address it, noted Shua.

Developers who wrote that code are also likely to have moved on to other projects. A vulnerability discovered in a production environment may need to be remediated by a different developer who didn’t write that code in the first place; pinpointing the exact line of code at issue can facilitate a remediation process that typically involves a team of developers.

Far too many developers assume cloud service providers are providing a level of security that they actually don’t. It’s the responsibility of the organization deploying the application to secure it and the configurations used to deploy it. The challenge, as always, is finding a cloud vulnerability and then marshaling the team of developers needed to fix it before a breach inevitably occurs.