CIS Safeguard 16.4: Establish an Inventory of 3rd Party Software Components

CIS Safeguard 16.4: Establish an Inventory of 3rd Party Software Components

By Eric Corcoran
Posted in Security
On November 10, 2026

In Stranger Things, the Upside Down exists right alongside the real world. It is connected to everything, it influences everything, and for years nobody knew it was there. The danger was not some distant external threat. It was underneath Hawkins the entire time, finding its way in through cracks nobody thought to check. Third-party software components you have not inventoried work exactly the same way: hidden dependencies running under the surface of your applications, quietly doing their job until one day they are not. Log4Shell proved this at enterprise scale.

What Is Establish and Manage an Inventory of Third-Party Software Components?

Most software is not built from scratch. It is assembled. Developers pull in open-source libraries, frameworks, and packages to speed up development. That is normal and expected. The problem is that when something goes wrong in one of those components, you need to know it is there before you can do anything about it.

CIS Safeguard 16.4 addresses this directly. The official text reads:

"Establish and manage an updated inventory of third-party components used in-house, including any risks that each component could pose. Evaluate the list at least monthly to identify any changes or updates to these components."

Know what is in your software. Keep that list current. Review it regularly.

Why It Matters

In December 2021, the security community discovered that Log4j, a Java logging library embedded in thousands of applications worldwide, had a critical remote code execution vulnerability. Organizations scrambled to figure out which of their systems were affected. Many could not answer that question quickly because they had no inventory. They did not know which applications used Log4j, which versions, or how deeply it was embedded. Some are still finding instances today.

That is the software supply chain risk in concrete terms. A vulnerability in a component you did not know you were running becomes your breach, your incident response, and your regulatory notification obligation.

Third-party components also introduce licensing risks, end-of-life software exposure, and compliance gaps. An inventory is not just a security control. It is operational hygiene.

Key Details or How It Works

  • Software Bill of Materials (SBOM): An SBOM is a formal, machine-readable inventory of every component in a software application, including direct dependencies and transitive ones (the dependencies of your dependencies). Think of it as a nutrition label for your software.
  • Direct vs. transitive dependencies: You may knowingly use five libraries. Each of those libraries may pull in dozens more. Transitive dependencies are where most surprises live.
  • Version tracking matters: A component is not just a name. The specific version determines whether a known vulnerability applies. Your inventory needs version numbers, not just package names.
  • Monthly review cadence: CIS specifies at least monthly evaluation. Vulnerabilities are disclosed continuously. A quarterly review leaves too long a window of exposure.
  • Risk scoring per component: Not every third-party library carries the same risk. Components that handle authentication, encryption, or network communication warrant closer scrutiny and faster remediation timelines.
  • Tooling automates the hard part: Software Composition Analysis (SCA) tools such as Dependabot, Snyk, and OWASP Dependency-Check can generate and maintain SBOMs automatically as part of a CI/CD pipeline.
  • Scope includes acquired software too: This is not just for in-house development. If you are running commercial off-the-shelf software or SaaS products with embedded components, they fall under this control as well.

How to Implement Establish and Manage an Inventory of Third-Party Software Components

  1. Identify all applications in scope. Start with a list of every application your organization develops, hosts, or relies on. Internal tools count. That internal Python script someone built three years ago counts.
  2. Generate an SBOM for each application. Use SCA tooling to scan your codebases and produce a Software Bill of Materials. SPDX and CycloneDX are the two most common SBOM formats, and both are well-supported across modern development environments.
  3. Store the inventory in a central, queryable location. A spreadsheet will not scale. Integrate SCA output into your vulnerability management system so you can answer "are we running a vulnerable version of this component?" in under a minute.
  4. Integrate SBOM generation into your CI/CD pipeline. Every build should update the inventory automatically. Manual processes drift. Automated ones stay current.
  5. Establish a monthly review process. Set a recurring review to check for newly disclosed vulnerabilities in your inventoried components, flag anything approaching end-of-life, and identify components that changed unexpectedly since the last review.
  6. Define a response workflow for flagged components. Discovering a vulnerable component is step one. You need a defined process for how quickly it gets patched, who owns the remediation, and how exceptions are documented and approved.

Final Thoughts

Eleven eventually mapped the Upside Down. Once people knew what was there, they could fight it. The problem was never that the threat was too powerful. The problem was that nobody knew it existed. Your third-party software components are the same. Vulnerabilities are being discovered and disclosed every day. An inventory does not eliminate that risk. It gives you a fighting chance to respond before the gate opens.

Resources

Here is a link to the Policy Templates provided free of charge from the fine folks at the Center for Internet Security.

Looking for even more detail? Here you go. If this still does not satisfy your curiosity, DM me.

Official CIS Text

CIS Control 16: Application Software Security Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.

CIS Safeguard 16.4: Establish and Manage an Inventory of Third-Party Software Components Establish and manage an updated inventory of third-party components used in-house, including any risks that each component could pose. Evaluate the list at least monthly to identify any changes or updates to these components.

Shameless Marketing Information

Gotham Technology Group helps organizations build and maintain software inventories, implement SCA tooling, and develop application security programs that scale. If your team builds or buys software and you are not sure what is running inside it, let's talk.