For the Financial Services (FinServ) industry , the software supply chain is a critical security risk. Unfortunately, most banking, trading, and insurance organizations continue to approach the problem in a fragmented way, leaving significant gaps that expose them to cyberattack. And these risks are only going to grow. For example, a 2023 Cybersecurity Ventures report suggests that the cost of software supply chain attacks will increase from $46B in 2023 to $138B by 2031, a 200% increase.

Instead, FinServ companies should look to source and deploy a single, comprehensive solution that can span the entire software supply chain, which includes:

  • Import – the process of making available open source packages, code snippets, tools, or other third-party software brought into the organization in order to streamline the software development process.
  • Build – the process of compiling, building, and/or packaging code, usually via an automated system that also executes tests on built artifacts.
  • Consume – the process of working with, testing, and running built artifacts in dev, test, and production. 

Without a comprehensive approach, organizations face multiple potential attack vectors, including:

  • Development environments, which can be compromised by the introduction of malware and vulnerabilities. 
    • Malware-infected packages in 2023 totaled more than twice the total number discovered for all years combined since 2019, according to Sonatype’s latest State of the Software Supply Chain.
    • In 2023, the mean time to exploit a vulnerability was 44 days versus the 215 days it took to patch a vulnerability, on average.
  • Build environments, which can be compromised by the injection of compromised components.
    • For example, build systems that are not hermetically sealed can permit components to pull in remote resources during the execution of their build step. 
  • Software development process, where using built artifacts that are not signed and/or verified using a mechanism like Provenance Attestations raises the risk of compromise. 
    • For example, unsigned components that lack a Provenance Attestation should never be trusted since there is no way to verify their security and integrity. 

Software supply chain security solutions are designed to address these kinds of attack vectors, which traditional cybersecurity tools often miss. But not all supply chain security solutions are the same.

Proactive vs Reactive Software Supply Chain Security 

FinServ organizations too often treat software supply chain security like cybersecurity, implementing tools that generate yet more alerts that need to be investigated. This kind of reactive approach just increases the AppSec team’s workload, exacerbating cybersecurity burnout, which can result in an overwhelming deluge of alarms not all of which can be investigated in a timely manner. In fact, the 2023 Gartner Technology Adoption Roadmap for Large Enterprises Survey indicated that while two-thirds of respondents had either implemented or were adopting software supply chain security, most were failing to see success. 

While Gartner suggests this may be due to the initiatives being uncoordinated across the organization, we’ve found that a significant driver of failure can be the result of taking a reactive rather than a proactive approach to supply chain security.

For example:

  • Most FinServ organizations store their open source dependencies in an artifact repository. But the security, compliance, and IT approval process required prior to adding a new dependency (or even a new version of a dependency) to the repository can slow down development cycles. As a result, FinServ organizations can fall into the trap of standardizing on a set of “golden dependencies” that become vulnerable and out of date.  
    • A proactive approach enables evaluating and approving dependencies on a continual basis BEFORE they become vulnerable or outdated.
  • Statistics show that billions of older, vulnerable dependencies continue to be downloaded year after year from public repositories, despite the fact that a fixed version is available, according to Sonatype’s latest State of the Software Supply Chain. These older versions are often flagged during the CI/CD pipeline, creating more work for DevOps. 
    • A proactive approach ensures that runtime environments are always built with up-to-date dependencies.
  • Artifacts built in a non-reproducible manner may differ from one build to the next, raising the security and integrity risk of the built artifact. 
    • A proactive approach builds all artifacts with a hardened, tamper-proof, reproducible build system instead. 
  • Prebuilt open source dependencies sourced from a public repository are typically unsigned and lack a Provenance Attestation to help verify the security and integrity of the component. Typically scanners are employed, which generate alerts that must then be investigated. 
    • A proactive approach sources signed dependencies and their attestations from a trusted vendor.

And so on. Whether at the import, build, or consumption stage, taking a proactive approach to ensuring the security and integrity of your software supply chain can dramatically improve outcomes. By comparison, taking a reactive approach inevitably results in rework, increasing friction and slowing down development cycles.

While automation can help, especially if it’s based on policy that can eliminate exceptions that violate corporate guidelines, automating reactive processes typically ends up creating more follow up work than it resolves. Automated proactive tools, on the other hand, can significantly decrease the costs and resources required to secure your software supply chain.

This is what the ActiveState Platform can provide you: an automated way to create secure. reproducible builds of open source components from vetted source code using a hardened, tamper-proof build system. Provenance attestations and SBOMs are created for every built artifact, including each component and the overall runtime environment, as well. On use, each component is verified by the ActiveState command line tool (State Tool) to ensure its security and integrity have not been compromised.

In this way, you can take a proactive approach to securing your open source supply chain from import through the build process to consumption by developer and DevOps teams.

Conclusions

Implementing software supply chain security requires the participation of all affected stakeholders from security to software engineers to DevOps to compliance officers to IT and vendor risk managers. Collaboration is key. 

While the marketscape is complex, involving both traditional AppSec vendors and emerging software supply chain vendors, very few vendors offer a comprehensive solution that spans the entire import-build-consume chain. But cobbling together multiple point solutions increases complexity, maintenance overhead, and ultimately costs.

Instead, consider acquiring a single, centralized platform like ActiveState that can provide a collaboration point for all stakeholders, and can be easily integrated with your existing software development processes. When that platform can also provide an automated end-to-end solution that allows you to take a proactive approach to securing your software supply chain, the benefits can far outweigh the costs. 

Next Steps

Compare the different market solutions for software supply chain security in our Buyers Guide to Securing Your Software Supply Chain.