Securing the apps that businesses and individuals have come to rely on, particularly during the pandemic, has become a multidimensional challenge. Recent research underscored the need to more tightly knit DevOps together with SecOps early in the development process.
More than 40% of apps actively leaked information, increasing the risk that sensitive data would be exposed, according to WhiteHat Security’s AppSec Stats Flash Volume 3, the company’s latest monthly statistics report. Among the top vulnerabilities, A3-sensitive data exposure, in particular, can have dire consequences for the supply chain as attacks ripple across connected applications.
For those charged with DevSecOps, these most recent WhiteHat stats “point to a misalignment between what is seen in production systems and what is prioritized in the DevOps process for security,” said Setu Kulkarni, vice president of strategy at the security firm.
After all, he pointed out, integrating “actually exploitable vulnerability information from production systems back into SecOps (for mitigation) and/or DevOps (for remediation) is a starting point for good DevSecOps.”
The shift to work-from-home during the pandemic, and “the resulting much-larger enterprise digital footprint, required the mobilization of security teams to quickly adapt,” said Yaniv Bar-Dayan, CEO and co-founder at Vulcan Cyber, but that meant the bad actors adapted, too. “Meanwhile, the number of known vulnerabilities have reached all-time highs,” and offered a path of least resistance for bad actors who have quickly adjusted their own methods to exploit the situation.
The challenge of securing apps is particularly tough in manufacturing, where the research showed the highest window of exposure – the survey found 70% of the applications had at least one serious vulnerability in the prior year.
That’s likely because manufacturing’s roots are not in interconnectedness; simultaneously the sector has experienced rapid advances in OT. As a result, security teams must support a growing number of legacy systems and software that must be internet-enabled for at least remote monitoring and, in some cases, remote operations. “The lift and shift of applications that were never meant to be internet-facing to become internet-enabled has likely resulted in this high risk,” Kulkarni said.
Another contributing factor: “Supply chains are now increasingly software-driven – which means business partners are now having to open up otherwise internal applications to integrate with supply chain partners – again, resulting in existing vulnerabilities – that were previously unexploitable – to become publicly exploitable,” said Kulkarni.
The risk of leaky apps to B2B partnerships aren’t, of course, confined to the manufacturing sector.
B2B partnerships in tech and tech-enabled businesses almost always require application integration, Kulkarni explained. “Through these application integrations, the partnering organizations are able to offer net-new value propositions to their end users,” he said.
For example, for an online-first bank application that integrates with a money-transfer application to deliver an in-situ end-to-end banking experience that allows the bank customer to complete international money-transfers, “the security posture of the partnership venture is only as good as the least secure application,” Kulkarni said. If just one app has AppSec vulnerabilities that allows adversaries to exfiltrate data from the other application and during app integration “assumptions were made about authorization requirements in one app,” that could leave the second application vulnerable.
WhiteHat’s findings show how important it is for DevOps and SecOps to work closely together and prioritize breach risk reduction during production rather than after the fact. While it might be tempting to throw responsibility for sensitive data exposure vulnerabilities “over the fence” to DevOps teams – which typically do search for vulnerabilities to fix – Kulkarni said if PII data is masked, for example, it’s likely Dev teams will “omit addressing vulnerabilities which allow software versions to be revealed, only because these are not traditionally in the remit of the individual developer.”
As it turns out, “PII-related issues are less than 1% of the sensitive data exposure vulnerabilities, while software version revelations are almost 34% of the sensitive data exposure vulnerabilities,” he said. “This is a great example where Dev and Sec teams need to work together and share knowledge.”
But while “collaboration between security and IT operations teams has never been more important,” it also has never been more difficult, said Bar-Dayan.
The shift left, though, can put more of the security onus on the application team, “in addition to their traditional workload,” said Michael Isbitski, technical evangelist at Salt Security. On the other side, security teams and their IT counterparts had to develop skills and use tools to automate and orchestrate a more collaborative approach to IT security operations, DevSecOps and vulnerability remediation, Bar-Dayan added.
But the more organizations automate tooling and bake-in relevant subject matter expertise, Isbitski said, “the better off development, operations and security teams will be in delivering functional and secure applications.”
The simplest tip to facilitate collaboration comes from Kulkarni: Build a culture of trust between the teams.