Safeguard 16.4 Third-party component inventory

What a third-party component inventory must show for Safeguard 16.4

If you must show a current third-party component inventory under CIS Safeguard 16.4, you need a living list of every outside library, framework, package and service component your development teams use or plan to use, with the risks each one could pose. The Safeguard applies to IG2 and IG3 enterprises, not IG1. CIS publishes the Controls and does not issue certifications or attestations; an independent assessor or auditor reaches any conclusion about your implementation, and your organization owns the inventory itself.

The risk this Safeguard addresses is simple to state: an organization cannot protect components it does not know it runs. An unknown dependency may carry a published vulnerability, sit at a version the upstream project no longer supports, or be modified from its original source. The difficulty is that most components arrive transitively, pulled in by other components you chose on purpose, so the developer who added a package may never see the dozens of libraries beneath it. The inventory also decays. A list that was accurate at a sprint review can be wrong a week later after a dependency update, so the monthly evaluation CIS asks for is where changes and unsupported versions get caught.

Before the next assessment, confirm three things: that the inventory covers planned components as well as current ones, that each entry records the risks you have assessed, and that a named owner completes the monthly review with dated evidence. The Safeguard depends on Safeguard 2.1, the software inventory, so check that it exists first; the assessment specification scores a missing inventory of third-party software components as a failure. Ask your assessor which tools and formats they will accept, since the inventory must be reproducible and not a spreadsheet typed from memory.

Which applications, teams and suppliers the Safeguard 16.4 inventory must cover

The inventory is only as complete as its boundary. Each card below names a scope decision that changes which components appear in the bill of materials and who has to supply them. Settle these questions with development leads before the first inventory run, because a boundary set too narrowly leaves gaps that the monthly review cannot see.

In-house applications and their dependencies

Every application the enterprise builds is in scope, including internal tools, scripts that ship with products and small utilities maintained by one team. For each one, the inventory should list direct and transitive third-party libraries, with versions and the risks each could introduce. Confirm with each team which repositories and package manifests define its builds, since transitive dependencies often appear only in lock files.

Hosted and SaaS software built upon

When the enterprise builds on hosted platforms, managed services or SaaS components, the third-party code it relies on still counts, even if the enterprise does not operate the servers. Ask teams which hosted APIs, SDKs, managed runtimes and embedded widgets sit inside their applications. Record the supplier-provided component, its support status and the risk it adds, and link the entry to the provider review under Control 15.

Acquired and vendor-supplied software

Software bought or licensed from vendors often arrives as a compiled package with embedded libraries that the buying team cannot see. Ask vendors for a software bill of materials as a contract requirement, and record what they supply alongside what the enterprise modifies. Where a vendor cannot provide one, the inventory should say so, so the gap is visible at the monthly review rather than discovered during an incident.

Build pipelines and container images

Build tools, base images, compilers, CI runners and plugins execute on every release and can alter what ships, so they belong in the boundary. Container images bring operating system packages and language libraries that differ from the application's own manifest. Confirm with platform engineers which base images and pipeline actions each build pulls, and which pinned versions are in use. Trivy can generate software bills of materials from images and file systems, which helps check that the inventory matches what the pipeline actually builds.

Components planned for upcoming releases

Safeguard 16.4 asks for the inventory to include components slated for future use, not only those already shipping. Ask product owners and architects which libraries, SDKs or services are on the roadmap, under evaluation or pending procurement. Recording them early lets the team assess their risks and support status before the code is merged, and it gives the monthly review a list of changes to check.

Teams that change components outside the main pipeline

Shadow projects, prototypes and contractor-built code often pull libraries directly from public registries without passing through the standard build. These sources are easy to miss and can bring in components with unknown licenses or abandoned maintainers. Ask engineering managers to identify every repository and team that publishes code under the enterprise's name, and bring those sources into the same inventory process.

How an assessor tests the Safeguard 16.4 inventory

This table compares what an assessor checks under the CIS Controls Assessment Specification for Safeguard 16.4, the evidence each check expects, and where organizations usually fall short. Read it as a checklist: each row is a test point, and the common findings show where a readiness review should start.

