Dive Brief:

• Nearly two-thirds (63%) of third-party code templates used for building cloud infrastructure have insecure configurations, according to research from Palo Alto Networks Unit 42 Cloud Threat Report for H2 2021 released Tuesday. The data comes from Unit 42's cloud threat intelligence team, which conducted red team exercises on customers' software build processes to find ways bad actors could compromise cloud assets. 
• Almost all third-party container applications deployed (96%) have known vulnerabilities. Cloud infrastructure could be targeted in a similar way to software supply chain hacks where "unvetted" code could bring flaws into the cloud and provide bad actors access to cloud-based data, the report found. 
• With third-party code universally in use, Unit 42 warns companies that this code could even come from bad actors. Companies reliant on the same code repositories for their cloud infrastructures could be compromised and then have it replicated across other organizations using the code.  

Dive Insight:

The breakneck speed at which services become available is challenging proper and secure configurations. At the same time, "everything as code" has its benefits, including oversight of workloads in a cloud infrastructure, according to Jay Chen, principal researcher at Unit 42, in an email to Cybersecurity Dive. It's a matter of catching security problems in the build before cloud workloads are provisioned. 

The upstream compromise of software builders is creating larger downstream victims through "ripple" incidents. When SolarWinds was compromised, the company was adamant that its source code was not manipulated but its build process was. However, the supply chain-style attack SolarWinds suffered was not the first of its kind, Unit 42 said. Dating back to 2015, bad actors were drawn to attacking developers, including XcodeGhost, KeRanger, NotPetya and CCleaner. 

In one case, Unit 42's red team accessed a customer's software development process using insecure configurations. The team gained initial access because cloud credentials were hardcoded in the source code, Chen said. The other most critical issues were leaked credentials that allowed for privilege escalation and inactive threat detection services. 

Infrastructure as code is reliant on dependent packages, which can create security issues with each deployment. Issues with cloud infrastructure, contributing to weaknesses bad actors can exploit, include cloud infrastructure provisioning, Kubernetes Helm chart deployment, and container image initiation, the report found. 

After analyzing more than 1,500 of "the most downloadable container images," Unit 42 found the majority of vulnerabilities are from open-source packages, Chen said. The vulnerabilities include denial of service, remote cross-site scripting and remote code execution. 

The security problem with third-party container applications is not indicative of infrastructure flaws, Chen said. "It is an unavoidable issue in modern cloud-native applications, as most applications are built on top of tens or hundreds of open-source tools." 

"When building a container image, it is not always possible to find a library that is compatible with the application, well-maintained, and vulnerable-free. Most developers will prioritize usability over security," he said. Software bill of materials could theoretically alleviate some of these challenges, but software still will not be vulnerability-proof. 

Following the SolarWinds breach, the company set new standards for its software build, requiring a reproducible build. Attestation and verification throughout every stage of the build process is best practice, Chen said. 

"We believe the adoption of DevOps is pushing the entire industry towards a more secure software supply chain." But adopting best practices will come second to companies modernizing their "long tail of technology debt," he said. For one particular customer, had it "implemented even half of the security best practices we advised, the Unit 42 researchers wouldn't be able to penetrate the system, at least not so easily."