Safeguard 16.5 Up-to-date trusted third-party components

What CIS Safeguard 16.5 requires for third-party components

Safeguard 16.5 asks you to use up-to-date, trusted third-party software components, preferring established and proven frameworks and libraries, and to either acquire them from trusted sources or evaluate them for vulnerabilities before they enter your products. If an auditor or a customer questionnaire asks how you handle open-source libraries, the answer they are looking for is a documented selection rule that you apply consistently, plus records showing the rule was followed. Safeguard 16.5 is the selection counterpart to Safeguard 16.4, the inventory of third-party components. The inventory tells you what you use; 16.5 decides whether each component deserves a place in your software in the first place and whether it stays current. Under the CIS Controls Assessment Specification, 16.4 is a prerequisite for measuring 16.5, so an organization without a working component inventory will struggle to show compliance with the selection safeguard.

The risk is straightforward. Stale components carry known vulnerabilities that attackers scan for, and unvetted components can bring in malicious code, abandoned maintenance or licenses your legal team has not approved. The difficulty is scale. Most of what ships is transitive dependencies, libraries pulled in by other libraries that developers never chose and rarely see. A single direct dependency can bring dozens of indirect ones. Projects also go unmaintained without announcement, and the same library may be pinned at different versions across many build pipelines, container images and teams. An inventory built from manifests alone often misses what actually ends up in a build.

Start by confirming which Safeguard 16.5 measure your assessor will use: the Compliance metric, which is the share of up-to-date and trusted software components. Then decide, in writing, what counts as trusted (source registries, maintenance activity, licensing, and a vulnerability check before first use) and what counts as current (for example, how far behind the latest patched release a component may fall before someone must act). Tooling can produce the evidence. OWASP Dependency-Track ingests CycloneDX SBOMs and reports known vulnerabilities, outdated or modified components and license risk, while Trivy can generate SBOMs from build artifacts and scan them. Confirm with each tool's documentation which ecosystems and artifact types your pipelines actually produce before relying on it for the metric.

Which software and teams fall under 16.5

Safeguard 16.5 applies to IG2 and IG3 enterprises, not IG1, and it reaches well beyond the application code a team writes. The cards below set out which software, build assets and decision-makers fall within it, and what the organization should confirm before it claims the Safeguard.

Implementation Group scope

Safeguard 16.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. Confirm your group before scoping the work. An IG1 organization that builds software may still choose to adopt the practice, but it is not measured against this Safeguard. Record the group decision and the reasoning in the scope document so an assessor can trace it.

In-house applications

Code your teams write is the most visible scope item, and each application's dependency manifest is where third-party components enter. For every in-house application, list the package manager files, lock files and vendored directories that pull in libraries. Confirm that each team knows which of its repositories count as in scope, including internal shared libraries that other applications import.

Hosted and acquired software

Commercial and open-source products that run in your environment, or that a vendor hosts for you, still embed third-party components you did not write. Ask each vendor for a software bill of materials or an equivalent component list, and confirm how often it is updated. Where a vendor cannot provide one, record that gap as a risk for the procurement and service provider processes.

Container images and base layers

Container images bundle an operating system layer, language runtimes and libraries, often from public registries. Each base image and each image tag your platform pulls is a third-party component with its own currency and trust questions. Confirm which registries are approved, how base image versions are pinned, and who rebuilds images when a base layer receives a fix.

Build tooling and pipelines

Compilers, build plugins, CI actions and deployment templates run during the build and can alter what ships. They are software components in their own right and are often overlooked when teams inventory only runtime libraries. Confirm that pipeline definitions, pinned action versions and build images are included in the component list and checked for currency and trust.

Teams that choose dependencies

Selection decisions are made by developers, platform engineers and architects, often without a central approval step. Identify who can add a new library or framework, which criteria they apply, and who signs off on components used for security functions such as authentication or encryption. Document these roles so the selection process has an owner that an assessor can interview.

How an assessor tests Safeguard 16.5