Test point	Evidence an assessor expects	Common finding
Inventory exists	A current list of third-party software components used in development, with version and source for each entry	No inventory of third-party components exists, which the assessment specification scores as failing
Planned components included	Entries or a documented intake step for components slated for future use in development	Inventory covers only production dependencies and omits components in the pipeline
Risks recorded per component	Each entry notes the risks the component could pose, such as known vulnerabilities, license terms or maintainer status	Entries list names and versions but no risk information
Monthly evaluation	Dated review records or tickets showing the inventory was evaluated at least monthly	Inventory exists but has not been reviewed monthly, with gaps in the review history
Changes and updates identified	Diff or change history between review cycles showing added, removed or upgraded components	Changes are made in code repositories but never reflected in the inventory
Support status confirmed	Record that each component is still supported by its maintainer, with the check date	Components past end of support remain in use and are not flagged in any review
Prerequisite software inventory	Evidence under Safeguard 2.1 that the software inventory is maintained, since it underpins 16.4	Application inventory is incomplete, so third-party components cannot be traced to their systems

Why Safeguard 2.1 must come first for the Safeguard 16.4 check

The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 16.4, so an assessor will look at the general inventory of installed software before looking at the third-party component inventory. Safeguard 2.1 asks the enterprise to establish and maintain a list of the software it runs. Safeguard 16.4 then asks which third-party components sit inside the software the organization builds, buys or hosts. The second list only means something if the first one is complete, so the assessor will test the order of the work as well as the content. The practical consequence is that a team that cannot list its own installed software will struggle to show which third-party components it depends on. In a typical application estate, a service may pull in libraries, container base images, runtime packages and operating system packages, and some of those will not appear in a developer's head or in a project manifest. Before preparing evidence, the team should confirm that its software inventory covers production, staging and build environments, names the owner of each application, and records version information. Open-source tools such as Trivy can help build a first pass of package and dependency data, but the organization still has to decide which assets are in scope and keep the list current.

The assessor also checks whether the monthly evaluation of the Safeguard 16.4 inventory actually happened. Safeguard 16.4 expects the inventory to be reviewed at least monthly to identify changes or updates and to confirm each component is still supported. A list created once and never revisited will not satisfy that expectation, so the team needs dated records: the review date, who performed it, which components changed, and what was decided about unsupported or risky components. Meeting notes, ticket histories or dashboard snapshots taken on a schedule are usually stronger evidence than a spreadsheet with a single modified date. Before preparing, the enterprise should read the current wording of the Controls16 section of the Assessment Specification directly at the CIS documentation site, and compare it with the Safeguard 2.1 entry in the same specification. The specification is versioned, and the exact inputs, measures and metrics an assessor uses should be confirmed there rather than taken from this page. Ask the assessor, if one is engaged, which versions of the specification and the Navigator they will apply.

How to build and keep a third-party component inventory in six steps

This sequence takes an enterprise from agreed scope to a component inventory that covers what is in use and planned, carries risk and support status, and is reviewed monthly on a dated record that an assessor can test.

Confirm scope with development leads
Start by agreeing with development leads which applications, repositories, build pipelines and container images the inventory covers, including in-house, hosted and acquired software. Name the business owner for each application and record which teams build, ship and run it. Record which applications sit outside the inventory and why. The output is a signed scope register listing each application, its owner and its build sources, which gives the assessor a fixed population to test against.
Establish or confirm the Safeguard 2.1 software inventory
Safeguard 16.4 depends on Safeguard 2.1, the software asset inventory, which the CIS Controls Assessment Specification names as a prerequisite for measuring 16.4. Check that the software inventory exists, is maintained and covers the in-scope applications. Where it does not, fix that first, because a component list cannot be reconciled against an inventory that does not exist. The output is a current software inventory extract for the scope register, with the date it was last reviewed.
Generate component lists from build manifests and images
Produce machine-generated component lists from the sources that define what ships: package manifests and lock files, build outputs, and container images. Open-source tools such as Trivy can identify OS packages and software dependencies in a target and produce them as a software bill of materials, and it can also scan existing SBOMs. Run generation as part of the build pipeline so every release produces a list. The output is a stored SBOM per application version, in a format the team can parse and retain.
Record version, source and support status for each component
Consolidate the generated lists into one inventory per application. For each component, record its name, version, source or supplier, license and whether the upstream project still supports that version. Flag components that are unsupported, unmaintained, modified in-house or pulled from unknown sources. Load the data into a tracker such as OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs and VEX and identifies outdated or modified components and license risk using SPDX license IDs. The output is a consolidated inventory with a support status on every row.
Add risks and planned future components
Safeguard 16.4 asks for the inventory to include components slated for future use and the risks each component could pose. For each component, record the known vulnerabilities, the license obligations and the business or security risk of relying on it. Then add the components the team plans to adopt, with the reason and the owner who approved them. Ask developers to log planned libraries before they are added to the build. The output is a risk column per component and a planned-components list that an assessor can compare against the next monthly review.
Set the monthly review with a named owner and dated record
CIS asks for the inventory to be evaluated at least monthly to identify changes or updates and confirm each component is still supported. Assign a named owner who runs the review, a backup, and a standing agenda covering new components, version changes, unsupported components and new risk. Each review produces a dated record listing what changed, what was approved, and what was escalated or accepted. Confirm with your assessor how they will sample those records, since the monthly cadence is what they will test. The output is a dated review log for each month, with the owner's sign-off, kept alongside the inventory.

