fossa.com Open in urlscan Pro
18.66.122.42  Public Scan

Form analysis
2 forms found in the DOM

<form id="mktoForm_1377" novalidate="novalidate" class="mktoForm mktoHasWidth mktoLayoutLeft" style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; color: rgb(51, 51, 51); width: 401px;">
  <style type="text/css">
    .mktoForm .mktoButtonWrap.mktoSimple .mktoButton {
      color: #fff;
      border: 1px solid #75ae4c;
      padding: 0.4em 1em;
      font-size: 1em;
      background-color: #99c47c;
      background-image: -webkit-gradient(linear, left top, left bottom, from(#99c47c), to(#75ae4c));
      background-image: -webkit-linear-gradient(top, #99c47c, #75ae4c);
      background-image: -moz-linear-gradient(top, #99c47c, #75ae4c);
      background-image: linear-gradient(to bottom, #99c47c, #75ae4c);
    }

    .mktoForm .mktoButtonWrap.mktoSimple .mktoButton:hover {
      border: 1px solid #447f19;
    }

    .mktoForm .mktoButtonWrap.mktoSimple .mktoButton:focus {
      outline: none;
      border: 1px solid #447f19;
    }

    .mktoForm .mktoButtonWrap.mktoSimple .mktoButton:active {
      background-color: #75ae4c;
      background-image: -webkit-gradient(linear, left top, left bottom, from(#75ae4c), to(#99c47c));
      background-image: -webkit-linear-gradient(top, #75ae4c, #99c47c);
      background-image: -moz-linear-gradient(top, #75ae4c, #99c47c);
      background-image: linear-gradient(to bottom, #75ae4c, #99c47c);
    }
  </style>
  <div class="mktoFormRow">
    <div class="mktoFormCol" style="margin-bottom: 10px;">
      <div class="mktoOffset mktoHasWidth" style="width: 10px;"></div>
      <div class="mktoFieldWrap">
        <div class="mktoHtmlText mktoHasWidth" style="width: 400px;">
          <h2 class="formheader" style="font-family: Opensaucetwo, sans-serif; font-size: 3rem !important;">OSS News and Insights</h2>
        </div>
        <div class="mktoClear"></div>
      </div>
      <div class="mktoClear"></div>
    </div>
    <div class="mktoClear"></div>
  </div>
  <div class="mktoFormRow">
    <div class="mktoFormCol" style="margin-bottom: 10px;">
      <div class="mktoOffset mktoHasWidth" style="width: 10px;"></div>
      <div class="mktoFieldWrap">
        <div class="mktoHtmlText mktoHasWidth" style="width: 400px;">
          <p class="formsubheader" style="font-size: 1.8rem; font-family: Opensaucetwo, sans-serif;">Delivered Straight to Your Inbox</p>
        </div>
        <div class="mktoClear"></div>
      </div>
      <div class="mktoClear"></div>
    </div>
    <div class="mktoClear"></div>
  </div>
  <div class="mktoFormRow">
    <div class="mktoFieldDescriptor mktoFormCol" style="margin-bottom: 10px;">
      <div class="mktoOffset" style="width: 10px;"></div>
      <div class="mktoFieldWrap mktoRequiredField"><label for="Email" id="LblEmail" class="mktoLabel mktoHasWidth" style="width: 0px;">
          <div class="mktoAsterix">*</div>
        </label>
        <div class="mktoGutter mktoHasWidth" style="width: 10px;"></div><input id="Email" name="Email" placeholder="Subscribe to Our Newsletter" maxlength="255" aria-labelledby="LblEmail InstructEmail" type="email"
          class="mktoField mktoEmailField mktoHasWidth mktoRequired" aria-required="true" style="width: 350px;"><span id="InstructEmail" tabindex="-1" class="mktoInstruction"></span>
        <div class="mktoClear"></div>
      </div>
      <div class="mktoClear"></div>
    </div>
    <div class="mktoClear"></div>
  </div>
  <div class="mktoButtonRow"><span class="mktoButtonWrap mktoSimple" style="margin-left: 120px;"><button type="submit" class="mktoButton">Subscribe</button></span></div><input type="hidden" name="formid" class="mktoField mktoFieldDescriptor"
    value="1377"><input type="hidden" name="munchkinId" class="mktoField mktoFieldDescriptor" value="246-JVA-804">
</form>

<form novalidate="novalidate" class="mktoForm mktoHasWidth mktoLayoutLeft" style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; color: rgb(51, 51, 51); visibility: hidden; position: absolute; top: -500px; left: -1000px; width: 1600px;">
</form>

Text Content

Toggle navigation
 * License Compliance
 * Security Management
 * About FOSSA
 * Contact Us

 * License Compliance
 * Security Management
 * About FOSSA
 * Contact Us
 * Request Demo

Request Demo

 * Vulnerability Management
 * License Compliance
 * Open Source in the News
 * Software Composition Analysis
 * Developers


30 September 2021 / Open Source Vulnerability Management


HOW TO DEFEND AGAINST SOFTWARE SUPPLY CHAIN ATTACKS

Software supply chain attacks are exploits where a bad actor compromises a piece
of software that’s used by multiple targets — i.e. something in the supply
chain. Software supply chain threats differ from (and have the potential to be
more damaging than) classic attacks because a single breach can impact hundreds
or even thousands of different targets.

Consider the hypothetical where I’m a cybercriminal and want to inject malicious
code into N different targets.

In a classic attack, I’d need to come up with around N unique exploits to affect
each system. While I may be able to reuse the same attack mechanism against
multiple targets, there is no guarantee that will work in every case. Even
worse, it’s possible that any of those N targets has relatively good security
measures and is very hard to breach.

Now, consider a supply chain attack that aims to hit the same N systems. I only
need to infect a single shared dependency of those N targets. What makes this
even more dangerous is that I can try to find the easiest attack surface from a
myriad of other sources now that I’m not constrained to only attacking my
unsuspecting victims' environments directly. Now, whenever any of these N
systems uses or pulls in this shared dependency, they’re also importing the
trojan of my choosing.

This is what makes software supply chain attacks so dangerous. One successful
attack can affect a wide swath of machines.

So, what strategies can security and engineering teams employ to defend against
supply chain threats? What tools provide the strongest protection? Read on for
answers to these questions, as well as an overview of three particularly
devastating supply chain attacks.

RELATED: Application Security for Developers | Log4J Impact and Fixes


SUPPLY CHAIN ATTACK EXAMPLE 1: EVENT-STREAM TROJAN

We’ll start our review of supply chain attacks with a look at the event-stream
trojan. event-stream was an npm package whose maintainer no longer wanted to
maintain the package, so they transferred its publishing rights. The new
maintainer added a dependency called flatMap Stream, which initially was benign
and worked as expected.

However, they later updated flatMap Stream to have malicious code that would
sniff for bitcoin wallets with more than 100 bitcoins in them and send secret
keys off to a remote server. If you updated your event-stream package or any of
your dependencies and you had a version range defined for flatMap Stream, it
would innocuously and unceremoniously pull in the malicious version.

Here, there was a single shared resource (the npm registry). The attackers
targeted Bit Pay, but the exploit impacted other companies including Microsoft
and most other unsuspecting event-stream users.

Thank you for submitting details. Your email address is added to our
subscription list.


OSS NEWS AND INSIGHTS





Delivered Straight to Your Inbox




*




Subscribe


SUPPLY CHAIN ATTACK EXAMPLE 2: SOLARWINDS ORION PLATFORM

The SolarWinds Orion incident is perhaps the most well-known example of a
software supply chain attack. It happened because hackers got access to secure
credentials — in case you’re wondering, SolarWinds123 is not a good password if
your company is SolarWinds, or for that matter any company.

Once the attackers compromised these credentials and gained access to
SolarWinds’ network, they started to add malicious code throughout SolarWinds’
system. Specifically, the hackers targeted the Orion Platform, which is used for
infrastructure monitoring and some security features for large organizations.
The Orion Platform was considered a single, trusted resource. If a user
downloaded from SolarWinds, they expected the payload to come from SolarWinds.

But once that payload was maliciously updated, we witnessed something similar to
the event-stream attack. The SolarWinds Orion Platform was compromised, which
then affected hundreds of organizations including the Federal Reserve,
Microsoft, Fire Eye, and the Department of Energy. This exploit has been an
ongoing thorn for well over a year at this point and still plagues many
companies and the U.S. government.


SUPPLY CHAIN ATTACK EXAMPLE 3: CODECOV BASH UPLOADER

More recently, we had the Codecov bash uploader compromise. Bad actors gained
access to credentials due to an error in Codecov’s Docker image creation
process; the attackers were then able to change Codecov documentation and modify
the script (which was included in the documentation) used to install the tool in
CI environments.

For context, Codecov is a code coverage tool that integrates into your CI
environment. You download a script to upload your code coverage results to
Codecov's server. And, attackers were able to change that particular script.

Modifying the script enabled the attackers to exfiltrate secret environment
variables, which is particularly bad if you deploy your production services from
the same CI in which the compromised script was run. It means that all of your
secrets for production should be considered compromised. To make matters worse,
Twilio, GoDaddy, and most other Codecov users had no idea an attack occurred
until someone checked the hash of the payload and noticed it didn’t match what
the hash would have been from the upload script on Github.


DEFENDING AGAINST SUPPLY CHAIN ATTACKS

Now that we’ve discussed the specific tactics used in supply chain attacks,
we’ll shift our focus to preventing them. Broadly, we’ll group these defense
mechanisms into two categories: strategies and tools.


STRATEGIES FOR DEFENDING AGAINST SUPPLY CHAIN ATTACKS

 1. Use lockfiles: Lockfiles will pin the versions of every package in your
    dependency graph, and often they will be pinned to a specific registry. This
    means that even if a new version is published and your semver range
    specification allows your code to use it, the lockfile will not be changed
    unless you explicitly update it. Additionally, most lockfiles include hashes
    that can detect man-in-the-middle attacks where the package payload has
    changed.
 2. Always try to validate checksums of any software that you use: Do this
    whether it involves developer tools or source code.
 3. Vendor dependencies into your source control: Don’t just install from a
    repository every time you want to install your dependencies. When you
    actually vendor in your dependencies, you’re guaranteed nothing will change
    unless you change it.
 4. Inspect all the code that’s being used in production: This is obviously
    very, very high overhead. But there are certain domains where this is
    necessary. For example, I used to work at Capital One, and if you wrote code
    that moved money in any way, there was a team that would audit all of the
    code, whether it be first-party or third-party. This auditing team would
    take a significant amount of time and prevent production deployments until
    they gave the thumbs up.
 5. Request a software bill of materials where and when possible: If practical,
    it’s generally useful to ask suppliers to produce an SBOM to accompany any
    piece of software. This, of course, helps improve visibility into your
    software supply chain.
 6. Consult NIST’s Guidelines on Minimum Standards for Developer Verification of
    Software: As part of the Biden Administration’s Executive Order on Improving
    America’s Cybersecurity, NIST (The U.S. government’s National Institute of
    Standards and Technology) published 11 recommendations for software testing.
    These include threat modeling, testing, code-based structural test cases,
    and more.


TOOLS FOR DEFENDING AGAINST SUPPLY CHAIN ATTACKS

 1. Software composition analysis solutions identify and provide remediation
    guidance for known vulnerabilities in open source code. This is an important
    part of security tech stacks given the popularity of OSS in modern software
    development — it’s estimated that open source comprises 85-90% of the
    average application.
 2. Google recently published its SLSA framework (Supply Chain Levels for
    Software Artifacts), which is meant to expose metadata in a software
    artifact throughout different stages of the software development lifecycle.
    The framework aims to ensure the “integrity of software artifacts throughout
    the software supply chain.”

A common thread in many of these strategies and tools is visibility: Oftentimes,
knowing that something is off goes a long way toward strengthening your defenses
against these attacks. Going all the way back to the event-stream trojan, that
particular attack was discovered because of a warning that was published on
install about a soon-to-be deprecated network call on a package that wasn't
supposed to be connected to the internet. That prompted someone to realize
something was wonky.

The event-stream trojan, like the SolarWinds and Codecov incidents that followed
it, also shows just how dangerous these attacks can be. They can be hard to
detect unless you have the proper approach and infrastructure to identify
anomalous behavior.

About the Author: Matt Schwartz is a team lead and senior software engineer for
FOSSA, focusing on expanding and improving the company’s security offerings.
Outside of FOSSA, he has worked with several organizations on security and
security infrastructure, including the Barbados government, and responsible
disclosures to various companies.


TRY FOSSA FOR FREE

Begin managing your Open Source dependencies today.

Sign up with Github Request a Demo

MATTHEW SCHWARTZ

Read more posts by this author.

Read More
— Dependency Heaven —


OPEN SOURCE VULNERABILITY MANAGEMENT


 * How to Quickly Find and Remediate Log4J Vulnerabilities (Log4Shell)
 * How to Fix the New Log4J DoS Vulnerability: CVE-2021-45105
 * Log4J "Log4Shell" Zero-Day Vulnerability: Impact and Fixes

See all 10 posts →
Software Composition Analysis


Q AND A: SOFTWARE BILL OF MATERIALS AND FOSSA

Get answers to frequently asked questions about using FOSSA to generate a
software bill of materials.

 * FOSSA Editorial Team

6 min read
Software Composition Analysis


HOW TO GENERATE A SOFTWARE BILL OF MATERIALS WITH FOSSA

See how your organization can use FOSSA to generate a comprehensive software
bill of materials in a few easy steps.

 * Deepak Mehta

5 min read
Dependency Heaven
—
How to Defend Against Software Supply Chain Attacks
Share this

 * For the Love of Open Source © 2021 FOSSA, Inc.
 * Privacy Policy
 * Terms & Conditions