Jit- announcement icon

Announcing our bidirectional integration with Wiz to level-up contextual prioritization!

Learn more

In this article

How to Manage and Reduce Software Supply Chain Risk

Charlie Klein - Director of Product Marketing at Jit
By Charlie Klein

Published November 10, 2024.

a lock and pad with the words how to manage and reduce software supply chain risk

What makes software supply chain risk so insidious is its near-invisibility that stems from limited direct oversight. Each third-party integration and each nested dependency passes through multiple layers without undergoing the same scrutiny as in-house code. When a component reaches production, potential vulnerabilities may have already slipped through undetected. And since these risks don’t manifest immediately, they’re often ignored—until it’s too late.   

Breaches exploiting supply-chain vulnerabilities surged 180% in 2023, with 15% tied directly to third-party suppliers. As your reliance on open-source libraries and third-party services grows, so does the potential attack surface. Ultimately, your supply chain is only as secure as your weakest dependency, tool, service, and pipeline. It’s time to manage and reduce these risks with a proactive, layered approach that continuously monitors, verifies, and secures each link in the chain. 

What Is Software Supply Chain Risk?

Software supply chain risk refers to vulnerabilities within the development ecosystem, ranging from dependencies on third-party packages, such as open-source libraries, to development tools like CI/CD pipelines, build servers, and cloud-based services like GitHub Actions or AWS Lambda. These risks arise when organizations depend on external software, often without complete visibility into their security practices or potential vulnerabilities.  

Unpatched open-source libraries, insecure third-party APIs, and cloud misconfigurations are the most common sources of vulnerabilities. Attackers exploit these weaknesses to inject malicious code or gain unauthorized access to sensitive systems. 

a diagram of the different types of supply chains


For example, the 2022 breach of the PHP package repository Packagist allowed attackers to compromise open-source packages, creating a backdoor into systems that used those libraries. This attack demonstrates how deeply supply chain vulnerabilities can be embedded in widely trusted software.

The Rising Challenges in Managing Software Supply Chain Risk

Modern software development ecosystems rely on an intricate web of third-party libraries, vendors, and platforms, each introducing layers of interdependencies that are hard to monitor and secure. A single vulnerable component in this chain can expose an entire system to attack. The sheer volume of components, often spanning hundreds or thousands, complicates efforts to track what elements are being used and where potential vulnerabilities might exist.

a diagram of a building with different types of buildings


Many organizations also lack visibility of the third-party libraries, APIs, or cloud services integrated into their systems. These blind spots create security risks, as unmonitored dependencies can harbor vulnerabilities. Without full transparency, teams struggle to identify which elements are safe and which pose threats, limiting their ability to respond proactively.

Even when vulnerabilities are detected, it often takes 60 to 150 days before fully addressing them, exposing systems for far too long. Manual processes, communication bottlenecks, and a lack of automation hinder rapid remediation. 

Delays in patching or updating vulnerable components give attackers ample time to exploit known weaknesses. Organizations must manage software supply chain risks effectively through streamlined processes and faster coordination between development and security teams.

a diagram of the vulnerability remediaation process


Best Practices to Manage and Reduce Software Supply Chain Risk

1. Perform Vendor and Third-Party Software Evaluation

Managing software supply chain risks starts with carefully evaluating your vendor-related risks. Begin by requiring vendors to provide evidence of their security posture, such as recent penetration test reports, security certifications (for example, ISO 27001 and SOC 2 compliance), and proof of regular vulnerability scanning. 

Request Software Bill of Materials (SBOMs) from vendors to understand the open-source and third-party components they use, allowing you to assess potential risks. Establish contract terms that require vendors to notify you of any security incidents or newly discovered vulnerabilities, along with their response plans. Lastly, ensure you set clear expectations for security patching timelines.

a table that has a bunch of different things on it


2. Implement Dependency Pinning

One of the most effective ways to control software supply chain risk is by implementing dependency pinning. Pin dependencies to specific, known-good versions in your package manager. For example, in a Python requirements.txt file, list dependencies with specific version numbers:

requests==2.25.1
flask==1.1.2

Alternatively, use

pip freeze > requirements.txt
to pin all installed versions automatically.

This practice helps you manage version control by locking down the exact versions used in production. Pinning dependencies doesn't mean you should leave them untouched. Set up automated dependency audits that evaluate and update versions based on known vulnerabilities and patches. 

3. Automate Security Testing Across the Pipeline