Evidence that passes a Safeguard 16.4 review and how to keep it current

An assessor testing Safeguard 16.4 looks for a current inventory, risk notes that cover planned components, and a dated trail showing the inventory is reviewed monthly. The cards below cover the artifacts that prove this, how to keep each one current between audits, and what an assessor will ask to see with dates.

Current component inventory export

The inventory export lists every third-party component used or planned in development, with its version, source repository or registry, and the product or application it belongs to. Regenerate it from your build pipeline or a bill of materials tool rather than editing it by hand, so the export matches what is actually shipped. Between audits, schedule the export and store each dated copy. An assessor will ask for the export date, the scope of applications it covers, and how you confirmed no component was missed, such as a comparison against build manifests for one sample application.

Risk notes for each component

Each component entry needs a short risk note covering known vulnerabilities, license terms, maintainer activity and how the component is used. Include planned components before they reach the codebase, because Safeguard 16.4 expects the inventory to show components slated for future use. Record the owner who accepted each risk and the review date. An assessor will ask to see the notes for a sample of components, particularly any with open high-severity findings, and the dated decision that allowed each one to continue.

Dated monthly evaluation records

Safeguard 16.4 asks that the inventory be evaluated at least monthly to find changes or updates. Keep a dated record for each evaluation that lists the components added, removed or upgraded since the last run, and the actions taken. A record showing no changes still counts when it is dated and signed off. Missed months are the most common gap, so set a recurring calendar entry with a named owner. An assessor will ask for the last several monthly records and will compare them against version changes in your repositories.

Support status checks

Confirm for each component that its version is still supported by its maintainer or vendor, and record the end-of-support date where one is published. Unsupported components should appear in the risk notes with a remediation plan or an accepted-risk decision. Check support status at each monthly evaluation, not only when a vulnerability is reported. An assessor will ask which components are unsupported, what was decided for each, and when the decision was last reviewed.

Link to the Safeguard 2.1 software inventory

Safeguard 16.4 depends on Safeguard 2.1, the software inventory, which the assessment specification lists as a prerequisite. Map each third-party component in the 16.4 inventory to the software asset record that runs it, using a shared identifier such as the application name or asset ID. Gaps appear when a component is in production but absent from the software inventory, or when a 2.1 asset has no component list. An assessor will ask to trace a sample production application from its software record to its component list, with dates showing both were current.

What meeting Safeguard 16.4 costs in tooling, engineering time and review

