What is Software Supply Chain Security?

The software supply chain encompasses everything influencing or playing a role in a product or application during its entire software development life cycle (SDLC).

In recent years, attacks on the software supply chain are becoming more prevalent and more sophisticated. In their 2022 report, Gartner states: ”Anticipate the continuous expansion of the enterprise attack surface and increase investment in processes and tools for identity threat detection and remediation and digital supply chain integrity.”

It is more important than ever to secure all components, activities, and SDLC practices involved in the creation and deployment of software. Development teams and software vendors must ensure they only utilize code components free from known vulnerabilities and find ways to validate the integrity of their build, checking for unauthorized tampering.

Before we dive in, let’s agree on what Software Supply Chain risk is

For consumers, software supply chain risk refers to any threats from the inclusion of 3rd party code in the product, production, or IT environment. For software vendors, it relates to the risk of providing customers with software containing malicious code or a critical vulnerability. Software supply chains result in a series of dependencies between the various packages used, including open source libraries and proprietary code. Attackers can target the weakest link within this complicated chain to compromise the entire application.

Recent research by Synopsis found that 97% of codebases contain open source components, and worryingly 85% contain open source software that hasn’t been updated for more than four years. Plus, the open source packages you use depend on other open source elements themselves, with the chain going on and on.

It is hard to keep track of all the transient dependencies within a project. Given how fast the open source system changes, it can be challenging just to maintain visibility and stay on top of all the components actually used by your code, let alone the implications deriving from them. Often organizations use only implicit trust when including 3rd party packages. This assumption is the opposite of well-known “zero-trust” security architecture investments.

Attacks on software supply chains: why are they so common?

Modern software pipelines are automated environments that rely on a variety of tools for continuous integration and continuous delivery. A software project may end up including thousands of open source dependencies.

Malicious actors can pass off rogue libraries as legitimate by exploiting "logical flaws" in open-source package managers. For example, malware-laced packages can be ascribed to trusted maintainers without their knowledge. Such misplaced trust can introduce problematic and hidden vulnerabilities in your code. These vulnerabilities can provide attackers with access to sensitive data or allow them to plant malware and control systems throughout the supply chain.

The modern development environment has its own vulnerabilities, and a variety of software supply chain attacks targeted the CI/CD pipeline to insert malicious code at some point throughout the development process. Here too, a zero trust assumption is the adequate approach to gain trust in the final software product - check, verify and validate every step in the internal development chain.
Today’s CI/CD pipelines lack visibility and controls to adequately protect the software development process. They also struggle to detect code tampering, making this attack vector even more attractive.

The SSDF (NIST 800-218) has been finalized and is in effect

The SSDF (NIST 800-218) framework requires suppliers to implement security practices covering the Software Development Life Cycle (SDLC). It promotes transparency and tamper-resistant measures in an effort to reduce security vulnerabilities and malicious interference.

Specifically, it contains guidelines for an evidence-based approach to protecting the software itself from being tampered with.

The SSDF has four main parts:

01/
Prepare the Organization (PO):

Ensure that people are prepared and processes and technology are in place to perform secure software development at the organization level and, in some cases, for individual development groups or projects.

02/
Protect the Software (PS):

Protect all software components from any unauthorized access or tampering.

03/
Produce Well-Secured Software (PW):

Produce well-secured software with minimal security vulnerabilities in its releases.

04/
Respond to Vulnerabilities (RV):

Identify residual vulnerabilities in software releases, respond appropriately to address those vulnerabilities, and prevent similar vulnerabilities from occurring in the future.

You should not refer to the SSDF as a checklist but rather as a guide for planning and implementing a risk-based and evidence-based approach to developing secure software.
Companies must take steps to improve their security posture in order to facilitate compliance with emerging regulatory changes.

SLSA is a framework you ought to comply with

A framework originated at Google, called SLSA (Supply-chain Levels for Software Artifacts), provides guidelines for how to reach four levels of software supply chain protection. The framework focuses on the integrity of the artifacts’ build with the intention of preventing tampering and securing artifacts.

SLSA works this way: You implement checklists of security controls you should implement in your pipeline, and these controls are in subdomains such as source control systems, build systems and dependencies that you bring into your software projects.

SLSA lays out four levels of compliance with the objective of getting to level 4, which would have the highest security value, but would have a longer list of requirements.

The SLSA framework is based on the concept of provenance. A document that represents a “chain of evidence” denoting the artifacts’ origin and build process. As you go up the SLSA levels, you need to better protect the evidence itself.

You should consider SLSA as an industry standard, a recognizable and agreed-upon level of protection and compliance you have to adhere to.

How to secure your software supply chain?

The different frameworks we mentioned define the principles for securing the software supply chain and require your attention.

However, we would like to underline three main classes of security controls:

1. Secure the configuration of your software development lifecycle

Compromised credentials, insufficient control of permissions, and vulnerable build systems create attack surfaces that affect the software producer. Attackers exploiting these vulnerabilities can steal unsecured secrets or tamper with software artifacts. A range of commercial and open source solutions in this class may provide controls to map gaps in the security posture and remediate them.

