IG2 IG3

Use Up>to>Date and Trusted Third>Party Software Components

Control Group: 16. Application Software Security

Asset Type: Applications

Security Function: Protect

Description

Use up-to-date and trusted third-party software components. When possible, choose established and proven frameworks and libraries that provide adequate security. Acquire these components from trusted sources or evaluate the software for vulnerabilities before use.

Implementation Checklist

1

Assess current protection controls in place

2

Configure and deploy required security controls

3

Test control effectiveness in non-production environment

4

Deploy to production and verify functionality

5

Document configuration and operational procedures

6

Select and configure vulnerability scanning tool

7

Define scan scope, frequency, and credentials

8

Establish vulnerability remediation SLAs by severity

9

Create exception/waiver process for unremediated findings

10

Inventory all third-party service providers

11

Classify third parties by risk level

12

Conduct security assessments of critical vendors

13

Include security requirements in contracts

Tool Recommendations

Snyk Gartner MQ Visionary, Application Security Testing 2024; Forrester Wave Leader, SCA 2023

Developer-first application security with SCA, container scanning, IaC security, and SAST integrated into CI/CD

Snyk · Per-developer subscription

Synopsys Software Integrity Gartner MQ Leader, Application Security Testing 2024

Application security testing suite with SAST (Coverity), SCA (Black Duck), and DAST for comprehensive AppSec

Synopsys · Per-developer subscription

Checkmarx One Gartner MQ Leader, Application Security Testing 2024

Cloud-native application security platform with SAST, SCA, DAST, API security, and supply chain security testing

Checkmarx · Per-developer subscription

Threats & Vulnerabilities (CIS RAM)

Threat Scenarios

Exploitation of Known Vulnerability in Outdated Library

Integrity

An attacker exploits a well-documented vulnerability in an outdated third-party library that the development team never updated because no process requires keeping components current.

Malicious Package Substitution Attack

Integrity

A developer downloads a third-party component from an untrusted source that contains embedded malware, because no policy requires acquiring components from trusted repositories.

Typosquatting Attack on Package Repository

Confidentiality

A developer installs a malicious package with a name similar to a legitimate library from a public repository because no vetting process validates components before inclusion in the codebase.

Vulnerabilities (When Safeguard Absent)

Outdated Third-Party Components in Production

Without a requirement to keep third-party components current, applications run with outdated versions containing known vulnerabilities that attackers can easily exploit using publicly available tools.

No Validation of Third-Party Component Sources

Absence of a trusted sourcing requirement means developers may acquire components from unverified repositories, increasing the risk of including compromised or malicious code.

Evidence Requirements

Type	Evidence Item	Collection Frequency
Technical	Configuration screenshots or exports showing protection controls enabled	Captured quarterly
Document	Procedure documentation for protection measures	Reviewed annually
Technical	Vulnerability scan reports showing scope and findings	Per scan cycle
Record	Vulnerability remediation tracking with SLA compliance metrics	Monthly
Record	Third-party risk assessment reports and scorecards	Annually per vendor
Document	Vendor contracts with security requirements	Per contract cycle
Document	Governing policy document (current, approved, communicated)	Reviewed annually