“We’ve all heard of paying it forward, but this is ridiculous!” That’s probably what most of us think when one of our partners or vendors inadvertently leaves an open door into our shared supply-chain network; an attacker can enter at any time. Well, we probably think in slightly more expletive-laden terms, but nonetheless, no organization or company wants to be the focal point of blame from a multitude of (formerly) trusting partners or vendors.
[Open-source software (OSS)](<https://www.rapid7.com/open-source/>) is particularly susceptible to these vulnerabilities. OSS is simultaneously incredible and incredibly vulnerable. In fact, there are so many risks that can result from largely structuring operations on OSS that vendors may not prioritize patching a vulnerability once their security team is alerted. And can we blame them? They want to continue operations and feed the bottom line, not put a pause on operations to forever chase vulnerabilities and patch them one-by-one. But that leaves all of their supply-chain partners open to exploitation. What to do?
## The supply-chain scene
Throughout a 12-month timeframe spanning 2019-2020, attacks aimed at OSS [increased 430%](<https://www.sonatype.com/hubfs/Corporate/Software%20Supply%20Chain/2020/SON_SSSC-Report-2020_final_aug11.pdf>), according to a study by Sonatype. It’s not quite as simple as “gain access to one, gain access to all,” but if a bad actor is properly motivated, this is exactly what can happen. In terms of motivation, supply-chain attackers can fall into 2 groups:
* **Bandwagoners:** Attackers falling into this group will often wait for public disclosure of supply-chain vulnerabilities.
* **Ahead-of-the-curvers:** Attackers falling into this group will actively hunt for and exploit vulnerabilities, saddling the unfortunate organization with malware and threatening its entire supply chain.
To add to the favor of attackers, the same Sonatype study also found that a shockingly low percentage of security organizations do not even learn of new open-source vulnerabilities in the short term after they’re disclosed. Sure, everyone’s busy and has their priorities. But that ethos exists while these vulnerabilities are being exploited. Perhaps the project was shipped on time, but malicious code was simultaneously being injected somewhere along the line. Then, instead of continuing with forward progress, remediation becomes the name of the game.
According to the Sonatype report, there were more than a trillion open-source component and container download requests in 2020 alone. The most important aspects to consider then are the security history of your component(s) and how dependents along your supply chain are using them. Obviously, this can be overwhelming to think about, but with researchers increasingly focused on remediation at scale, the future of supply-chain security is starting to look brighter.
#### Learn more about open-source security + win some cash!
[Submit to the 2021 Velociraptor Contributor Competition](<https://docs.velociraptor.app/announcements/2021-artifact-contest/>)
##
## Securing at scale
Instead of the one-by-one approach to patching, security professionals need to start thinking about securing entire classes of vulnerabilities. It’s true that there is no current catch-all mechanism for such efficient action. But researchers can begin to work together to create methodologies that enable security organizations to better_ _prioritize vulnerability risk management (VRM) instead of filing each one away to patch at a later date.
Of course, preventive security measures — inclusive of our [shift-left culture](<https://information.rapid7.com/shifting-left-sdlc.html>) — can help to mitigate the need to scale such remediation actions; the fact remains though that bad actors will always find a way. Therefore, until there are effective ways to eliminate large swaths of vulnerabilities at once, there is a growing need for teams to adhere to current best practices and measures like:
* Dedicating time and resources to help ensure code is secure all along the chain
* Thinking holistically about the security of open-source code with regard to the CI/CD lifecycle and the entire stack
* Being willing to pitch in and develop coordinated, industry-wide efforts to improve the security of OSS at scale
* Educating outside stakeholders on just how interdependent supply-chain-linked organizations are
As supply-chain attackers refine their methods to target ever-larger companies, the pressure is on developers to refine _their_ understanding of how each and every contributor on a team can expose the organization and its partners along the chain, as [The Linux Foundation](<https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security/>) points out. However, is this too much to put on the shoulders of DevOps? Shifting left to a DevSecOps culture is great and all, but teams are now being asked to think in the context of securing an entire supply chain’s worth of output.
This is why the industry at large must continue the push for research into new ways to eliminate entire classes of vulnerabilities. That’s a seismic shift left that will only help developers — and really, everyone — put more energy into things other than security.
## Monitoring mindfully
While a proliferation of OSS components — as advantageous as they are for collaboration at scale — can make a supply chain vulnerable, the power of one open-source community can help monitor another open-source community. [Velociraptor](<https://docs.velociraptor.app/>) by Rapid7 is an open-source [digital forensics and incident response (DFIR)](<https://www.rapid7.com/blog/post/2021/09/03/cybersecurity-as-digital-detective-work-dfir-and-its-3-key-components/>) platform.
This powerful DFIR tool thrives in loaded conditions. It can [quickly scale incident response and monitoring](<https://velociraptor.velocidex.com/scaling-velociraptor-57acc4df76ed>) and help security organizations to better prioritize remediation — actions well-suited to address the scale of modern supply-chain attacks. How quickly organizations choose to respond to incidents or vulnerabilities is, of course, up to them.
## Supply chain security is ever-evolving
If one link in the chain is attacked via a long-languishing vulnerability whose risk has increasingly become harder to manage, it almost goes without saying that company’s partners or vendors immediately lose confidence in it because the entire chain is now at risk. The public’s confidence likely will follow.
There are any number of [preventive measures](<https://www.rapid7.com/blog/post/2021/07/09/securing-the-supply-chain-lessons-learned-from-the-codecov-compromise/>) an interdependent security organization can implement. However, the need for further research into scaling security for whole classes of vulnerabilities comes at a crucial time as global supply-chain attacks more frequently occur in all shapes and sizes.
#### Want to contribute to a more secure open-source future?
[Submit to the 2021 Velociraptor Contributor Competition](<https://docs.velociraptor.app/announcements/2021-artifact-contest/>)
{"id": "RAPID7BLOG:F8502554A3593B631B7FDB48FA3A8BD7", "type": "rapid7blog", "bulletinFamily": "info", "title": "Security at Scale in the Open-Source Supply Chain", "description": "\n\n \n\u201cWe\u2019ve all heard of paying it forward, but this is ridiculous!\u201d That\u2019s probably what most of us think when one of our partners or vendors inadvertently leaves an open door into our shared supply-chain network; an attacker can enter at any time. Well, we probably think in slightly more expletive-laden terms, but nonetheless, no organization or company wants to be the focal point of blame from a multitude of (formerly) trusting partners or vendors.\n\n[Open-source software (OSS)](<https://www.rapid7.com/open-source/>) is particularly susceptible to these vulnerabilities. OSS is simultaneously incredible and incredibly vulnerable. In fact, there are so many risks that can result from largely structuring operations on OSS that vendors may not prioritize patching a vulnerability once their security team is alerted. And can we blame them? They want to continue operations and feed the bottom line, not put a pause on operations to forever chase vulnerabilities and patch them one-by-one. But that leaves all of their supply-chain partners open to exploitation. What to do?\n\n## The supply-chain scene\n\nThroughout a 12-month timeframe spanning 2019-2020, attacks aimed at OSS [increased 430%](<https://www.sonatype.com/hubfs/Corporate/Software%20Supply%20Chain/2020/SON_SSSC-Report-2020_final_aug11.pdf>), according to a study by Sonatype. It\u2019s not quite as simple as \u201cgain access to one, gain access to all,\u201d but if a bad actor is properly motivated, this is exactly what can happen. In terms of motivation, supply-chain attackers can fall into 2 groups: \n\n * **Bandwagoners:** Attackers falling into this group will often wait for public disclosure of supply-chain vulnerabilities. \n * **Ahead-of-the-curvers:** Attackers falling into this group will actively hunt for and exploit vulnerabilities, saddling the unfortunate organization with malware and threatening its entire supply chain.\n\nTo add to the favor of attackers, the same Sonatype study also found that a shockingly low percentage of security organizations do not even learn of new open-source vulnerabilities in the short term after they\u2019re disclosed. Sure, everyone\u2019s busy and has their priorities. But that ethos exists while these vulnerabilities are being exploited. Perhaps the project was shipped on time, but malicious code was simultaneously being injected somewhere along the line. Then, instead of continuing with forward progress, remediation becomes the name of the game. \n\nAccording to the Sonatype report, there were more than a trillion open-source component and container download requests in 2020 alone. The most important aspects to consider then are the security history of your component(s) and how dependents along your supply chain are using them. Obviously, this can be overwhelming to think about, but with researchers increasingly focused on remediation at scale, the future of supply-chain security is starting to look brighter.\n\n#### Learn more about open-source security + win some cash!\n\n[Submit to the 2021 Velociraptor Contributor Competition](<https://docs.velociraptor.app/announcements/2021-artifact-contest/>)\n\n \n\n\n## \n\n## Securing at scale\n\nInstead of the one-by-one approach to patching, security professionals need to start thinking about securing entire classes of vulnerabilities. It\u2019s true that there is no current catch-all mechanism for such efficient action. But researchers can begin to work together to create methodologies that enable security organizations to better_ _prioritize vulnerability risk management (VRM) instead of filing each one away to patch at a later date.\n\nOf course, preventive security measures \u2014 inclusive of our [shift-left culture](<https://information.rapid7.com/shifting-left-sdlc.html>) \u2014 can help to mitigate the need to scale such remediation actions; the fact remains though that bad actors will always find a way. Therefore, until there are effective ways to eliminate large swaths of vulnerabilities at once, there is a growing need for teams to adhere to current best practices and measures like: \n\n * Dedicating time and resources to help ensure code is secure all along the chain\n * Thinking holistically about the security of open-source code with regard to the CI/CD lifecycle and the entire stack\n * Being willing to pitch in and develop coordinated, industry-wide efforts to improve the security of OSS at scale\n * Educating outside stakeholders on just how interdependent supply-chain-linked organizations are\n\nAs supply-chain attackers refine their methods to target ever-larger companies, the pressure is on developers to refine _their_ understanding of how each and every contributor on a team can expose the organization and its partners along the chain, as [The Linux Foundation](<https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security/>) points out. However, is this too much to put on the shoulders of DevOps? Shifting left to a DevSecOps culture is great and all, but teams are now being asked to think in the context of securing an entire supply chain\u2019s worth of output. \n\nThis is why the industry at large must continue the push for research into new ways to eliminate entire classes of vulnerabilities. That\u2019s a seismic shift left that will only help developers \u2014 and really, everyone \u2014 put more energy into things other than security.\n\n## Monitoring mindfully\n\nWhile a proliferation of OSS components \u2014 as advantageous as they are for collaboration at scale \u2014 can make a supply chain vulnerable, the power of one open-source community can help monitor another open-source community. [Velociraptor](<https://docs.velociraptor.app/>) by Rapid7 is an open-source [digital forensics and incident response (DFIR)](<https://www.rapid7.com/blog/post/2021/09/03/cybersecurity-as-digital-detective-work-dfir-and-its-3-key-components/>) platform. \n\nThis powerful DFIR tool thrives in loaded conditions. It can [quickly scale incident response and monitoring](<https://velociraptor.velocidex.com/scaling-velociraptor-57acc4df76ed>) and help security organizations to better prioritize remediation \u2014 actions well-suited to address the scale of modern supply-chain attacks. How quickly organizations choose to respond to incidents or vulnerabilities is, of course, up to them.\n\n## Supply chain security is ever-evolving\n\nIf one link in the chain is attacked via a long-languishing vulnerability whose risk has increasingly become harder to manage, it almost goes without saying that company\u2019s partners or vendors immediately lose confidence in it because the entire chain is now at risk. The public\u2019s confidence likely will follow.\n\nThere are any number of [preventive measures](<https://www.rapid7.com/blog/post/2021/07/09/securing-the-supply-chain-lessons-learned-from-the-codecov-compromise/>) an interdependent security organization can implement. However, the need for further research into scaling security for whole classes of vulnerabilities comes at a crucial time as global supply-chain attacks more frequently occur in all shapes and sizes.\n\n#### Want to contribute to a more secure open-source future?\n\n[Submit to the 2021 Velociraptor Contributor Competition](<https://docs.velociraptor.app/announcements/2021-artifact-contest/>)", "published": "2021-09-08T13:48:34", "modified": "2021-09-08T13:48:34", "cvss": {"score": 0.0, "vector": "NONE"}, "cvss2": {}, "cvss3": {}, "href": "https://blog.rapid7.com/2021/09/08/security-at-scale-in-the-open-source-supply-chain/", "reporter": "Aaron Wells", "references": [], "cvelist": [], "immutableFields": [], "lastseen": "2021-09-08T14:57:53", "viewCount": 12, "enchantments": {"dependencies": {}, "score": {"value": -0.3, "vector": "NONE"}, "backreferences": {}, "exploitation": null, "vulnersScore": -0.3}, "_state": {"dependencies": 1646271214, "score": 1659847081, "epss": 1679109163}, "_internal": {"score_hash": "fb4dbace43e1676e72f6a49d40e3d2b0"}}
Security at Scale in the Open-Source Supply Chain