2. Avoid relying on vulnerable or malicious dependencies

Invariably, new vulnerabilities will continue to be discovered in open source and commercial software. Software producers must mitigate this risk by upgrading vulnerable open source components, scanning for self-inflicted vulnerabilities in their proprietary code, and informing software consumers about the software bill of materials (SBOM) and its associated implications. These consumers can, in turn, take action accordingly.

Hijacked open source project accounts and malicious packages masquerading as legitimate, pose additional risks, primarily affecting secret stealing from pipelines. The open source community and some commercial vendors are working to address this through enhanced reputation and malicious behavior detection.

3. Validate the integrity and the secure build of the software artifacts

Cybersecurity requires defense in depth. Attacks can slip through the cracks when using the traditional attack surface reduction, detection, and reputation approach to protection. Moreso, nowadays, downstream software consumers have little influence over these controls. At most, they can rely on point-in-time security audits, such as code scanning that provides a vulnerability snapshot, of suppliers that do not create a real trust that the software artifact is well-secured and protected against during the development lifecycle.

A new, emerging class of controls is now available that continuously attests to every software artifact build's integrity and secure development process. These attestations are non-reputable and can be shared between producers and downstream consumers looking for validation. Non-repudiation is achieved by cryptographic methods and, therefore, significantly raises the price for any attacker infiltrating the supply chain.

This approach is considered essential by experts in the field of software supply chain security. However, while some open-source building blocks exist to support this class of controls, only a few vendors can provide an integrated solution.

A full software supply chain solution must include:

The collection of evidence and signing it as attestations from the software development and build processes. Typically, this evidence is file hashes with metadata that are compared between relevant steps in the process, events about security-related steps such as code committer identities, code reviews, automatic security tests, and so on. It is also necessary to provide an attestation as to the security posture of the software producer’s build process at the time the software artifact was built.

A secure attestation store that allows visibility and supports analytics such as validating code integrity.

A policy engine that measures these attestations against an organizational defined policy or a standards-based one for validation and demonstration of compliance.

A sharing hub for trust-related information between software producers or consumers; this could be inter or intra-enterprise).

Validating software integrity is challenging

Theoretically checking code integrity should be easy. Just compare files, right? In reality, there is a lot to consider. For starters, each language compiles files differently. On top of that, files are used very differently depending on their purpose. Some are meant to change, while others are deleted, and others are created during the compilation process.

Add to that the fact companies don’t want to hand over their proprietary code to each other.

Scribe Security - Continuous code assurance throughout the entire SDLC

Scribe sets out to secure your entire SDLC continually. With evidence collected from various parts of the development and build process, Scribe uses digital signing to create unfalsifiable attestations.

Once signed, each piece of evidence can be later verified to ensure all processes took place as planned and no unplanned alterations took place.

Following the best practices laid out in the SSDF, Scribe allows you to employ common sense policies to increase your confidence throughout the development process. Policies such as requiring signed commits, 2FA for developers, 2-person code review, etc., help generate trust that each piece of software was produced following the correct security posture.

Collecting all this evidence in a single location, along with a code integrity report and a summary of all policies and attestations allows for greater visibility and confidence in the development process and the software artifacts produced at the end and is aligned with the SSDF guidelines that stand at the basis of the new cyber regulation.

Allowing select subscribers to view the product’s compliance with policy requirements and integrity results offers users greater visibility and trust in your development pipelines and final software product.

The end result is not only detecting code or pipeline tampering but also the ability to attest to the tests and security procedures that took place during the design and build of the software, as well as the integrity of the source code and the open-source packages used in building it.

Automating SLSA-compliance evaluation

The security of dynamic pipelines must be continuously measured. SLSA (Supply-chain Levels for Software Artifacts) defines four software supply chain protection levels along with guidelines on how to reach them.

An SLSA compliance evaluation can be automated to meet their requirements. But how should an organization go about acquiring one? Are there specific best practices you should follow?

Watch this video where we share best practices for implementing automation, using open-source tools such as Sigstore and OPA in real-world scenarios. Both conceptual and technical best practices shed light on real-world details and challenges of evaluating and automating SLSA compliance.

Before using Scribe After using Scribe
Trust Hub – Information sharing

  • A generated SBOM is saved locally per single pipeline, without the ability to manage or share them with stakeholders across the organization or externally.

  • Sharing and managing SBOMs, both internally within the organization with other stakeholders and externally with customers or users
  • Intelligent SBOM with actionable insights
  • SBOM insights can be used as a go/no-go ‘gate’ on the pipeline or product, used to determine if the resulting image matches what was expected
  • Syncing between different teams and orgs is now possible

Secure SDLC – Policy & compliance

  • No automatic or resilient way to make sure that secure SDLC policies were followed as required.

  • An evidence-based reliable way that assures secure SDLC policies were enforced according to the most recent software supply chain security regulations and frameworks (SLSA 3, SSDF)