This table walks through how an assessor approaches Safeguard 16.5 under the CIS Assessment Specification, from the 16.4 inventory it depends on to the evidence requested and the gaps assessors most often record. Read it as a checklist of what to have ready before a review, and confirm the current measure wording against the specification for v8.1 before you rely on it.

Assessment element	What the assessor looks for	Common finding
Prerequisite	A working third-party software component inventory under Safeguard 16.4, since the assessor cannot judge currency or trust for components nobody has listed	No inventory exists, or the inventory covers only top-level libraries and omits transitive dependencies
Measure	The share of software components that are up to date and from trusted sources, calculated against the inventory population	No calculation is kept, so the organization cannot state what share of its components meet the criteria
Selection criteria	Written criteria for choosing components, such as established maintainers, active security response, supported versions and acceptable licenses	Developers pick libraries ad hoc, and no documented criteria or approval step exists
Source trust	Evidence that artifacts come from official registries or mirrors and that integrity checks such as checksums or signatures are applied where the ecosystem supports them	Components are pulled from unofficial sources or unverified mirrors with no integrity check
Pre-use evaluation	Records showing a component was checked for known vulnerabilities and maintenance status before it entered a build	Evaluations exist in people's memory only, with no tickets, scan output or approval records
Component ownership	A named owner for each component or component group who tracks versions, advisories and upgrade decisions	Components with no owner, so known vulnerabilities sit unaddressed after the original team moves on
Transitive dependencies	Evidence that indirect dependencies are reviewed with the same criteria as direct ones, through lockfiles or an SBOM	Unreviewed transitive dependencies carry outdated or vulnerable versions into production builds
Ongoing currency	Scan results and upgrade records over time, showing that outdated or vulnerable components are identified and planned for remediation	Scans run once at project start and are never repeated, so the compliance share drifts unnoticed

How to implement 16.5 in sequence

This sequence turns Safeguard 16.5 from a policy statement into a repeatable selection and vetting process, so every third-party component that enters or stays in your software is current, trusted and checked for known vulnerabilities before it is relied on.

Confirm the 16.4 component inventory
Start from the third-party software component inventory required by Safeguard 16.4, because the assessment specification treats it as a prerequisite for measuring 16.5. The development or platform lead checks that every application lists its direct and transitive components, versions and owners, and that the list is generated from build manifests or a software bill of materials rather than kept by hand. The output is a confirmed inventory with a named owner and a known review date. If components are missing, fix the inventory before setting criteria, because selection cannot be measured against components nobody can see.
Define trust and selection criteria
Security architects and engineering leads write the criteria a component must meet before adoption. Typical criteria cover maintenance status (active releases and responses to security reports), provenance (the publisher, the source repository and the distribution channel), known vulnerabilities, and license terms checked against your policy. Record the criteria in an approved standard that names who can grant exceptions. The output is a versioned selection standard that developers can apply without asking a security team for each library.
Set a vetting gate in the pipeline
Platform engineering adds an automated gate to the build pipeline so new or updated components are checked against the selection standard before they reach a shared branch or production artifact. The gate fails the build or raises a review request when a component is unmaintained, comes from an unapproved source, carries a blocked license or has an unresolved vulnerability above your threshold. The output is a pipeline configuration, a test build that shows the gate blocking a sample violation, and a written exception path.
Scan for vulnerabilities and outdated versions
Security engineers run scheduled and on-demand scans across the inventory, not just at build time, because newly published advisories affect components that were already approved. Tools such as Trivy can generate a software bill of materials and scan dependencies, OWASP Dependency-Track can ingest CycloneDX SBOMs and report known vulnerabilities, outdated components, modified components and license risk, and Wazuh or Fleet can cover software installed on hosts. The output is a findings list per application, with each finding linked to a component, a version and an owner.
Set a remediation path for components below the bar
Application owners and the security function agree how each failing component is handled: upgrade to a fixed or maintained version, replace it with an approved alternative, apply a documented compensating control, or record a time-limited risk acceptance signed by the accountable owner. Each path needs a target and a reviewer. The output is a remediation register that shows the component, the decision, the owner and the closure evidence, which the assessor will sample to test the Compliance metric for 16.5.
Measure and report the compliance share
The security function calculates the share of in-scope components that are up to date and trusted, which is the metric the assessment specification uses for 16.5. Measurement is repeated on a schedule the organization defines and tracked against the register from the previous step. The output is a dated report that shows the numerator, the denominator, open exceptions and trends, retained so an independent assessor can recompute the figure from the underlying scan records. Confirm with your assessor which sampling and retention periods they expect.

