Software Supply Chain Security: Lessons from SolarWinds and Kaseya for Financial Services

Your software is only as secure as the weakest dependency in your supply chain. The SolarWinds attack (December 2020) compromised 18,000 organisations through a single compromised software update. The Kaseya attack (July 2021) compromised 1,500 businesses through a managed service provider’s remote management tool.

Financial services firms are high-value targets for supply chain attacks because they use the same software as every other organisation — but they hold more valuable data. A compromised dependency in a banking application is more valuable to an attacker than the same dependency in a startup’s application.

Who Is This Guide For?

This guide is for CISOs, DevOps leads, and software architects at financial services firms who need to secure their software supply chain. If you want to prevent supply chain attacks from compromising your applications, this is for you.

By the End of This, You’ll Know…

• Why supply chain attacks are the most dangerous threat to financial services
• How to implement Software Bills of Materials (SBOM) for visibility into dependencies
• The verification strategies that detect compromised dependencies before deployment
• How to build a secure software development lifecycle that addresses supply chain risk

Why Supply Chain Attacks Are Different

Traditional attacks target your infrastructure. Supply chain attacks target your software development process:

• SolarWinds: Attackers compromised the SolarWinds build system and injected malware into a legitimate software update. 18,000 organisations installed the compromised update.
• Kaseya: Attackers compromised Kaseya’s VSA remote management tool and used it to deploy ransomware to 1,500 customers.
• Codecov: Attackers modified the Codecov bash uploader script to exfiltrate environment variables (including secrets) from CI/CD pipelines.

Supply chain attacks are difficult to detect because the compromised software comes from a trusted source. The update is signed, the distribution is legitimate, and the code looks normal.

Software Bill of Materials (SBOM)

An SBOM is a list of all software components in your application. It includes:

• Direct dependencies: Libraries you explicitly import
• Transitive dependencies: Libraries your dependencies import
• Versions: Specific versions of each component
• Licenses: Open-source licenses for each component
• Known vulnerabilities: CVEs associated with each component

Why SBOM matters for financial services:

• Incident response: When a new vulnerability is disclosed (like Log4Shell), you need to know which applications use the vulnerable component
• Compliance: Regulators increasingly require SBOM as evidence of software supply chain security
• Audit: SBOM provides a complete inventory of software components for audit purposes

SBOM tools:

• Syft: Generate SBOM from container images and filesystems
• CycloneDX: OWASP standard for SBOM format
• SPDX: Linux Foundation standard for SBOM format

Dependency Verification

Dependency Pinning

Pin dependencies to specific versions and hashes:

1
2
3

# package-lock.json (Node.js) - pins exact versions
# go.sum (Go) - includes cryptographic hashes
# poetry.lock (Python) - pins exact versions with hashes

Hash Verification

Verify dependency integrity using cryptographic hashes:

1
2
3

# Verify a dependency hash
sha256sum dependency.jar
# Compare with published hash from the dependency author

Signature Verification

Verify dependency signatures using PGP or Sigstore:

1
2

# Verify GPG signature
gpg --verify dependency.jar.sig dependency.jar

Private Registry

Use a private registry to control which dependencies are available:

• Artifactory: Self-hosted artifact repository with access control
• Nexus: Self-hosted repository manager
• AWS CodeArtifact: Managed artifact repository

Secure Development Lifecycle

Pre-Commit Hooks

Run security checks before code is committed:

• Secret detection: Detect hardcoded secrets (API keys, passwords)
• Linting: Enforce coding standards that reduce security risks
• Dependency checks: Verify dependency integrity

CI/CD Pipeline Security

Secure the CI/CD pipeline against supply chain attacks:

• Build isolation: Run builds in isolated environments (containers, VMs)
• Reproducible builds: Ensure builds are reproducible from source
• Artifact signing: Sign build artifacts to verify authenticity
• SBOM generation: Generate SBOM for every build

Deployment Verification

Verify deployment integrity:

• Image scanning: Scan container images for vulnerabilities before deployment
• Policy enforcement: Enforce deployment policies (no root, no privileged containers)
• Runtime protection: Monitor running containers for anomalous behaviour

What You Can Actually Use Today

• Syft: SBOM generation tool from Anchore
• Grype: Vulnerability scanner for container images
• SLSA: Supply chain Levels for Software Artifacts framework
• Sigstore: Software signing, verification, and provenance

FAQ

How do we detect compromised dependencies?

Use SBOM to maintain a complete inventory of dependencies. Monitor CVE databases and security advisories for newly disclosed vulnerabilities. Use dependency scanning tools (Snyk, Dependabot, Grype) to detect known vulnerabilities.

What is the difference between SBOM and dependency lock files?

Dependency lock files (package-lock.json, go.sum) pin specific versions and hashes. SBOM provides a complete inventory including transitive dependencies, licenses, and vulnerability information. Both are necessary.

How do we handle zero-day vulnerabilities in dependencies?

Zero-day vulnerabilities have no patches. Mitigate by: (1) isolating affected systems, (2) monitoring for exploitation, (3) applying virtual patches if available, (4) replacing the vulnerable dependency if possible.

We help financial services firms secure their software supply chain against SolarWinds and Kaseya-style attacks. If you need to implement SBOM or dependency verification, get in touch.