Innovation Shift Left Together: Coordinating A Joint Response To Supply Chain Threats Mario Vuksan Forbes Councils Member Forbes Technology Council COUNCIL POST Expertise from Forbes Councils members, operated under license. Opinions expressed are those of the author. | Membership (fee-based) Jul 6, 2022, 08:45am EDT | Share to Facebook Share to Twitter Share to Linkedin Co-Founder and CEO of ReversingLabs , which helps cybersecurity teams gain insights into malware infected files and objects.
Getty If you’re an independent security researcher, there’s no better reward—professionally or financially—than discovering a serious and remotely exploitable flaw that’s common to systems operated by the biggest, wealthiest software firms in the world. That’s just what happened in early 2021, when researcher Alex Birsan and some colleagues netted $130,000 in bug bounties in a matter of days from the likes of Apple, PayPal, Microsoft and Shopify. Birsan’s ace in the hole? Dependency confusion : a complex-sounding but simple attack that leverages configuration flaws or “insecure by design” features of common package installers, such as Node.
js npm, RubyGems and Python’s pip, to shuttle malicious code into organizations under the guise of public, open-source packages. Birsan’s “hack” of these prominent firms proceeded from some straightforward, open-source research on public code repositories like Github. He and his collaborators uncovered the names of private, internal software packages used by organizations like PayPal and Apple buried inside scripts published to public repositories.
They then “squatted” on those names, creating new, public packages with the same names and with high version numbers. Misconfigured package managers did the rest—silently importing the malicious squatter package in place of the legitimate but “older” private package that was hosted internally by the target firm. Birsan dubbed the attack “dependency confusion” and observed , “The success rate was simply astonishing.
. . .
Squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds. ” MORE FOR YOU Google Issues Warning For 2 Billion Chrome Users Forget The MacBook Pro, Apple Has Bigger Plans Google Discounts Pixel 6, Nest & Pixel Buds In Limited-Time Sale Event Survey Finds Concern And Resignation On Supply Chain Security Birsan’s disclosure set off a firestorm of news coverage. But a year later, are companies any better prepared for or protected against dependency confusion or similar assaults on software supply chains? Evidence from a survey my company conducted suggests the answer is “no.
” My company recently sponsored a survey of more than 300 enterprise executives and technology and security professionals to assess their understanding of supply chain risks related to the use of third-party and open-source software. We found that the survey respondents were almost universally aware of and concerned about the threat posed by software tampering and supply chain attacks, but only a minority worked for organizations that were addressing that risk. In fact, 87% of respondents said they were aware that software tampering has resulted in enterprise security breaches.
However, only 37% said they worked for organizations that had the means to detect software tampering across the company’s software supply chain. Supply Chain Attacks: Just The Beginning As for the dependency confusion vulnerability identified by Birsan and others, there is every reason to believe that sophisticated nation-state actors and cybercriminal groups are already wise to the dependency confusion attack vector. In recent weeks, for example, reports surfaced about “in the wild” dependency confusion attacks discovered on the npm platform and—apparently—targeting German technology, media and industrial firms.
Researchers at the firm Snyk and my company discovered malicious, public npm packages, some clearly intended to impersonate legitimate, private npm packages used by unknown and unnamed firms. Those “in the wild” attacks ended up being an example of friendly fire. After they attracted media attention, they were claimed by a security consulting firm , Code White GmbH, which said the offending packages were part of “red team” assessments of its clients.
Still, the presence of dependency confusion attacks in the toolbelt of a professional red teaming outfit like Code White underscores the fact that supply chain attacks are now recognized as “go-to” tools to obtain access to sensitive IT assets and environments for both white hat and black hat hackers. In recent years, researchers at my company have scanned repositories, including PyPI and Node. js npm, identifying multiple instances of malicious programs hiding among the tens of thousands of legitimate software modules.
These include password stealers hiding inside or posing as legitimate open-source modules. At least one of these compromised modules had more than 30,000 downloads, suggesting that malicious actors who can successfully infiltrate open source repositories reap sizable dividends. Shift Left—Together This growing specter of sophisticated attacks on development pipelines and software supply chains demands a response.
But what should that response be? DevSecOps advocates a tight integration of IT security with continuous “DevOps” application development. However, DevSecOps is no silver bullet. (Spoiler alert: There are no silver bullets.
) In fact, the advent of dependency confusion and similar hacks exposes a weakness in the DevSecOps paradigm: the inherent trust placed in the integrity of third-party and open-source software supply chains by individual developers and larger development organizations. That’s why security operations centers also need to “shift left” along with attackers by broadening their mandate to encompass monitoring of software supply chain threats as part of their overall risk monitoring. To use the example of software dependency attacks above, a left-shifted SOC would be on the lookout for alerts about malicious (or just suspicious) packages before deploying them into their production environment.
This would include monitoring for compromises of packages that were built internally or acquired from open-source repositories and other third parties. Dev SOC Ops, Anyone? By empowering development and SOC teams to shift left together, organizations can protect their IT assets, users and data from the risks posed by software supply chain attacks that are fast becoming the “new normal. ” This won’t be an easy transition.
While security may be shifting left, my company’s survey suggests many organizations continue to prioritize feature development and timely delivery of code over security considerations. At the same time, necessary security investments, such as the adoption of software bills of materials, remain stuck on the back burner. As the drumbeat of successful supply chain and CI/CD compromises quickens, organizations will find that they no longer have the luxury of delaying these needed security investments.
Shifting development and SOCs left together is the answer. Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify? Follow me on Twitter or LinkedIn .
Check out my website . Mario Vuksan Editorial Standards Print Reprints & Permissions.
From: forbes
URL: https://www.forbes.com/sites/forbestechcouncil/2022/07/06/shift-left-together-coordinating-a-joint-response-to-supply-chain-threats/