How self-hosted open-source tools fit the 16.5 workflow

Trivy, an Apache-2.0 scanner, identifies the operating system packages and software dependencies in a target such as a container image, file system or repository. It can export what it finds as a software bill of materials, and it can also scan an existing SBOM. For Safeguard 16.5, this gives the team a repeatable way to see which components are in use and to check them against known vulnerabilities before a build ships. The output is a dated, machine-readable record that can be kept with each release.

Build-time generation: Run the scan in the CI pipeline so each image or artifact gets an SBOM tied to a specific build identifier.
Rescanning stored SBOMs: Scan archived SBOMs when new vulnerability data arrives, which catches components that were clean at build time but are now affected.
Dependency coverage: Confirm which language ecosystems and package managers the scanner reads in your stack, since coverage varies by target type.
Scan results as records: Store reports alongside the SBOM so the team can show when a component was checked and what was done about its findings.
Offline operation: Confirm how the vulnerability database is updated and whether it can be mirrored inside an air-gapped network.

Before relying on this tab's output, confirm with your own pipeline that every in-scope artifact produces an SBOM and that the scanner's coverage matches the components your developers actually use.

Evidence that passes a 16.5 review

An assessor testing Safeguard 16.5 looks for a chain of records: a policy that defines which components are acceptable, proof that each component passed a vetting gate, a current inventory for every release, and a trail showing how vulnerable or outdated components were fixed or formally accepted. The cards below cover each artifact and how to keep it current between audits.

Approved component selection policy

This written policy defines what counts as a trusted source, which frameworks and libraries are preferred, which license types are acceptable, and who may approve a new component. Under the 16.5 measure, the share of up-to-date and trusted components is only meaningful against a stated standard, so the assessor will compare what teams actually use with what this policy allows. Confirm the policy names an owner, has a review date, and is linked from the developer onboarding material.

Vetting gate records

Each new third-party component should leave a record showing its source, version, license, known vulnerabilities at the time of intake, and the reviewer's decision. Keep these records in the ticket system or repository pull request where the component was introduced, so the decision and the date are traceable. Sampling a handful of recent additions is a common assessor check, so confirm that every sampled component has a complete record.

SBOM for every release

A CycloneDX or SPDX software bill of materials generated for each release shows exactly which components shipped. Generate it in the build pipeline, not by hand, and store it with the release artifact so it cannot drift from the code. Assessors compare the SBOM against the 16.4 inventory and check whether the versions listed are current, so mismatches between the two are a frequent finding.

Scan reports showing current versions

Dependency and container scan output shows whether each component is at a supported, current version and whether any known vulnerability applies. Schedule scans on each build and on a recurring basis for components already in production, since new advisories affect code that passed earlier reviews. Keep the dated output so you can show the state of the software at any point in the audit period, not only the day you ran the last scan.

Exception records with owners and dates

Some outdated or flagged components will stay in use for valid reasons, such as a vendor dependency that has not yet released a fix. Each exception should name the component, the risk accepted, the compensating control, the accountable owner, and an expiry date that forces a new decision. Exceptions without an owner or expiry date are the findings most often raised against this safeguard, so review the open list at least as often as the inventory.

Remediation tickets with closure dates

