Supply Chain Security Assessment For A Tier-1 Technology Vendor

Before assessing risk, we needed to know exactly what went into each product. We analysed source code, build files and container images across every product line to identify every direct and indirect third-party component in use. Every product line was included, including older releases.

The inventory revealed far more than the vendor expected. Its 80 declared dependencies pulled in hundreds of additional libraries behind the scenes, some several layers deep, and several products bundled outdated copies of the same component with different versions, creating inconsistent risk that nobody had been tracking or managing properly.

For the first time, the vendor had a complete, accurate picture of its software supply chain. The inventory became the starting point for every later step, from risk scoring to the software bill of materials shared with its enterprise customers. Engineers now check the inventory before adding any new component, which has already stopped several risky additions.

Enterprise customers wanted a software bill of materials, a detailed list of every component inside each product. We set up automated SBOM generation in industry-standard formats for every release, so the list is always current and accurate. Customers wanted it in a standard, machine-readable format.

Each SBOM records component names, versions, suppliers and licences, and is generated directly from the build process rather than written by hand. This means it always matches exactly what customers receive, and it can be shared securely with customers and regulators whenever they request it during procurement or annual reviews.

When a new vulnerability is announced, the vendor can now search every SBOM and know within minutes which products are affected. Customers value that speed and transparency, and several have highlighted it as a key reason for renewing their contracts. The SBOM process now runs on every release automatically, so it never depends on anyone remembering to update it.

Not every dependency carries the same risk, so we built a scoring model to focus effort where it mattered. Each component was assessed on known vulnerabilities, exploit likelihood, maintenance activity and how critical it was to the product. The model was agreed with engineering leaders in advance.

The model combined industry data such as CVSS and EPSS scores with signals about the health of each open-source project, including how often it was updated and how many people maintained it. Components used in security-sensitive parts of a product, such as authentication or encryption, were weighted more heavily than others.

The scoring highlighted a small group of components responsible for most of the real risk. This allowed the team to fix the most important issues first, instead of trying to address hundreds of low-impact findings with the same urgency and limited time. The model is reviewed every quarter to reflect new threats, and scores update automatically as projects change.

Twelve dependencies contained known critical vulnerabilities, some already being exploited in the wild. We worked with the engineering teams to plan and deliver fixes quickly, without breaking functionality relied on by critical infrastructure customers. Customer stability was the top priority throughout the work.

Where safe upgrades were available, they were tested thoroughly and rolled out. Three components that had not been maintained for over three years were replaced with actively supported alternatives, and where immediate fixes were not possible, temporary protective measures were put in place and clearly documented for customers to review and understand.

All twelve critical vulnerabilities were resolved within the 90-day milestone. Automated monitoring now alerts the team as soon as a new vulnerability affects any component, so issues are dealt with in days rather than lingering for months unnoticed. A clear policy now defines how quickly each severity must be fixed, giving customers confidence in response times.

Recent attacks have shown that compromising a build system can be as damaging as compromising the code itself. We reviewed the vendor's build pipelines to see how an attacker might tamper with products before they reached customers. Every step from commit to release was examined closely.

The review found shared credentials, build servers with broad network access and no way to prove that a shipped product had been built from approved source code. Build steps could also download components straight from the internet at build time, creating an easy route for a malicious package to slip into a release unnoticed.

Pipelines were hardened with isolated build environments, pinned and verified dependencies, and short-lived credentials. Every build now produces a signed record of exactly how it was made, giving customers verifiable proof that products have not been tampered with. The hardened pipeline design is now the standard template for every new product the vendor builds.

Customers needed a simple way to confirm that software really came from the vendor and had not been altered. Before the project, releases were not signed at all, leaving customers to rely on trust alone. Many customers had asked for it in recent security reviews.

We implemented code signing across every product, with signing keys protected in hardware and access limited to the automated release process. Customers can now verify each release with standard tools, and any unsigned or modified package is rejected automatically by their deployment systems before it can be installed anywhere in their environment.

Code signing closed one of the most obvious gaps raised by customers. It also protects the vendor's reputation, since attackers can no longer easily distribute fake or altered versions of its software under its trusted name. Several customers now verify signatures automatically in their own pipelines, strengthening the wider supply chain.

Supply chain risk also comes from the companies behind commercial components. The vendor had no process for checking the security of its own suppliers, even those providing code used in critical infrastructure products. This gap had already been raised by several major customers.

We designed a proportionate supplier assessment process, with short questionnaires for low-risk suppliers and deeper reviews for those providing critical components. Contract clauses were updated to require timely vulnerability disclosure, and a central register now tracks every supplier's risk level, assessment date and any outstanding issues or follow-up actions.

Every new component and supplier now goes through the process before it is used in a product. The approach has already stopped two high-risk libraries from being introduced, and gives customers confidence that risk is being managed beyond the vendor's own code. Supplier risk is now reported to the leadership team every quarter, alongside the vendor's other key risks.

The final deliverable was a practical roadmap to full alignment with NIST SP 800-161. We compared the vendor's current practices against the guidance and identified exactly what still needed to be done. It needed to be realistic, clear and fully costed.

The roadmap sets out clear actions at 90, 180 and 365 days, each with an owner, estimated effort and expected risk reduction. It was written for two audiences at once: detailed enough for engineering teams to act on, and clear enough for customers and executives to understand progress without technical background knowledge.

The roadmap was shared with enterprise customers within the 60-day deadline, unblocking three major deals within 30 days. Progress is now reported to customers every quarter, turning supply chain security into a visible strength rather than a sales obstacle. Several customers have since used the vendor's approach as a model for strengthening their own supply chains.