Gartner has predicted that by 2025, 60% of organizations will use cybersecurity risk as a key factor when deciding which third-party vendors to work with. When those third parties are commercial entities, this approach makes sense. Unfortunately, more and more organizations are relying more and more on non-commercial entities in the form of open source software, raising issues of how to determine trust.

Financial institutions are a prime example. They rely extensively on third-party vendors for a range of software (i.e, CRM) and services (i.e., cloud computing), each of which pose a greater or lesser risk depending on their cybersecurity practices. Because different vendors have different practices, FinServ organizations have a difficult time creating a “one size fits all” security standard they can apply to across the entirety of their vendor base. Consequently, too many third parties need to be treated as “exceptions” due to cybersecurity postures that don’t align with the FinServ organization’s standards. 

One way to mitigate this problem is exemplified by banks who prefer to reinvent the wheel, building their own version of Adobe Acrobat for secure signing of legal documents, or their own version of Docker in order to securely deploy ephemeral payloads, etc.

But banks aren’t building these internal solutions from scratch. Instead, they rely heavily on open source software to create them. In many cases, >80% of application code is open source code. Managing each open source package author (and the authors of each package’s dependencies, AND the authors of each of their dependencies) as separate third-party vendors is simply not possible. None of them will be filling out your questionnaires. This means that all open source software must be treated as “untrusted.”

When the entire software supply chain is untrusted, FinServ organizations expose themselves to backdoor attacks, whereby hackers can gain access to systems via a third-party and then work their way upstream to compromise your systems. For example, Bank of America’s customer data came under threat recently by a supply chain cyberattack that targeted their partner, IMS. In fact, according to Blue Voyant, “97% of companies have experienced negative consequences due to a cybersecurity breach among the external vendors and suppliers that form their supply chain.”

The problem lies in the breadth and depth of the software supply chain since most organizations have a tech stack that features more than one open source language and multiple deployment platforms. In a word, most organizations are “stumped” by the scale of the problem. 

Open Source Vendor Risk Management at Scale

To be effective, third-party vendor risk management has to go beyond just the initial questionnaires, assessments and scans. This is especially true of open source software, where a constant stream of patches, updates and newer versions make for a fast-moving security target. To secure the software supply chain requires both proactive and reactive measures. 

For example, basic security groundwork needs to be laid, including the need to:

  • Perform a software audit to generate a list of all third-party applications in your organization.
  • Perform a hardware audit to generate a list of all devices in your organization, which may be where previously unaccounted for third-party applications are deployed.
  • Create an SBOM compendium that contains an SBOM for each internally-created application, as well as each third-party application in order to be able to quickly identify which applications may contain problematic open source components.

But the real focus needs to be on more proactive activities, including:

  • Auditing and monitoring that data protection measures are in place.
  • Auditing and monitoring that physical security controls are in place.
  • Auditing and monitoring to ensure robust authentication and granular authorization are in place.
  • Continual malware scanning, including for both unobfuscated code and binary/compiled code.
  • Regular vulnerability remediation, either by applying patches or updates.
  • Working toward securing the software development process by implementing a framework like Supply chain Levels for Software Artifacts (SLSA) or NIST’s Secure Software Development Framework (SSDF).

All of these activities are both time and resource intensive, and can result in a complex implementation that is difficult and costly for all but the largest FinServ enterprises to maintain, especially when it comes to managing open source software. This is to say nothing of the fact that software supply chain security cannot be implemented all at once across the SDLC without a great deal of disruption to underlying business processes and operation costs. As an alternative, consider using a service like the ActiveState Platform.

The ActiveState Platform allows you to effectively outsource the securing of your open source supply chain by providing:

  • Continual malware scanning of open source code.
  • Notifications as soon as vulnerabilities are detected within your open source codebase.
  • The ability to update a vulnerable component, resolve any dependency conflicts that may arise, and automatically rebuild your codebase.
  • A “SLSA Build Level 3” hardened build service that automatically builds all open source components from vetted source code.
  • Automated generation of SBOMs and Software Attestations for your codebase.

This kind of automation allows you to secure your software supply chain at scale with minimal time and resources. And because the ActiveState Platform can be integrated with most software development processes in a matter of days, you can accelerate your ability to contain the risk posed by your third-party software.

Next Steps

Watch our webinar Navigating Your Software Supply Chain Journey: 5 Stages to Success to understand how you can create a roadmap to securing your software supply chain.