When a scan or advisory identifies a vulnerable component, the resulting ticket should show the upgrade or replacement, the test evidence, the release that shipped the fix, and the closure date. Assessors use these tickets to test whether the process from detection to fix works in practice. Tie tickets to the affected SBOM entries so each fix can be traced to the release where it took effect.

What meeting 16.5 costs in money and effort

The cost of meeting Safeguard 16.5 is mostly staff time, not software. The open-source tools that support it, such as OWASP Dependency-Track (Apache-2.0), Trivy (Apache-2.0), Wazuh (GPL-2.0-only) and Fleet (MIT), carry no license fee, but the organization still pays for the servers or cloud accounts that run them, the engineers who wire them into build pipelines, and the people who read their output. Because Safeguard 16.5 cannot be measured without the component inventory from Safeguard 16.4, the first cost is often the inventory itself. Ask any implementation partner to price the inventory and the selection gates as separate line items, so you can see which part is one-time and which recurs.

One-time setup covers defining what counts as an approved, trusted source, choosing the criteria for preferring established frameworks and libraries, configuring the scanners and vulnerability feeds, and building the gates that stop a new component from entering a build until it has been evaluated. Recurring work is less visible and usually larger. Someone must triage new findings on components already in use, keep SBOMs current as dependencies change, and maintain an exception record for every component that is kept despite a known weakness or an end-of-support date. Each exception needs an owner, a justification and a review date. Hosting and feed updates add modest but steady operating cost, and hosting an offline vulnerability copy adds administration effort.

The main drivers of cost are the number of applications and pipelines in scope, how many components each one pulls in, whether builds are automated, and how many teams can approve exceptions. External review adds cost where the organization wants an independent check of its selection criteria before an assessment, and assessor sampling adds effort because the assessor will ask for records from a selection of components and builds. Ask for a quote that states the number of applications in scope, the tools to be deployed, who will operate them after handover, how exception records will be kept, and what evidence the partner will hand over at the end. Confirm the assessment expectations for your own environment with your assessor before you sign.

Cost components for 16.5 and what drives each

This table compares the main cost components of meeting Safeguard 16.5, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. No prices are given because none are supplied; use it to structure the questions you ask in a written quote.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling and hosting	Recurring	Number of applications and repositories scanned, SBOM generation frequency, and whether the vulnerability database is hosted offline or updated online	Standardize on one SBOM format, scan in existing pipelines, and confirm license terms and hosting needs for each open-source tool before scaling
Pipeline engineering	One-time, with periodic upkeep	Number of build systems, languages and package managers, and how many gates block builds versus report findings	Start with a single pipeline template reused across teams, and add gates only after the team trusts the findings
Triage and remediation effort	Recurring	Volume of outdated or vulnerable components, transitive dependency depth, and whether updates break tests or require code changes	Prioritize by exploitability and reachability, group upgrades by owner, and keep dependencies current in small, frequent steps
Exception management	Recurring	Number of components that cannot be upgraded, such as legacy or vendor-locked libraries, and the review cadence for each exception	Document a short approval path with an owner, a compensating control and an expiry date for each exception
External review	Recurring or per engagement	Scope of an independent assessment, number of applications in scope and whether an outside party reviews the selection process	Prepare evidence in advance, confirm scope in writing, and ask the reviewer which artifacts they will sample
Assessor sampling	Recurring, per assessment cycle	Number of components and applications the assessor selects, and how complete the inventory and scan records are	Keep the 16.4 inventory current and export scan and approval records in a consistent format so sampling is quick

Who owns what for 16.5: your team, a partner and the assessor

Your organization owns the Safeguard. Assessors test whether the component selection process works and whether it is followed, so the decisions behind it must be made and recorded by people inside the enterprise. Your team sets the standard for what counts as an established, proven and trusted component, decides which sources are acceptable, and accepts or rejects risk when a vulnerable or unmaintained component is found.

