Software supply chain attacks present an increasingly worrying threat. According to a recent BlueVoyant study, an impressive 97 percent of companies surveyed have been negatively impacted by a security breach in their supply chain, and 38 percent said they have no way of knowing about any potential issues with a third-party supplier’s cybersecurity.
Ankur Shah, senior vice president for Prisma Cloud products at Palo Alto Networks, told eSecurity Planet that high-profile threats like the Log4j and Spring4Shell vulnerabilities have kept these concerns at top of mind – and they’re becoming more prevalent, Shah said, for three key reasons.
3 Causes of Growing Supply Chain Threats
First, Shah said, years ago when he was a developer, nothing he built would be deployed until after extensive security and QA testing. “Now, developers can pretty much, from their IDE, click a button and get the whole thing tested, secured, deployed, within minutes,” he said. “Customers are shipping applications every hour, every day, whenever they want, and businesses love that. It’s a circular trend, and it’s not going to change – developers are not going to go slowly because of quality or security.”
Second, the number of developers has quickly outpaced the number of security pros, making it all but impossible for the security folks to keep up. “Everybody’s a developer now,” Shah said. “There are over 33 million developers vs. 3 million security professionals. So it’s a battle that security can’t win.”
Third, Shah said, when he was a developer, it was usually about 80 percent his code and 20 percent open source libraries – while today, it’s often the opposite. “Download open source code from hack me dot com, now it’s part of your container image, whatever it is – and then who knows? It gets deployed in hundreds of thousands of workloads and hell breaks loose,” he said.
And it doesn’t have to be from some random website – Log4j isn’t just some random component from a tiny third-party vendor. “This is Apache,” Shah said. “Their claim to fame is they’re Open Source 101 – a trusted vendor, a trusted component – and yet somebody found a vulnerability, and it’s fairly easily exploitable.”
Also read: New Open-source Security Initiative Aimed at Supply Chain Attacks
4 Steps to Code Security
What companies need to do in response, Shah said, is to secure the entire application lifecycle from code to runtime – which involves actively monitoring security in at least four key points in the process.
The first step is during development, making sure that any open source code being used is safe. “When the developers are building their code in the IDE, if they just say, ‘Import this open source component,’ right then and there they should know, ‘Are you sure you want to do this? Because that particular open source component has a known vulnerability,’” Shah said.
Increasing developers’ awareness of those concerns is a good start, he said, though each company has to determine its own risk tolerance. A fintech, healthcare, or government organization will likely need to be more careful about open source components than those in other verticals that may want to seek a different balance between security and speed of deployment.
The next area to consider is infrastructure as code. “A lot of times, the bad actors exploit the weaknesses in the infrastructure – overly permissive security groups, etc. – so the other thing to secure, in addition to the open source code, is secure infrastructure as code,” Shah said.
It’s equally important to secure the code repository, the third step in Shah’s process. “Make sure that your VCS, your Git repo, doesn’t have weaknesses – like is it exposed to the public Internet? With Capital One, the code repo was exposed and somebody was able to exploit it – make sure you have multi-factor authentication, you can only access it within your corporate VPN, and it’s not available to the public Internet.”
Finally, there should be an additional check prior to deployment. “Scan your container registries, scan your CI/CD pipeline, make sure you’ve got one more check done there,” Shah said. “And then the final stage is, things go into production.”
Also read:
Defense in Depth
That whole process, Shah said, is about ensuring defense in depth. “You don’t just do one step,” he said. “You do these security checks and balances every step of the way – at the code time, build time, deploy time, and run time. And if you do that, the chances of a mistake are minimal.”
With checks throughout the process, Shah said, you end up with an approach to code like Toyota’s concept of jidoka, which allows anyone to stop the assembly line if they spot a defect. “The idea being, the further down the car goes in the assembly line, the worse the problem gets – so fix it sooner, as much as you can. Do quality checks every step of the way.”
Finally, Shah said, for many companies, it’s worth considering a platform player rather than combining piecemeal solutions. “Having more security tools does not make you more secure,” he said. “It makes you less secure. By taking a platform approach to your security, you can get visibility across the board – you don’t have to stitch a bunch of disparate things together.”
Further reading:
