Modern software isn’t “written”, it’s assembled. Your application code is only one piece. The rest comes from open-source applications, languages, and packages. Build tools, CI/CD systems, artifact repositories, and deployment platforms. This entire pipeline is your software supply chain. This software supply chain best practises guide starts with a beginner-friendly definition, then gets practical: how supply chains work, where they break, real-world attack examples, and the controls that reduce risk without turning developers into full-time patch managers.
What Is a Software Supply Chain?
Simply stated: It’s everything that happens including (people, processes, tools, and components) from the moment a developer writes a line of code to the moment it’s run in production, including all the third-party code relied upon along the way.
Why It Matters:
- Security: All third-party code is a potential attack vector
- Reliability: Drift, dependency conflicts, and build breakages slow teams down.
- Compliance: Global standards (like NIST and SLSA) now require provenance, SBOMs, and repeatable builds.
The Components of a Software Supply Chain
- Source Code & Version Control: Application code, version control systems (e.g., Git) and the workflows that govern how code is pushed and pulled into and between repositories.
- Dependencies (Direct + Transitive): Dependencies are third-party libraries your software uses. Transitive dependencies are what your dependencies rely on. These transitive dependencies areoften the part teams don’t realize they shipped until something breaks.
- Build Tools & Environments: Compilers, interpreters, package managers (pip, npm, Maven), build scripts, plugins, and the temporary images or containers where builds occur.
- CI/CD Pipelines: The tooling and software that automates source integration, building, testing, signing, and deployment
- Artifact Repositories & Registries: Storage for binaries, packages, and container images, including mirrors of public open-source registries.
- Deployment & Runtime Platforms: Kubernetes, VMs, and cloud services, including the observability tools that watch for drift and vulnerabilities.
How a Software Supply Chain Works (Step-by-Step)
- Develop: Engineers write code and update dependency manifests or lockfiles.
- Resolve: Package managers retrieve dependencies from registries.
- Build: CI systems compile and assemble the application using a defined toolchain.
- Test: Pipelines run unit, integration, and security checks (SAST/DAST).
- Package: Outputs are bundled into artifacts (packages, binaries, or images).
- Store & Distribute: Artifacts are signed and published to secure registries.
- Deploy: Operations pulls verified artifacts into staging or production.
- Monitor & Patch: Teams respond to new CVEs, integrity issues, and environment drift
Common Risks & Weak Points
- Compromised dependencies/registries: Typosquatting, maintainer takeover, and malicious updates are common patterns. The recent npm Shai-Hulud attacks act as a very real example of an upstream compromise affecting downstream consumers.
- Build tampering (CI/CD compromise): CI/CD often holds secrets and the ability to publish artifacts. The Codecov Bash Uploader compromise shows how build tooling can expose sensitive data from CI environments.
- Non-reproducible builds and drift: If builds aren’t repeatable, proving what shipped (and recreating it under pressure) becomes slower and riskier.
- Vulnerability overload with unclear fix paths: Detection is only step one. The scalable win is reliable, safe remediation across dependency trees—without breaking production.
Real-World Supply Chain Attacks (What They Teach Us)
Understanding these incidents helps shift the mindset from “securing the code” to “securing the process.”
SolarWinds:
The Attack: Attackers (UNC2452) gained access to the SolarWinds build system as early as September 2019. They ran a “test” injection in October 2019 and finally deployed the Sunburst malware into the Orion Platform’s build process in early 2020.
The Nuance: This was a Build-Time Injection. The source code in the repository looked clean, but the artifact delivered to 18,000 customers was malicious. Because the final DLL was signed with a valid SolarWinds certificate, it was trusted by customer networks.
The Lesson: Even “official updates” from trusted vendors can be compromised. You must verify the integrity of the build environment itself, not just the code.
Codecov:
The Attack: In early 2021, attackers modified the Codecov Bash Uploader script—a tool used by thousands of developers in their CI/CD pipelines. The modified script exfiltrated environment variables (including secrets and keys) from users’ build environments.
The Nuance: This was a Tooling Compromise. Most users didn’t “install” Codecov; they fetched a script via curl during their build. This allowed attackers to “reach into” thousands of private build environments.
The Lesson: Any third-party tool that runs in your pipeline has the same permissions as your developers. Treat CI/CD tools as high-risk dependencies.
Log4Shell:
The Attack: In late 2021, a critical vulnerability (CVE-2021-44228) was found in Log4j, a ubiquitous Java logging library.
The Nuance: This demonstrated the Transitive Dependency nightmare. Most organizations didn’t know they were vulnerable because they didn’t use Log4j directly; it was pulled in by other libraries (like Apache Struts or ElasticSearch).
The Lesson: You are responsible for your dependencies’ dependencies. An SBOM (Software Bill of Materials) is the only way to map these hidden risks quickly.
Best Practices for Software Supply Chain Security
- Control Your Inputs: Use curated catalogs (a private and vetted repository of open source components) or mirrors instead of pulling “whatever is latest” from the public internet.
- Lock and Pin Versions: Use lockfiles and pinned toolchains to ensure every environment builds the exact same thing.
- Produce SBOMs (Software Bill of Materials): Generate a machine-readable inventory (SPDX or CycloneDX) for every release and store it with the artifact.
- Sign and Verify: Use tools like Sigstore to sign artifacts at the build stage and enforce verification gates before deployment.
- Aim for Reproducible Builds: Ensure that given the same source, your build produces a bit-for-bit identical result. This proves the build environment hasn’t been tampered with.
- Harden CI/CD: Apply the principle of least privilege. Use short-lived credentials and separate the “Build” role from the “Publish” role.
- Automate Remediation: Detection is only the first step. Use tools that provide safe, automated upgrade paths for vulnerable dependencies.
Getting Started: Questions for Your Team
Q: Where do our dependencies come from today? (Public registries? Mirrors? Mixed? Who can approve exceptions?)
Q: Can we answer “what’s in production” in minutes,not days? (SBOM availability, artifact traceability, inventory)
Q: Can we rebuild the same artifact consistently? (Reproducibility, toolchain standardization, build environment control)
Q: What can publish artifacts and how is that controlled? (CI/CD permissions, signing, separation of duties)
Q: How fast can we safely remediate a critical CVE across multiple apps? (Upgrade-path analysis, rollout workflow, testing gates)
Q: What do developers do when they need a package that isn’t approved? (If it’s “download it anyway,” you might have a problem)
How ActiveState Helps Secure Your Software Supply Chain
Supply chain security breaks when teams feel forced to choose between speed and control. ActiveState focuses on making secure open source consumption a paved road. ActiveState delivers:
- Curated, trusted open source: A catalog of over 40 million rebuilt-from-source packages to help teams consume dependencies from a controlled source.
- Standardized artifacts: Secure containers and runtimes to reduce drift and align dev/CI/prod.
- Operational focus: Consistent remediation based on industry-leading SLA, eliminating the need to have developers remediate third-party code.
Ready to tame open source security—without slowing delivery?
.png)
.png)
.png)