Co-founder and CEO of reverse laboratorywhich helps cybersecurity teams gain insights into malware-infected files and objects.
GT
If you are an independent security researcher, there is no better reward – professionally or financially – than discovering a dangerous and exploitable remote flaw common in systems operated by the largest and wealthiest software companies in the world.
This is exactly what happened in early 2021, when researcher Alex Bersan and some colleagues Earn $130,000 in Bug Bounty in a matter of days From the likes of Apple, PayPal, Microsoft and Shopify. Ace Bersan in the hole? dependency confusion: A seemingly complex but simple attack that takes advantage of configuration flaws or “unsafe by design” features of popular package installers, such as Node.js npm, RubyGems, and Python pip, to transmit malicious code to organizations under the guise of public open-source packages.
Bersan’s “hack” of these notable companies stemmed from some direct and open source research on public code repositories like Github. He and his collaborators have revealed the names of private internal software packages used by organizations like PayPal and Apple buried within scripts posted to public repositories. Then they “squatted” on those names, creating new generic packages with the same names and higher version numbers. Misconfigured package managers did the rest – silently importing the random malicious package instead of the legitimate but “older” private package hosted internally by the target company.
Bersan described the attack as a “confusion of dependency.” And the noteThe success rate was simply astounding. …Putting the correct internal package names was an almost surefire way to get into the networks of some of the biggest tech companies out there, get in remote code execution, and possibly allow attackers to add backdoors during builds.”
Survey Finds Anxiety And Quitting About Supply Chain Security
Bersan’s disclosure sparked a storm of news coverage. But a year on, are companies better prepared or protected against dependency confusion or similar assaults on software supply chains? Evidence from a survey conducted by my company suggests that the answer is “no.”
My company recently sponsored A questionnaire Over 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 survey respondents were nearly universally aware of and concerned about the threat posed by software tampering and supply chain attacks, but only a few worked with organizations that were dealing with this risk.
In fact, 87% of respondents said they were aware that tampering with software had led to corporate 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 vulnerabilities identified by Pearsan et al., there is every reason to believe that sophisticated nation-state actors and groups of cybercriminals are indeed wise toward the dependency confusion attack vector.
In recent weeks, for example, Reports appeared About “in the wild” dependency confusion attacks discovered on the npm platform apparently targeting German technology, media and industrial companies. Researchers at Snyk and two companies have discovered malicious npm packages, some of which are apparently intended to impersonate legitimate and private npm packages used by unknown and unknown companies.
The “in the wild” attacks ended up being an example of friendly fire. After they caught the media’s attention, they were Required by a security consulting company, Code White GmbH, which said the offending packages were part of its customers’ “red team” ratings. However, the presence of dependency confusion attacks in the tool belt of a red professional team uniform like Code White underscores the fact that supply chain attacks are now known as “go-to” tools for accessing sensitive IT assets and environments to both white hat and black hat hackers. .
In recent years, researchers at my company have scanned repositories, including PyPI and Node.js npm, to identify multiple instances of malware hiding among tens of thousands of legitimate software modules. These include Password thieves Hiding inside or appearing as legitimate open source modules. At least one of these hacked modules has more than 30,000 downloads, which indicates that malicious actors who can successfully infiltrate open source repositories are making huge profits.
Shift left – together
This growing specter of sophisticated attacks on development pipelines and software supply chains requires a response. But what should this response be? DevSecOps advocates the tight integration of IT security with the continuous development of “DevOps” applications. However, DevSecOps is not a panacea. (Spoiler alert: There are no silver bullets.)
Indeed, the emergence of dependency confusion and similar hacking exposes a weakness in the DevSecOps model: 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 “swipe left” alongside attackers by extending their powers to include monitoring of software supply chain threats as part of overall risk monitoring. To use the example of software dependency attacks above, the SOC changed to the left will be on the lookout for alerts about malicious (or just suspicious) packages before they are deployed to their production environment. This will include monitoring of assignments of packages created internally or obtained from open source repositories and other third parties.
DaveSouth Oil CompanySorry, anyone?
By enabling development and SOC teams to shift left together, organizations can protect IT assets, users, and data from the risks posed by software supply chain attacks that are fast becoming the “new normal.”
This will not be an easy transition. While security may shift to the left, my company’s survey indicates that many organizations continue to prioritize feature development and timely code delivery over security considerations. At the same time, necessary security investments, such as the adoption of software bills of materials, remain stuck in the background.
As the cadence of successful supply chain and CI/CD accelerates, organizations will find that they no longer have the luxury of delaying these required security investments. Transformation in development and leaving SOCs together is the correct answer.
Forbes Technology Council It is an invite-only community of world-class CIOs, CIOs, and CTOs. Am I eligible?