Integrity & Tamper detection

  • Only what you can glean from logs and APIs
  • Not signed until the very end of the process – right before the delivery (relates only to ‘final lag’ MITM)

  • Continues code assurance using continuous code hashing and signing at every stage of the development process allows validating that the final artifact is what it meant to be and that no malicious code was inserted by a bad actor during the development and delivery processes.

Visibility

  • Whatever you can glean from logs and APIs
  • Saved locally and Not signed, leading to the possibility malicious actors tampered with it

  • Signed attestations saved to a separate secure – tamper-proof evidence store

Security posture

  • Checking for CI/CD tools’ misconfigurations
  • Looking for leaked Secrets
  • Checking for known vulnerabilities (CVEs)

  • Checking for SDLC gaps in your CI/CD toolchain.
  • Checking for known vulnerabilities (CVEs) and OSS repos’ reputation
  • Registering tamper-proof attestations that the required security measures were taken in time at every stage of the process according to the organizations’ SDLC policy.

Scribe Security - a new Software Supply Chain Security standard

Continuous code Assurance is comprised of processes and tools that:

Track every detail and event in the software development process, as well as the integrity of the software components and artifacts

Verify that tampering has not occurred in any and all parts of the software development process

Verify the integrity of the CI/CD tools used to build the code

Confirm the integrity of the development process - ensuring that security-related steps were conducted according to the organization’s policy and have not been bypassed

By collecting and signing evidence of anything and everything that happens to the code, at every stage of the development life cycle you make it more difficult for attackers to tamper with files, tools, or the expected behavior of your CI/CD pipeline.

How can help?

Our unique platform ensures code artifacts are secure from Git to production throughout the entire software development lifecycle, using the leading security concepts and frameworks.

Our customers, responsible for securing software builds and software in use, rely on Scribe to ensure their software is secure and trustworthy.

Software supply chain attacks have become more prevalent and sophisticated in recent years. According to a Gartner report, the number of software supply chain attacks is predicted to triple by 2025, affecting nearly half of all organizations worldwide. As a result of this growing threat, securing all components, activities, and SDLC practices is more important than ever.

An SBOM (Software Bill of Materials), is a set of information about the many components that make up a software product or application. It usually contains licensing information, version numbers, component details, vendors, etc. Such a detailed and formal list decreases risks for both the manufacturer and the user by allowing others to understand what’s in their software and act accordingly.

SBOMs allow visibility of product components, enable easier vulnerability scanning, leverage licensing governance ft, and can be used to analyze threats to Integrity.

Continuous Assurance aims to dispel the software supply chain’s blind spot. It involves collecting signed evidence about every event in the development life cycle that may affect the security of the final software product, including product build and deployment. Today, enterprises use a variety of security tools to make their software products more secure. However, they rarely establish a policy for consistent use of these tools.

Continuous Assurance ensures that software products were not tampered with during development and that security-related tests were performed.

Minor code changes may go undetected for a long time. A few dozen lines of code can make the entire change, which is well concealed within the original class. Development teams trust the owner of the code if the modified product is properly signed. As a result, malware-laced packages can be created and assigned to trusted, popular maintainers without their knowledge. A case of misplaced trust could mean a problematic vulnerability or outright malicious code hidden in your code.

It is also common for developers to copy and paste code from existing libraries or StackOverflow to use in their own code or to upload to new libraries. This increases the chances of also copying insecure and vulnerable code that is now essentially untrackable. Despite the original code getting a CVE and eventually remediation, the problematic function you copied is invisible and might contaminate any codebase that uses it.

NIST released the final version of SSDF 1.1 (Secure Software Development Framework) on March 22nd. In September 2021, a draft version of the framework was published. Many of the differences are centered around the various examples provided rather than high-level practices and tasks.

When deciding which practices to implement, NIST recommends balancing risk against cost, feasibility, and applicability. To ensure software security, automation of as many checks and processes as possible is a key feature to consider.

There is more emphasis on integrity verification, both for your code and for libraries/products you acquire from outside. It should be clear which party is responsible for each practice and task and how each provider will attest to their conformance with the agreement.

Building trust in your software is an important task, especially given the new standards and best practices, such as SSDF and SLSA. Moreover, soon those vendors who can’t prove this trust and share it with their users will not be able to sell to the US federal government and later on work with companies who sell to the federal government.

To build trust, you would need to retain and share with stakeholders the software bill of materials (SBOM) of your products along with evidence about their secure development and build.

Only a truly end-to-end software supply chain security solution would provide you with this capability. A solution that applies continuous code assurance throughout the software development lifecycle in a zero-trust approach and automatically generates shareable product SBOMS so you can gain insights around vulnerabilities and code tampering.

Dynamic pipelines must be continuously monitored for security. In SLSA (Supply Chain Levels for Software Artifacts), four levels of protection for software supply chains are defined, along with guidelines on how to reach each level

You need to follow best practices for implementing automation, using open-source tools such as Sigstore and OPA, just to name a few.