This table lists each cost component of keeping a third-party component inventory under Safeguard 16.4, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to know which quote lines to ask for. No prices or durations are given here because none are supplied, so request every figure in writing.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Tooling or licenses	Tool vendor or open-source project maintainers; internal platform team for hosting	Recurring if commercial; hosting is recurring either way	Number of pipelines and applications scanned, and whether SBOM analysis is hosted in-house. Confirm license terms with each vendor.
SBOM generation in pipelines	Engineering or platform team, and implementation partner if engaged	One-time setup, then recurring maintenance	Number of pipelines, build systems and languages. Each new pipeline adds integration work.
Dependency analysis and triage	Application security or development leads reviewing findings	Recurring	Release frequency, number of components per application and how many findings each release produces.
Monthly review of the inventory	Named owner and development leads, typically a standing meeting	Recurring, monthly	Number of applications and suppliers, and whether components are reviewed for support status and changes.
Supplier and planned-component records	Procurement, architecture and development teams	Recurring as suppliers change	Number of third-party suppliers and how many are involved in each product line.
Evidence upkeep	Compliance lead and system owners who keep inventories, review records and change history current	Recurring	Audit frequency and how automatically exports and review logs are kept.
External testing or review	Independent assessor or testing firm, if commissioned	Usually one-time per engagement, sometimes recurring	Scope of applications, and whether reviews cover the inventory process or only sampled components.
Auditor sampling time	Independent auditor, paid under the audit engagement	Recurring per audit cycle	Number of sampled applications and releases, and how quickly the inventory can produce evidence for each sample.

Who owns the inventory, who prepares it and who issues the assessment

Your development and security teams own Safeguard 16.4. The enterprise is responsible for knowing which third-party components its software uses or plans to use, and for deciding what to do when a component becomes risky. Those decisions cannot be handed to a vendor or consultant, because they depend on your products, data and risk appetite.

Ownership of the inventory: Name an accountable owner for the component inventory and for the monthly evaluation that the Safeguard asks for.
Planned components: Record components that teams intend to adopt, not only those already shipped, so the inventory covers future use as the Safeguard describes.
Monthly review decisions: Decide which changes, updates and unsupported components require action, and set timelines for each.
Risk acceptance: Document who approves keeping a component with a known issue, the compensating controls and the review date.
Build pipeline changes: Integrate SBOM generation into the normal build process so new dependencies are captured without manual steps.

Before the assessment, confirm that the owner, the review cadence and the risk acceptance records are written down and that someone can show the last few monthly reviews.

Which open-source tools can produce or check the Safeguard 16.4 evidence

Two self-hosted open-source projects map well onto the evidence Safeguard 16.4 asks for: OWASP Dependency-Track for keeping and reviewing the inventory, and Trivy for producing component data from build pipelines. Both are licensed under Apache-2.0, as listed in the supplied project information. Before adopting either, confirm the current capabilities, supported formats and version numbers against each project's own documentation, since features change between releases.

Dependency-Track consumes and produces CycloneDX software bills of materials (SBOMs) and VEX documents. It flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX license ID. That makes it a natural home for the monthly review record: each review should show which components changed, which are still supported, and which carry new risk. Trivy identifies OS packages and software dependencies in a target and can either generate an SBOM or scan an SBOM you already have, so it fits the pipeline stage where components are first recorded. Confirm which package ecosystems and output formats your build tooling needs before relying on it, and check that the SBOMs it emits are accepted by Dependency-Track in your version.

Neither tool satisfies Safeguard 16.4 on its own. The inventory must also cover components planned for future use, the risk each one could pose, and the monthly evaluation, and the enterprise owns each of those decisions and the assignment of who performs them. Tools generate data; people decide what a changed or unsupported component means for a release. Ask your implementation partner to document that ownership, and expect an independent assessor to test the process, the records and the review dates rather than the tool output alone.

Questions buyers ask about the Safeguard 16.4 inventory

Does an IG1 organization have to maintain a third-party component inventory?

No. Safeguard 16.4 is assigned to Implementation Group 2, so it applies to IG2 and IG3 enterprises. IG1 organizations still need essential hygiene over the software they run, including the software inventory in Safeguard 2.1, but the third-party component inventory is an IG2 expectation. Being in IG1 does not settle the question if a customer contract, a regulator or another framework you have adopted asks for a component inventory, so check those requirements before deciding. Confirm your Implementation Group against the CIS Implementation Groups pages and record the reasoning. The CIS Controls Navigator shows which framework requirements map to this Safeguard, which helps when an outside obligation is the real driver.

How long does the first component inventory take, and what drives the time?