Selection policy: Write the rules for which frameworks, libraries and package sources teams may use, and what evidence of trust is required before adoption.
Risk decisions: Decide whether a flagged component is upgraded, replaced, patched or temporarily accepted, and who approves that choice.
Exception register: Record each approved exception with its owner, reason, compensating measure and review date.
Inventory linkage: Make sure the component inventory required by Safeguard 16.4 is the source the selection process uses.
Operating cadence: Assign owners for reviewing scanner output and deciding on findings within a set schedule.

Before engaging anyone, confirm that you can produce the signed policy, the decision log and the exception register, because these are the records an assessor will ask for first.

Where organizations fall short on 16.5

Most organizations already keep some list of the libraries they use, so the shortfall under Safeguard 16.5 is rarely the absence of data. It is the absence of a decision: written criteria for what may enter the codebase, a check that happens before adoption, and an owner who acts when a component goes stale. The gaps below are the ones assessors tend to find when they ask how a component was chosen and who is watching it now.

No written selection criteria

Teams often pick libraries by familiarity or by whatever a tutorial used. Safeguard 16.5 expects a preference for established, proven frameworks and libraries acquired from trusted sources, so the criteria should be written down. Check whether the document states which sources are approved, how maintenance activity is judged, what license types are allowed, and who can grant an exception. Without that document, an assessor has nothing to measure the selections against.

Inventory without a vetting step

Safeguard 16.4 produces a list of components, but a list does not show that anyone evaluated them. Many organizations record what is in use and stop there, so a component with a known vulnerability or a dormant upstream project passes through unchecked. Confirm that each new entry in the inventory triggers a documented review before merge, and that the review result is stored next to the inventory record. The CIS Controls Assessment Specification treats 16.4 as a prerequisite for measuring 16.5, so a gap here blocks the whole measurement.

Ignoring transitive dependencies

Teams review the packages they declare directly and overlook the packages those packages pull in. The vulnerable component is frequently several levels down, outside anyone's review. Check whether the organization's tooling resolves the full dependency tree, including container base images and OS packages, and whether the compliance metric counts those indirect components. A review limited to direct dependencies will show a high compliance rate that does not reflect the code actually shipped.

No owner for unmaintained libraries

A component that was current at adoption can become abandoned, with no releases, unanswered security reports and no fix path. Safeguard 16.5 asks for up-to-date components, so an abandoned library counts against the organization even when it still works. Confirm that every component in the inventory has a named owner responsible for tracking upstream status, and that the process defines what happens when a project is archived: replacement, fork or documented risk acceptance with a sign-off date.

Evidence produced once, not per release

A component review completed at project kickoff proves that a decision was made once. It does not show that the software in production today uses current, trusted components. Assessors look for records tied to releases, such as a generated software bill of materials and a scan result for each build, along with the approval trail for any new dependency. Check that the pipeline regenerates these artifacts on every release and that old records are retained so the history can be reviewed.

Vulnerability findings with no closure

Scanners report known vulnerabilities in components, yet many organizations never record whether each finding was fixed, accepted or found not applicable. The open list grows, and the compliance share cannot be reported with confidence. Check that each finding has a status, an owner and a target date, that accepted risks carry an approval, and that the tooling can show how many components were current at a given point. Ask the team to walk an assessor through one finding from detection to closure.

Questions buyers ask about Safeguard 16.5

Does Safeguard 16.5 apply to IG1 organizations?

No. Safeguard 16.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and is not part of the IG1 essential cyber hygiene set. An IG1 organization that builds or hosts software still benefits from knowing which libraries it runs, but the CIS Controls Assessment Specification measures 16.5 only for organizations in IG2 or IG3. Confirm your Implementation Group with the CIS Implementation Groups pages before you scope the work, because a contract or regulator may ask for a different baseline.

How much effort does keeping third-party components current take?

The effort depends mostly on how many applications you run, how many components each one pulls in, and whether you already track them. Costs come in two parts: a one-time setup of inventory, scanning and a update policy, and a recurring cost of reviewing alerts, testing upgrades and retiring unsupported components. Teams that already produce a component inventory under Safeguard 16.4 typically spend far less on 16.5, because the inventory is the input the assessment checks first. Ask any provider to break its quote into setup and recurring operations so you can see where your own staff stays involved.