Focus on scanning the entire CI/CD environment – not just the application code. This includes checking for misconfigurations, insecure access controls, and vulnerabilities with the tools, scripts, and dependencies that support your pipeline. Integrate security testing tools directly into your CI/CD pipeline to automate code analysis at every stage of development. Critical tools for this purpose include: 

  • Legitify: Scans GitHub settings to spot misconfigurations – like overly permissive access, missing repository restrictions, or exposed secrets – that could leak sensitive data or allow unauthorized access.
  • Chain-Bench: Analyzes your pipeline for weak spots in dependency configurations, build scripts, and deployment settings. It flags risks like outdated dependencies, unsafe build commands, and insecure deployment paths. 

Both of these tools are available through Jit’s Application Security Posture Management (ASPM) platform, which automates pipeline security by targeting GitHub-specific risks. Jit also offers MFA and Branch Protection Checkers, which verify that multi-factor authentication is enforced on critical accounts and that branch protection rules are correctly applied to protect essential code paths. This approach shifts security left by catching issues in your code and the pipeline that supports and deploys it. 

a purple background with a bunch of different logos


4. Source Composition Analysis (SCA)

SCA tools like npm-audit and OSV Scanner build a complete dependency graph of your software to identify vulnerabilities, outdated versions, and license risks. They analyze metadata and cross-reference it with known vulnerability databases (like NVD) to detect vulnerabilities, misconfigurations, and obsolete versions while tracking legal compliance by checking open-source licenses.

To set up SCA effectively, integrate it directly into your CI/CD pipeline so scans run automatically on every code commit or build. Ensure you’re scanning the entire dependency graph, not just direct dependencies, and configure it to alert you immediately on critical vulnerabilities. Transitive dependencies introduced indirectly through other libraries are dangerous because they can bring unmonitored risks.

a diagram of a large number of lines


5.  Protect Against Exposed Secrets in Code Repositories

Exposing secrets like API keys, database credentials, or tokens in your code is a high-stakes risk – especially in CI/CD environments, where a breach can open up access across systems. For example, when attackers could access Sisense’s GitLab repositories, they found hard-coded secrets and used them to enter AWS S3 buckets with sensitive customer data. This incident is a clear reminder of how exposed secrets can be a direct path for exploitation. To secure your secrets:

  • Catch secrets locally before they are even pushed by scanning your codebase continuously. Use pre-commit hooks to flag secrets in commit history right at the developers' end, stopping them from reaching your main branch. 
  • Manage and store your secrets securely with tools like AWS Secrets Manager. Rotate any exposed secrets immediately and rescan the affected code. 
  • Enforce security policies that halt builds or deployments if a secret is detected. High-risk findings should block the process, while lower-risk alerts could be set for a quick review. 

6. Adopt Secure Build Environments

Isolating your build environment minimizes the risk of tampering during the build process. Use containerized builds and dedicate specific virtual machines or containers solely for building and testing software. These environments should be highly restricted with minimal network access and employ strict access control mechanisms (such as Role-Based Access Control and Multi-Factor Authentication) to prevent authorized access. 

a diagram showing the different stages of deploy


7. Leverage Cryptographic Signing of Components

Signing artifacts, like containers, binaries, and configuration files, offers a verifiable way to confirm that they haven’t been tampered with. Without signing, attackers can modify artifacts to inject malicious code or backdoors to gain unauthorized access, exfiltrate data, or alter application behavior. 

You can manage cryptographic signing internally by setting up your Public Key Infrastructure (PKI). Your PKIs let you generate private keys for signing your software artifacts. When you create a build, sign it using secure cryptographic algorithms like RSA or ECDSA with your private key. 

Integrate signing and verification steps into your CI/CD pipeline to automate this process. Require the signature of each artifact to be verified against the public key during each deployment. For added resilience, consider setting up automated alerts for any failed verifications so your team can respond immediately to any tampering attempts. 

a diagram of a public key infrastructure


Your software relies on a complex network of dependencies to stay operational, but that same network can be its biggest weakness. All it takes is one vulnerable library or an overlooked misconfiguration to compromise the entire system. You need those dependencies to build, but without the proper protections, they can just as easily tear your software down.

Best practices are a good start, but managing a complex supply chain can involve a lot of coordination. Jit’s ASPM platform offers an integrated solution that simplifies and automates vulnerability management across your entire development lifecycle. With built-in integrations like Semgrep and Gosec, Jit makes securing your software supply chain a smooth, automated process – keeping it resilient and ready. Visit Jit to learn more.