One of the defining characteristics of the digital economy is our increased dependence on third-party organisations. Whether we are manufacturers, retailers, hotels, financial institutions or government, we rely on a network of suppliers and business partners to create and deliver goods and services.
While this interdependence allows us to achieve economies of scale, it also introduces risks to our business.
Consider the case of the Japanese automaker, Toyota. In February 2022, Toyota shut down operations in Japan after a major plastic supplier, Kojima Industries, suffered a data breach. Kojima had remote access to Toyota manufacturing plants, greatly increasing Toyota’s risk. As a result of the temporary shutdown, Toyota suffered financial and operational losses.
These third-party risks extend to our technology suppliers. Consider the case of SolarWinds and Kaseya – both are trusted names in their industries. When both suffered a breach, the attack cascaded down to their customers.
So how do you protect your business when the potential threat is from outside your control?
Siddharth Deshpande, field CTO for the Asia-Pacific region at Palo Alto Networks, acknowledges that most business applications today are not developed (coded) from scratch.
He explained that these are generally assembled with different elements of third-party code that are integrated into the applications. Those application components or libraries represent dependencies.
He cautioned that there are risks because some of these come from an external environment.
“You can't always regulate exactly what code components end up in your software pipeline. But if you take security into the entire CICD lifecycle, organisations engage in digital business and yet maintain the risk posture."
Siddharth Deshpande
How can infrastructure as code play a role in supply chain protection?
Siddharth Deshpande: A small misconfiguration in one of these infrastructure-as-code templates can expose the organisation to excessive risks in production. It becomes hard to manually track down those misconfigurations once the application is already in production.
The solution is to look at shipping security labs so that you're able to bake security into the infrastructure as a coding process. You’re able to offer developers very specific recommendations to remediate those misconfigurations as they are committing the infrastructure as code templates.
How can code security prevent vulnerabilities and compliance violations that arise because of the increased use of container images?
Siddharth Deshpande: It's a combination of container security and scanning in the pre-deployment phase in the code and build phase as well as in the runtime phase. Container security from a vulnerability perspective has to be continuous.
You need to be able to do container vulnerability scanning at runtime and link that runtime scan with whatever you discovered in the pre-deployment phase, integrating the development and the runtime phase of container scanning.
If you look at the idea of provisioning controls built into code, what is the significance of policy as a code or policy as code?
Siddharth Deshpande: Policy as code becomes important because you don't want developers to go outside of their workflow or their infrastructure as code tools to implement policies.
Any cloud security approach needs to provide instrumentation and integration with the developers’ coding tools to allow them to put in place policies that can cascade [from] production to environment effectively.
[It] is just automating from a security perspective, enforcement of security policy at the code level, [instead of] having to do that manually.
How can the industry then build confidence in open-source security when you hear all of these breaches that have been happening for the last few years?
Siddharth Deshpande: I think it's a holistic approach that the industry needs to take. Apart from raising awareness, it’s the technology angle. You cannot expect open-source code maintainer[s] to have absolute visibility into everything from a security perspective.
The CICD lifecycle [should be integrated] effectively with the tools that developers are using. That can give organisations assurance that security is not a process that's coming in after the application is in production, but while the applications are being developed.
What is your advice to both the CIO, the CSO, and CTOs as regards securing third-party applications?
Siddharth Deshpande: There must be an organisational cultural awareness that needs to be driven from the top down about what types of different mechanisms exist for third parties to interact with our infrastructure and what kinds of risks those poses.
It's the culture and technology, but the technology platform, if it's the correct cloud security platform or CNAAP, [that] can facilitate the cultural change that organisations need to undergo when it comes to protecting against third-party risks.
Click on the PodChat player as Deshpande elaborates on the risks that come with third-party applications and how to secure the enterprise against third-party risks.
- What are the hidden risks and threats posed by Third-Party Code?Â
- How can Infrastructure-as-code play a key role in supply chain protection?Â
- How can code security prevent vulnerabilities and compliance violations in container images?
- What is the significance of policy-as-code in the provision of controls built into code?
- Most of the modern application code is made up of open-source dependencies. How can the industry build confidence in open-source security?
- As organisations pursue cloud-native applications and work more collaboratively with third-party partners, what is your advice for CIO/CISO and CTO in securing third-party applications?