Can our team meet Safeguard 16.5 without outside help?

Yes, if you have engineers who can operate software composition tools, maintain a dependency inventory and work with development teams on upgrades. The organization owns the control and must be able to show it operates. Outside help is most useful when the inventory is incomplete, when many teams ship software on different stacks, or when no one has time to build the review process. An implementation partner can install and configure the tooling in your environment and document the process, but the evidence must show your team using it.

How long does it take to put Safeguard 16.5 in place?

The duration depends on scope rather than on a fixed number. The main variables are the number of applications in scope, whether a 16.4 inventory already exists, how many teams need to change their build pipelines, and how much history of component use the assessor will expect to see. A written scope that lists systems, deliverables and milestones gives you a timeline you can check. Ask for the timeline to be tied to that scope, and ask what the plan assumes about your existing inventory and team availability.

What does an implementation partner need from our team?

A partner needs access to the systems in scope, named owners for each application, and decisions made quickly. Typical inputs include source code repository access, build pipeline details, existing software bills of materials, the current component inventory, and the policy that governs approved sources and upgrade timing. Your staff must also agree who triages alerts and who approves exceptions. DeployOpen works under a fixed-scope written agreement, so the client's responsibilities should be listed in that scope before work starts.

Is open-source tooling enough to satisfy Safeguard 16.5?

Open-source tools can produce much of the evidence an assessor will ask for, but they do not decide compliance on their own. OWASP Dependency-Track can ingest CycloneDX software bills of materials and flag components with known vulnerabilities, outdated versions or license risk. Trivy can generate a software bill of materials and scan existing ones. The organization still needs a written policy on trusted sources, an upgrade process and records showing decisions were made. Confirm with your assessor which artifacts they accept before you rely on a specific tool.

What will the auditor ask for to test Safeguard 16.5?

Assessors typically start with the component inventory required under Safeguard 16.4, then check whether the components in use are current and come from trusted sources. They will ask for the compliance measure the CIS Controls Assessment Specification uses, which is the share of up-to-date and trusted software components, so expect to show how that share is calculated. Be ready to produce scan results, dated records of vulnerability evaluations before adoption, and examples of upgrades or exceptions. Confirm the exact evidence list with your auditor, since CIS does not replace any regulatory or certification scheme.

How DeployOpen scopes and prepares 16.5 evidence

DeployOpen works on Safeguard 16.5 by preparing the systems, component inventory and evidence that show third-party software is current, trusted and checked for vulnerabilities before use. The organization keeps ownership of its selection policy and decisions, and an independent assessor is the party that tests and reports on the result.

How we scope

The written scope names which applications, pipelines and self-hosted platforms fall under Safeguard 16.5 and which teams approve component sources.
The scope confirms the prerequisite 16.4 component inventory exists and states what gaps must be closed before measurement begins.
Engagements are fixed-scope, so deliverables, responsibilities and timelines are agreed in writing before any work starts.

How we build

We configure open-source tooling such as Dependency-Track, Trivy and Wazuh to ingest SBOMs and flag outdated or vulnerable components.
We set up approved trusted-source rules and a vulnerability evaluation step that runs before a new component enters the build.
We test the pipeline and reporting so the compliance metric for up-to-date and trusted components can be produced from real data.

How we hand over

Handover includes the documented selection and evaluation process, tool configurations and the run books the client team needs.
Evidence packs include SBOM exports, vulnerability reports, approval records and metric outputs mapped to the assessment specification.
Ownership of the controls stays with the organization, and an independent auditor or assessor decides what the evidence proves.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainers can cover tool upgrades, feed updates and periodic review of the component inventory and vulnerability findings.
Confirm with DeployOpen during scoping which assessment cycles, auditors and framework mappings your organization needs supported.