Financial services companies need to make software supply chain security (SSCS) an integral part of their application security (app sec) testing program. 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.
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.
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. The breach at SolarWinds is an example where an adversary infiltrated a build environment to introduce malicious changes to digitally signed code that subsequently ended up getting distributed to downstream customers.
More recently, a security breach of the CircleCI development platform exposed API security tokens and other secrets used by millions of developers in their projects. Similarly, 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 service company might develop internally and also to any commercial software products they use. Many organizations, whether they are aware of the threat or not, don't have enough visibility into the issue. Though some are putting in a lot of effort, there is no evidence they are successfully mitigating 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 cannot verify if your components come from a trusted source. Existing SCA toolchains cannot analyze obfuscated binaries. They depend on known vulnerabilities and signatures and do not integrate threat intel on new and novel attacks.
A lot of 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 vector.
A 2022 study by analyst firm Cyentia showed that in previous financial services breaches, attackers most commonly abused valid credentials 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 app sec to include software 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 a multinational institution with your own internal development team focus on building a cohesive security program that goes beyond app sec and DevSecOps and 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 an 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 on the other hand use Java so your focus would on threats to npm and Struts.
An effective software supply chain security program would 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 would 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 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 app sec gaps
You need to make sure your application security team, DevSecOps team and threat intelligence are collaborating and talking with each other. 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 them.
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?