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.

Definition of Software Supply Chain Security

The software supply chain refers to everything involved in the development of an application throughout the entire software development life cycle (SDLC). Creating and deploying software requires securing the activities, processes, and components of its supply chain. There are many factors to consider in this regard, including custom code (in-house components), open source dependencies and libraries (third-party components), DevOps tools and infrastructure that make up the CI/CD process, and finally developers and DevOps teams.

It is the responsibility of organizations to perform these security activities and to provide proof of their security efforts to consumers.

 

 

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).

Read More

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.

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.

Learn More

Software supply chain security explained

What’s hiding in your code?

How to Improve the trust in the software supply chain?

What are the implications of SSDF (NIST 800-218) final version?

What’s with Continuous Assurance and software supply chain security?

Why is Continuous Assurance an Integral practice for software supply chain security?

How to implement automated SLSA-compliance evaluation?

How can SBOM enhance software supply chain security?

How to secure your software with SBOMs?

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.

Read more

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.

Contact Us

Stay in the Know

Continuous Assurance & Software Supply Chain Security | Scribe Security Cyber Risk
Continuous Assurance: An Integral Practice for Software Supply Chain Security
Read more
SSDF FINAL VERSION Cyber Risk
SSDF (NIST 800-218) final version – differences from the draft and their implications for you
Read more
IconBurst Article Image Cyber Risk
IconBust, a new NPM attack
Read more

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.

While it is difficult to prevent software supply chain attacks, the following are some of the things you can do to mitigate their impact or reduce their risks: Audit your infrastructure, keep an updated inventory of all your software assets, assess vendors and apply a zero-trust approach, use security tools, secure your endpoints, etc.

While there are no guarantees in life, let alone in security, there are software supply chain security best practices in place, which developers and product organizations need to follow to secure their software supply chain. Within the different stages of your software lifecycle, you can use these guidelines to describe, assess, and measure security practices within your organization. The best practices come into play at each phase of the software supply chain, including acquisition, development, and deployment.

A rise in the number of software supply chain risks and a series of high-profile breaches resulting from them shows how serious the vulnerability problem is. There are several threats to the software supply chain that can be posed by third-party software. It is possible for attackers to exploit vulnerabilities in systems that depend on third-party software in a variety of ways. Among these methods of attack are introducing malicious code into software, causing dependency confusion, and typosquatting.

Supply chain attacks usually hide behind legitimate processes to gain unrestricted access to an organization's software ecosystem. In most cases, attackers start by breaching the security defenses of a vendor or software supplier. Once the supply chain malware has been injected, it must attach itself to a legitimate digitally signed process. Software updates are often used by attackers to spread malware across the software supply chain. Some of the common types of software supply chain attacks include: Compromised software building tools, Stolen code-sign certificates or signed malicious apps using a stolen identity, and compromised code in hardware or firmware components.

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. 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. 

The final version of NIST SSDF 1.1 (Secure Software Development Framework) was issued 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.

Building trust in your software is an important task, especially given the new standards and best practices, such as SSDF and SLSA. Soon vendors who can’t prove this trust will not be able to sell to the US federal government.

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

Scribe platform, a truly end-to-end software supply chain security solution, provides you with this capability. It applies continuous code assurance throughout the SDLC in a zero-trust approach and automatically generates shareable SBOMS so you can gain insights around vulnerabilities and code tampering.

Dynamic pipelines must be continuously monitored for security. In SLSA Cybersecurity Framework (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.