What's YOUR supply chain?

Take a look behind the curtain at the Prelude Operator software dependencies

Like a lot of security organizations, the SolarWinds attack made us pause. What is our own stance on supply chain management?

Here at Prelude, we believe in extreme transparency as the avenue for building trust. We invest in our open-source work, publishing a Community repository of TTPs and a powerful GoLang agent, among other open-source projects. But we want to do more. We want to encourage organizations to apply real pressure on their software vendors - especially those in security (given the level of access most security programs require) - to expose their software dependencies.

Why do this?

Every external library a software product includes is a calculated risk. Because libraries (i.e., dependencies) are written, updated and managed by external programmers, there is no guarantee that the software doesn't perform surveillance, exfiltrate important data out of the program or network where it is installed or worse, morph into a data corruption tool.

Libraries which are open-source can be independently verified. But many smaller tools never go through this evaluation. And worse, even if you're the rare organization which validates each software package, the next update it has may introduce a vulnerability.

A typical supply-chain use case

Here's how it usually works.

A Python programmer says, "I need to schedule a function to run at a specific day/time. I could write code which mimics the cron job functionality on Unix machines but that's complicated. Instead, I'll just import someone else's library."

They head to Google and search for python cron job pip which yields a number of free software libraries:

They then pick one (python-cronjob, for example) and go into their source code's requirements.txt file and add the new dependency:

And just like that, a new business risk was adopted, all without a second thought or anyone on the business end of the company even realizing. The following questions were never asked: Who wrote the library? Which country is it coming from? Who is funding the development effort of the "free" library?

Notice anything else in the above screenshot?

A programmer should note the lack of versioning in the dependency file. This means the most current version of each of these dependencies will be installed on each new installation of whatever program is being built. Which in turn means, if a given library introduces a vulnerability between versions, you'll get it. It is a better idea to "pin" your dependencies to known/validated versions and upgrade carefully. Much better:

We'll show you ours..

At Prelude, we support projects in multiple languages, ranging from Golang to Python and NodeJS, among several others. As we do peer code reviews internally, one thing we take special note of is limiting the number of external dependencies we include. We only include those which are required to do the job at hand, and even then, we only include it if there is no feasible alternative. I like to call it the minimal dependency plan. Programmers call it difficult. Minimizing your dependencies means programmers will have to code more library functionality themselves.

You don't want to reinvent the wheel - but you also don't want to inherit unnecessary risk. It's up to you to determine your personal appetite for risk vs developer time.

Prelude Operator is a desktop application, written in NodeJS using the Electron framework. As of this writing, here are our dependencies:

"@elastic/elasticsearch"
"@grpc/grpc-js"
"@grpc/proto-loader"
"auto-launch"
"codemirror"
"dotenv"
"electron-log"
"electron-notarize"
"electron-updater"
"glob"
"history"
"js-yaml"
"lunr"
"ramda"
"react"
"react-codemirror2"
"react-dom"
"react-redux"
"react-router-dom"
"redux"
"redux-logger"
"redux-thunk"
"splunk-logging"
"ssh2"
"styled-components"

Phew, we did it.

We hope that as you use Operator, you'll challenge us from now and again about any new dependencies we've added - and why. We also hope you do the same for each software vendor you use and adopt in your organization. Each piece of software opens up a risk, so you should calculate each appropriately.