Protecting the software supply chain [Q&A]

As developers come under increasing pressure to deliver projects quickly, there's a rising level of conflict between development and security teams. And attackers are taking advantage of this conflict in order to target software supply chains.

So, what kind of threats do enterprises face and what can they do to protect themselves? We spoke to Pete Morgan, co-founder and CSO of supply chain security company Phylum to find out.

BN: Why is the software supply chain such an attractive target for attackers?

PM: There are three main reasons bad actors target software supply chains:

• Developers are the new high-value targets: Attackers know the targets of a supply chain compromise are software developers  or privileged infrastructure. Compromise of either target yields cloud access keys, SSH keys, signing keys and other secrets. These keys often live for long periods of time, meaning an undetected compromise allows attackers plenty of access and time to plan out the next stages carefully.
• There are a number of blind spots to exploit: The software supply chain is a constantly changing concept. Open-source packages are used in 85 percent -- 95 percent of applications and are created and maintained by strangers on the internet. Developers use these packages without oversight, or controls from the security team. Mapping out the true attack surface for an organization’s software supply chain is complicated and varies by organization, leaving many gaps. Maintaining it constantly over time is even harder, providing various opportunities for attackers. Defense has to be perfect, attackers only have to win once.
• Low investments for big payoffs: The cost to attack the software supply chain is extremely low, and often times free. Some attacks only require running a script and waiting. Until organizations level-up their software supply chain security programs, attackers know they don’t have to work that hard or use sophisticated attacks to be successful.

BN: What are the main friction points between development and security teams?

PM: Security teams want more visibility and control over the development process, and developers want as few roadblocks to innovation as possible. When goals, policy and process are not well aligned, or in this case often conflicting, friction will naturally exist.

BN: How can security improve the relationship with development teams?

PM: Empathy is a huge factor in finding common ground between these two teams, and it is essential for these two teams to work in harmony to meet critical business objectives. Security teams should incorporate developers into the early stages of security decision-making and make it easy for them to adopt policies, and developers should keep an open mind when asked to incorporate security practices into their processes. Open lines of communication, sharing regular feedback on what's working and what's not, and adopting technology that automates policy enforcement and contextualizes issues without interrupting the development process will lead to more effective cooperation.

BN: Why is malware in open-source packages so dangerous?

PM: Oh, where to start! Malicious packages are different than traditional malware in that most malicious packages don’t need to exploit any vulnerabilities or trick a user into executing them. A developer that installs the wrong package or installs a package that has the wrong dependency can be compromised, and 99 percent of the time they will never know.

Most developers simply do not have the time or tools to analyze the risk of the packages they use. Packages have dependencies which have dependencies, and that chain can be 20-30 levels encompassing tens of thousands of open-source packages. Most organizations are still only scanning for vulnerabilities and license misuse, so malware easily goes undetected: it's a smash-and-grab for keys and secrets to then mount further attacks.

BN: What are some other risks associated with open-source code that are often overlooked?

PM: There are many, but one that stands out is maintainer transition. It isn't a software vulnerability or malicious package; it's one of many author risks that stem from common practices in the open-source ecosystem. Sometimes, a developer no longer has the interest or time to maintain a popular open-source package. They often want to keep it functional for the users that rely on it, so they hand off maintainership to another individual, or group. It's incredibly difficult to vet the new maintainer's motives and incentives, so control of these packages is just put in the hands of a different stranger from the Internet. If a malicious author takes control of a package that is used in an application, that introduces new risk that was not accounted for in the initial build.

BN: How important is it to be aware of and manage dependencies?

PM: We should be critical of dependencies because the long-term inclusion of each package expands the attack surface drastically. We need to understand the risk in reusing code that changes constantly to effectively defend software. Otherwise, organizations will continue to re-use code from strangers on the Internet with a strategy of just hoping for the best. This is the reason software supply chain is in the news so much right now.

BN: How can SBOMs help with visibility and security?

PM: SBOMs are a step in the right direction, but I worry that regulations and mandates to adopt the SBOM process wholesale will result in a lot of motion without meaningful improvements to software security. The ideas of getting visibility into the components of a software project is a no-brainer, but the SBOM process I see passed around is woefully lacking as it only provides incomplete snapshots in time.

The information provided by SBOM is insufficient to cover the attack surface of the software supply chain, and the implications for vendor and consumer organizations to adopt the process of using SBOM assumes a reality where Application Security and/or Product Security budgets are effectively unlimited. SBOM formats and processes need to evolve significantly before they can be adopted in a meaningful way.

BN: What standards, norms or behaviors need to change for organizations to best protect their software supply chains?

PM: A fundamental mentality shift is required. Companies need to understand they are exposed to significant software supply chain risk now, and likely have been for a long time. Software supply chain security is in its infancy, so attacks are evolving daily, and defenses have only been created in the past couple of years. Assume your developers are actively being targeted and that you have unrealized exposure to software supply chain risk. Once you break through the false sense of security, you can start from an honest place to build an effective program that can scale based on your unique needs.

Image Credit: Manczurov/Shutterstock