The duration depends on the size and state of your development estate, and no fixed timeline is set by CIS. The main drivers are the number of repositories and languages in use, whether manifests and lock files are kept current, whether teams copy or vendor components into code, and how much hosted or acquired software you must include. Build metadata that already exists in pipelines shortens the work considerably. Where Safeguard 2.1 software inventory is not yet in place, expect extra effort, because the Assessment Specification lists it as a prerequisite. Ask any partner for a timeline based on the written scope and a sample of repositories. Ask which costs are one-time, such as collection and tooling setup, and which recur, such as the monthly review.

Can our engineering team build the inventory without outside help?

Yes, if the team has the skills and time. The CIS Controls are free for any organization to use for its own cybersecurity, and nothing in the Safeguard requires an outside party. Most of the work is collection and tracking: generating software bills of materials in a standard format, then loading them into a system that flags vulnerabilities, outdated components and license risk. OWASP Dependency-Track documentation describes a tool that consumes and produces CycloneDX SBOMs and tracks license use by SPDX identifiers. Outside help is usually sought for pipeline integration, deploying the tooling in your own infrastructure, designing the evidence, or a readiness review before an assessment. A partner prepares systems and evidence, while only an independent auditor issues reports.

What do developers and the security team each need to contribute?

Developers own the component list for their repositories. They keep manifests and lock files current and record components planned for future use, because the Safeguard covers planned components as well as those in use. The security team owns the process: defining what each record holds, such as name, version, source, license, support status and known risks, setting who reviews changes, deciding how risks are accepted or fixed, and sampling records at each review. Product owners and procurement must tell security about acquired or hosted software that engineering does not build. Engineering leadership should make a complete component record part of the definition of done for new services. Ask any quote for a responsibility matrix that names an owner for each task.

What must the monthly review show, and what record proves it?

The Safeguard asks that the inventory be evaluated at least monthly to identify changes or updates and to confirm each component is still supported. The proof is a dated record of each review. It should contain the inventory snapshot, the components added, removed or changed since the last review, the support status checked, the risks raised, and the decisions taken with named owners. Keep the tracker export, the meeting notes or ticket history that show the decisions. Assessors look for a steady cadence across months, not one document produced before an audit. Automated diffs help, but a named person should sign off each review. Confirm with your assessor how they expect the records to be retained.

How does the Safeguard 16.4 inventory relate to Safeguard 16.5?

Safeguard 16.5 asks for current, trusted third-party components from trusted sources, or for evaluating them for vulnerabilities before use. Safeguard 16.4 is the record of what you use or plan to use and the risks each component carries. The two work together: the inventory shows which components were selected and whether they have stayed supported, while the selection behavior in 16.5 determines what enters the inventory. Without the inventory, you cannot show which components were evaluated or whether they remain current. Build the inventory first so the monthly review can flag unsupported components and feed selection decisions. Ask a partner how its scope covers both Safeguards and whether the selection criteria will be written down.

How DeployOpen scopes and prepares a Safeguard 16.4 inventory

DeployOpen approaches Safeguard 16.4 as an engineering and evidence task inside your own environment: we scope which applications and build pipelines the inventory covers, deploy self-hosted tooling that produces the component records, and document the monthly review. Engagements are fixed-scope, and the organization keeps ownership of the controls and the review decisions.

How we scope

We list the applications, repositories and build pipelines that the written scope covers for the Safeguard 16.4 inventory.
We confirm which third-party components are in use and which are planned, so the inventory includes future-use components.
We agree in writing who owns the monthly review, the risk criteria for each component, and the evidence the assessor will receive.

How we build

We deploy self-hosted tooling in your infrastructure that generates CycloneDX software bills of materials from each build.
We configure component risk views for known vulnerabilities, outdated or modified components and license risk using SPDX license IDs.
We link the inventory to the Safeguard 2.1 software inventory so the prerequisite can be traced and tested.

How we hand over

We document the inventory process, the monthly evaluation procedure and the roles that perform it in your own policy language.
We deliver a walkthrough of how to pull a component list, record a review decision and show support status for a given release.
We provide a sample evidence pack, such as exported inventories and review records, for your team and any independent assessor to examine.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can keep the tooling current, adjust the inventory as new pipelines appear, and prepare the monthly review records.
Any certification or attestation decision remains with the independent auditor or certification body, not with DeployOpen.