Orca Security Integrates CNAPP With Microsoft GPT Service
Orca Security today announced it has fully integrated its cloud security platform with the Microsoft Azure OpenAI GPT-4 generative artificial intelligence (AI) service to make its simpler to, for example, identify code that can be used to remediate vulnerabilities.
In addition, the company has prompted improvements to optimize remediation queries along with support for the Open Policy Agent (OPA) remediation method and the ability to include remediation requests within Jira tickets created by an IT services management team.
Orca Security CEO Gil Geron said the overall goal is to make it possible for cybersecurity teams to present the code for remediating a cloud security issue to developers on a silver platter. One reason many cloud security issues remain unaddressed is that developers don’t have the time required to develop a patch. The integration with GPT-4 eliminates that issue by surfacing the code required alongside an explanation of the vulnerability that needs to be addressed, he added.
In many instances, all the developers will need to do is copy and paste that code into an application or infrastructure-as-code (IaC) tool, noted Geron.
Orca Security previously provided integration with GPT-3 via a REST application programming interface (API), but this update to its cloud-native application protection platform (CNAPP) supports the more advanced version of the generative AI platform.
Earlier this year, Orca Security introduced the 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. The company has been making a case for a CNAPP approach, dubbed SideScanning, that scans both workloads and cloud configuration metadata to build a map of risks and prioritize cloud security remediation efforts. That approach eliminates the need for DevOps teams to deploy and maintain agent software to ensure cloud security.
Cloud security remains challenging because cloud 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 to address it. 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 along with surfacing the code to remediate it makes it simpler for organizations to embrace DevSecOps workflows to improve cloud application security.
Unfortunately, far too many developers still 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 not just finding a vulnerability but also the resources needed to fix it.
