Financial services companies need to make software supply chain security (SSCS) an integral part of their application security (app sec) testing programs because app sec and DevOps testing practices that focus on addressing vulnerabilities in pre-deployment and post-deployment code are no longer sufficient to mitigate security risks.
Why? Because threat actors are increasingly targeting different stages of the software life cycle to compromise systems, hijack accounts, steal data and take other malicious actions. Common vectors include attacks on code repos and build environments, stealing tokens and secrets from CI/CD pipelines, injecting malware into open-source components and third-party libraries and tampering with trusted commercial software products.
Here's what you need to know about the limits of app sec testing, and why comprehensive software supply chain security is critical to mitigating risk.
[ See report: Why Traditional App Sec Testing Fails on Supply Chain Security | Get up to speed with RL's new report: The State of Software Supply Chain Security 2024 ]
Beware the huge blast radius
Threat actors have discovered that attacks on the software supply chain can have a huge "blast radius" and are therefore focusing more attention on them. During the breach at SolarWinds, for example, an adversary infiltrated a build environment and introduced malicious changes to digitally signed code that subsequently ended up getting distributed to downstream customers.
More recently, a security breach in the CircleCI development platform exposed API security tokens and other secrets used by millions of developers in their projects. And in a 2021 incident, a vulnerability in the Travis CI hosted service exposed secrets associated with hundreds of thousands of open-source projects.
These threats apply to software that a financial services company might develop internally as well as to any commercial software products they use. Many organizations, whether they are aware of the threat or not, don't have enough visibility into this issue. Although some are putting in a lot of effort, there is no evidence that they are successfully mitigating these software supply chain risks.
There is a tools gap and a knowledge gap in the industry when it comes to understanding the breadth of attacks that can happen in the software lifecycle, from development through consumption, and the detection logic for protecting against them.
Lack of visibility is a key problem
Many large financial services companies that develop software internally have application security testing practices that don't offer visibility over threats such as credential theft and misuse, session hijacking, compromise of open-source libraries and frameworks, tampered secrets and container breakouts.
Existing app sec testing practices can't verify that your components have come from a trusted source. Existing software composition analysis (SCA) toolchains can't analyze obfuscated binaries. They depend on known vulnerabilities and signatures and do not integrate threat intel on new and novel attacks.
Many security teams in the financial sector are still going down the rabbit hole of looking for and patching exploitable vulnerabilities in code. While this is essential to security, software vulnerabilities are only one initial access point. Vulnerabilities are not the only vector, or even necessarily the most common one.
A 2022 study by analyst firm Cyentia showed that in previous financial services breaches, attackers most often abused valid credentials in order to gain initial access to a victim network or system. The second most common vector was abuse of a trusted third-party relationship, followed by phishing.
Historically, in the financial sector, adversaries have demonstrated they can compromise a software supply chain without the use of malware or known vulnerabilities.
Evolve your AppSec to include supply chain security
Financial companies need to evolve their supply chain risk management programs to comprehensively account for software supply chain security. If you are working for a multinational institution with your own internal development team, focus on building a cohesive security program that goes beyond app sec and DevSecOps and that converges SOC and dev through frameworks, threat hunting and proactive attack emulation. Build out an app sec program with skill sets that have a foundational understanding of software supply chain security.
A binary analysis of your gold images and a one-time scan of all commercial off-the-shelf applications in the environment can provide a baseline and foundation for understanding where you stand and what you need to do. Once you decide to build out a software supply chain security program, consider using industry standards and frameworks, where available, to help guide the effort.
The Open Software Supply Chain Attack Reference (OSC&R) is one example. OSC&R can help you understand attacker behavior and techniques in software supply chain attacks. You can use it to emulate attacker behavior so you can evaluate your existing defenses and identify threats that need prioritization.
When evaluating risks consider the security properties of the specific code you use and their dependencies on open-source and third-party libraries and frameworks. If you are an investment banker, for instance, you probably rely heavily on risk management systems, many of which use C++ and are dependent on OpenSSL libraries. Most financial trading firms, on the other hand, use Java, so your focus would on threats to npm and Struts.
An effective software supply chain security program will have capabilities for detecting unexpected or suspicious behavior within software components and be able to identify differences across release versions that might signal a supply chain attack. You also will need to have a good understanding of threats to commercial software.
Software suppliers such as SolarWinds are a target of interest to adversaries because these vendors often have an extensive footprint and reach, and often their products are heavily dependent on open-source and third-party code.
Protect your software development secrets
Protecting secrets is key to software supply chain security. Any financial institution that is creating software has a DevOps teams using some kind of a CI/CD pipeline tool and it is likely generating secrets and machine identities. You need to have policies to understand how these secrets get generated, protected and cycled. You have to figure out how to build better detection when secrets get exposed and misused, and enable visibility and controls around your certificate signing process.
Bridge the AppSec team gaps
Make sure your application security, DevSecOps and threat intelligence teams are collaborating. Bridge the gaps between the security team and the development team, and base your defenses on a full understanding of adversary behavior, rather than just on detecting vulnerabilities in code and reactively patching it.
There is no bigger blast radius right now than a supply chain attack. What is your strategy for addressing the threat? Do you understand where you are today?
