1. Purpose

The Third-Party Component Vulnerability Procedure defines how the organization identifies, evaluates, prioritizes, remediates, and verifies vulnerabilities affecting third-party software components used in its applications, infrastructure, development environments, and technology services.

The procedure helps ensure that vulnerabilities in:

• Open-source libraries
• Commercial software components
• Frameworks
• SDKs
• Package dependencies
• Transitive dependencies
• Container images
• Operating-system packages
• Build tools
• CI/CD components
• Infrastructure-as-Code modules
• AI/ML components
• Third-party plugins
• External software packages

are identified and managed according to their actual security and business risk.

The objective is not simply to fix every vulnerability based on a severity score. The organization should determine whether the vulnerable component is actually used, exploitable, exposed, and relevant to the organization’s environment.

---

2. Core Principle

The vulnerability-management process should follow:

Component → Application → Version → Vulnerability → Exposure → Exploitability → Business Impact → Risk → Treatment → Verification

For example:

Log4j dependency → Customer-facing Java application → Affected version → Known vulnerability → Internet-facing application → Exploit possible → Potential remote code execution → High risk → Upgrade dependency → Testing → Deployment → Verification

---

3. Scope

This procedure applies to third-party components used in:

• Production applications
• Customer-facing applications
• Internal applications
• Development environments
• Test environments
• Build environments
• CI/CD pipelines
• Container images
• Cloud infrastructure
• Operating systems
• Infrastructure-as-Code
• APIs and SDKs
• Security tools
• Monitoring tools
• AI/ML systems
• Developer tooling

The organization should determine whether development-only components require the same treatment as production components based on risk.

---

4. Key Definitions

Third-Party Component

Software developed or maintained outside the organization and incorporated into or used by organizational systems.

Direct Dependency

A component explicitly included by an application.

Example:

express included directly in a Node.js application.

Transitive Dependency

A component required by another dependency.

Example:

Application → Package A → Package B

Package B is a transitive dependency.

Vulnerability

A weakness that could potentially be exploited to compromise confidentiality, integrity, availability, or other security properties.

Exploitability

The practical ability or likelihood that a vulnerability can be exploited in the organization’s environment.

Vulnerability Risk

The risk resulting from the combination of vulnerability, exposure, exploitability, business impact, and existing controls.

---

5. Roles and Responsibilities

Development Team

• Maintain application dependencies
• Review vulnerability notifications
• Upgrade vulnerable components
• Test updates
• Avoid introducing unauthorized dependencies

DevSecOps/Security Team

• Operate or oversee vulnerability-scanning processes
• Validate significant findings
• Prioritize vulnerabilities
• Define security requirements
• Monitor remediation

Application Owner

• Assess business and technical impact
• Approve remediation plans
• Accept residual risk where authorized

Engineering/Technology Leadership

• Resolve overdue or high-risk vulnerabilities
• Approve exceptions where required
• Ensure resources for remediation

Risk Owner

• Own significant residual risk
• Approve risk acceptance according to organizational authority

---

6. Component Identification

The organization should maintain visibility of third-party components through mechanisms such as:

• Software Dependency Inventory
• SBOM
• Package-manager manifests
• Container manifests
• Operating-system package inventories
• CI/CD scanning
• Software Composition Analysis (SCA)
• Vulnerability scanners

Examples:

• package.json
• package-lock.json
• requirements.txt
• poetry.lock
• pom.xml
• build.gradle
• go.mod
• Cargo.lock
• Container image manifests

Automated discovery should be preferred over relying exclusively on manually maintained spreadsheets.

---

7. Vulnerability Sources

Vulnerabilities may be identified through:

• SCA tools
• SBOM correlation
• Dependency scanners
• Container scanners
• Cloud security tools
• Vendor security advisories
• Open-source project advisories
• CVE databases
• Security researchers
• CERT advisories
• Internal security testing
• Penetration testing
• Bug bounty reports
• Threat intelligence
• Security incidents

The organization should maintain reliable sources appropriate to its technology stack.

---

8. Vulnerability Identification Process

The process should be:

Step 1 — Identify Component

Record:

• Component name
• Version
• Application
• Environment
• Direct/transitive status
• Source
• Supplier/maintainer

Step 2 — Identify Vulnerability

Record:

• Vulnerability identifier where available
• Affected versions
• Fixed versions
• Severity
• Published date
• Available exploit information
• Vendor/project advisory

Step 3 — Determine Applicability

Confirm:

• Is the affected component actually present?
• Is the affected version deployed?
• Is the vulnerable functionality used?
• Is the application exposed?
• Is exploitation technically possible?
• Are compensating controls present?

---

9. Vulnerability Record

A practical vulnerability record should contain:

Field	Details
Vulnerability ID
CVE/Advisory ID
Component
Version
Application
Environment	Production / Test / Development
Direct/Transitive
Source
Severity
Exploit Available	Yes / No / Unknown
Internet Exposure	Yes / No
Vulnerable Function Used	Yes / No / Unknown
Business Criticality
Affected Information
Risk Rating
Remediation
Owner
Target Date
Status
Verification Evidence

---

10. Vulnerability Validation

A scanner finding should not automatically be treated as a confirmed organizational risk.

Validate:

Component Presence

Is the component actually deployed?

Version

Is the affected version actually running?

Vulnerable Functionality

Does the application use the functionality associated with the vulnerability?

Exposure

Can an attacker reach the vulnerable component?

Exploitability

Is exploitation technically feasible?

Existing Controls

Are controls reducing the likelihood or impact?

Business Impact

What would happen if exploitation occurred?

---

11. Risk Assessment

Risk should consider more than the vulnerability’s published severity.

Consider:

Vulnerability Severity + Exploitability + Exposure + Business Criticality + Data Sensitivity + Existing Controls

Example factors:

Factor	Assessment
Vulnerability Severity
Exploit Availability
Internet Exposure
Privileged Access
Sensitive Data
Customer Impact
Business Criticality
Exploitability in Environment
Compensating Controls
Risk

The organization’s approved risk methodology should determine the final risk rating.

---

12. Suggested Priority Model

A practical prioritization model may be:

Critical

Examples:

• Actively exploited vulnerability
• Remote compromise of an internet-facing critical application
• Vulnerability affecting highly privileged infrastructure
• Potential significant customer/data impact

High

Examples:

• Serious vulnerability in production
• Exploitable vulnerability with meaningful business impact
• Vulnerability in an important customer-facing application

Medium

Examples:

• Exploitable under limited conditions
• Internal application exposure
• Meaningful but contained business impact

Low

Examples:

• Limited exploitability
• Low business impact
• Strong compensating controls
• Development-only exposure where appropriate

These categories are illustrative and should be aligned with the organization’s risk methodology.

---

13. Remediation Decision

For each vulnerability, determine the appropriate action.

Upgrade

Move to a secure/fixed component version.

Patch

Apply an available security patch.

Remove

Remove an unnecessary dependency.

Replace

Replace the component with an alternative.

Configuration Change

Disable vulnerable functionality or apply a secure configuration where appropriate.

Compensating Control

Implement another control to reduce risk temporarily.

Accept

Accept residual risk through formal risk acceptance where justified and authorized.

---

14. Remediation Workflow

The standard workflow is:

Vulnerability Identified

↓

Component & Version Confirmed

↓

Applicability Validated

↓

Risk Assessed

↓

Priority Assigned

↓

Remediation Planned

↓

Update/Patch Implemented

↓

Application Tested

↓

Security Scan Repeated

↓

Vulnerability Verified

↓

Evidence Retained

↓

Finding Closed

---

15. Remediation Timeframes

The organization should define target remediation periods based on risk.

Example:

Risk	Example Target
Critical	Immediate / expedited
High	Short-term
Medium	Planned remediation
Low	Routine maintenance

The exact timeframe should be defined by the organization’s risk appetite, contractual commitments, regulatory requirements, and technology environment.

Actively exploited vulnerabilities may require emergency treatment regardless of the normal remediation schedule.

---

16. Emergency Vulnerability Process

An emergency process should be available for vulnerabilities that present significant immediate risk.

Trigger Examples

• Active exploitation
• Critical remote-code-execution vulnerability
• Critical vulnerability in internet-facing production software
• Major zero-day vulnerability
• Compromise indicators
• Vendor-directed emergency patch

Process

Alert → Validate → Assess Exposure → Contain → Patch/Upgrade → Test → Deploy → Verify → Monitor

Possible temporary measures include:

• Disable vulnerable functionality
• Restrict network access
• Block affected endpoints
• Apply WAF rules
• Remove exposed service
• Disable affected dependency
• Increase monitoring

Temporary controls should not automatically be treated as permanent remediation.

---

17. Dependency Update Testing

Before production deployment, test the updated component for:

• Functional compatibility
• Security impact
• API compatibility
• Performance
• Authentication
• Authorization
• Data processing
• Integration
• Regression
• Logging
• Monitoring

For critical applications, use an appropriate test environment before production deployment.

---

18. Production Deployment

Once the update is approved:

1. Deploy the fixed version.
2. Record the deployed version.
3. Confirm successful deployment.
4. Run appropriate security scanning.
5. Validate application functionality.
6. Confirm vulnerability status.
7. Monitor for unexpected behavior.
8. Retain deployment evidence.

---

19. Verification

A vulnerability should not be closed simply because a developer says the package was updated.

Verification may include:

• SCA scan
• SBOM comparison
• Package manifest review
• Container scan
• Dependency version verification
• Security testing
• Application testing
• Deployment evidence

Closure Evidence

Previous Version:
Fixed Version:
Deployment Date:
Environment:
Verification Method:
Verification Result:
Evidence Location:

---

20. Transitive Dependency Vulnerabilities

Transitive dependencies require special attention.

Example:

Application

→ Package A

→ Package B

→ Package C

If Package C contains a vulnerability, the development team should determine:

• Why Package C is included
• Which package introduced it
• Whether the vulnerable functionality is used
• Whether Package A can be upgraded
• Whether Package C can be overridden safely
• Whether the dependency can be removed
• Whether compensating controls are available

Do not simply ignore a vulnerability because it is not a direct dependency.

---

21. Unsupported or End-of-Life Components

Identify components that:

• No longer receive security updates
• Are end-of-life
• Are abandoned
• Have an unsupported runtime
• Have an unmaintained dependency chain

For each:

Component → Business Dependency → Security Risk → Replacement Options → Migration Plan → Target Date

Where immediate replacement is not possible, the risk should be formally assessed and managed.

---

22. Container Vulnerability Management

For containerized applications, assess:

• Base image
• OS packages
• Application packages
• Runtime
• Third-party libraries
• Container configuration
• Image provenance
• Image signing/integrity where implemented
• Registry security
• Deployment environment

Example:

Node.js application → Docker image → Ubuntu base image → npm dependencies

A vulnerability in the base image can be as relevant as a vulnerability in the application’s npm packages.

---

23. CI/CD Vulnerability Management

Where practical, integrate dependency security into CI/CD.

Example workflow:

Developer Commit

↓

Dependency/SCA Scan

↓

Build

↓

Container Scan

↓

SBOM Generation

↓

Security Gate

↓

Test

↓

Deployment

↓

Post-Deployment Verification

Security gates should be configured according to risk rather than automatically blocking every vulnerability.

---

24. SBOM Integration

The organization’s SBOM should support vulnerability management by providing:

• Component name
• Version
• Supplier/maintainer
• Dependency relationships
• Identifiers such as PURL/CPE where applicable
• Release/build information

When a new vulnerability is announced:

Advisory → Component Identification → SBOM Correlation → Affected Applications → Risk Assessment → Remediation

This can significantly reduce the time required to determine exposure.

---

25. AWS SaaS Example

Consider a SaaS application running on AWS.

The application uses:

• Node.js
• React
• PostgreSQL
• AWS SDK
• Docker
• npm dependencies
• Terraform modules

A new vulnerability is identified in an npm dependency.

Assessment

Component: npm package
Version: 4.x
Application: Customer SaaS platform
Environment: Production
Exposure: Internet-facing
Data: Customer information
Vulnerability: High severity
Exploit: Public exploit available
Risk: High

Treatment

1. Confirm affected version.
2. Identify whether the vulnerable function is used.
3. Identify fixed version.
4. Upgrade dependency.
5. Run automated tests.
6. Build a new container.
7. Generate/update SBOM.
8. Scan the new image.
9. Deploy through CI/CD.
10. Verify the vulnerability is no longer present.
11. Retain evidence.

---

26. Vulnerability Exceptions

If a vulnerability cannot be remediated within the required timeframe, document an exception.

The exception should include:

Field	Details
Vulnerability
Component
Business Reason
Why Remediation Is Delayed
Risk
Compensating Controls
Target Remediation Date
Risk Owner
Approval
Expiry Date

Exceptions should be time-bound and periodically reviewed.

A permanent exception should not be created simply because remediation is inconvenient.

---

27. Vulnerability Monitoring

Monitor for:

• New CVEs
• Vendor advisories
• Open-source advisories
• Exploited vulnerabilities
• Security mailing lists
• Threat intelligence
• Supplier notifications
• New versions
• End-of-life announcements
• Dependency changes
• New vulnerabilities affecting existing SBOM components

The organization should define who receives and evaluates these notifications.

---

28. Metrics and Reporting

Useful metrics include:

• Number of open component vulnerabilities
• Critical vulnerabilities
• High vulnerabilities
• Vulnerabilities past target date
• Mean time to remediation
• Number of affected applications
• Number of vulnerable components
• Number of unsupported components
• Number of exceptions
• Percentage of applications covered by SCA
• Percentage of production releases with SBOM
• Vulnerabilities detected before production
• Vulnerabilities detected after production

Metrics should be used to identify systemic improvement opportunities rather than simply to measure developer performance.

---

29. Records and Evidence

Maintain appropriate records such as:

• SCA scan results
• Vulnerability reports
• SBOMs
• Dependency inventories
• Vendor advisories
• Risk assessments
• Remediation tickets
• Pull requests
• Change records
• Test results
• Deployment records
• Exception approvals
• Verification scans
• Closure evidence

---

30. Relationship With Other ISMS Documents

Document	Relationship
Software Dependency Inventory	Identifies software dependencies
SBOM	Provides component-level inventory
Vulnerability Management Procedure	Provides broader vulnerability-management process
Third-Party Software Assessment	Assesses software before use
Software Supply Chain Risk Assessment	Assesses broader supply-chain risk
Secure Development Procedure	Defines secure development practices
Change Management Procedure	Controls dependency changes
Patch Management Procedure	Addresses patching
Risk Register	Records significant risks
Security Incident Procedure	Handles exploitation or compromise
Exception/Risk Acceptance	Handles justified remediation delays
Software Release Checklist	Verifies release security

---

31. Common Mistakes

Mistake 1 — Fixing only direct dependencies

Transitive dependencies can also create significant vulnerabilities.

Mistake 2 — Treating every CVE as equally urgent

Risk depends on actual exposure and business impact.

Mistake 3 — Relying only on CVSS

Published severity is useful, but organizational context should also be considered.

Mistake 4 — Closing findings without verification

An updated source repository does not necessarily mean the vulnerable version was removed from production.

Mistake 5 — Ignoring container/base-image vulnerabilities

The application may be secure while the underlying image remains vulnerable.

Mistake 6 — No inventory

Without knowing which applications use a component, vulnerability response becomes slow and unreliable.

Mistake 7 — No emergency process

Critical exploited vulnerabilities may require treatment outside normal release cycles.

Mistake 8 — Permanent exceptions

Risk acceptance should not become a substitute for remediation.

---

32. Quick Audit Checklist

Question	Yes/No/N/A
Are third-party components inventoried?
Are direct and transitive dependencies identified?
Is an SBOM maintained where appropriate?
Are dependencies regularly scanned?
Are reliable vulnerability sources monitored?
Are vulnerabilities validated before treatment?
Is actual exposure considered?
Is exploitability considered?
Is business impact considered?
Are internet-facing applications prioritized appropriately?
Are critical vulnerabilities handled through an expedited process?
Are remediation targets defined?
Are dependency updates tested?
Are container vulnerabilities assessed?
Are CI/CD dependencies assessed?
Are unsupported components identified?
Are exceptions formally approved?
Are remediation actions verified?
Is evidence retained?
Are metrics reported?
Is the process periodically reviewed?

---

33. Recommended Vulnerability Lifecycle

A practical lifecycle is:

Discover

Identify components and versions.

↓

Monitor

Monitor vulnerability sources and advisories.

↓

Detect

Identify vulnerabilities affecting organizational components.

↓

Validate

Confirm component, version, exposure, and applicability.

↓

Assess

Determine exploitability, impact, and risk.

↓

Prioritize

Determine remediation priority.

↓

Treat

Patch, upgrade, remove, replace, configure, or apply compensating controls.

↓

Test

Validate functionality and security.

↓

Deploy

Release the corrected component.

↓

Verify

Rescan and confirm remediation.

↓

Close

Retain evidence and close the finding.

↓

Improve

Analyze trends and improve dependency-management practices.

---

34. Final Audit Trail

A strong audit trail should demonstrate:

Component Identified
↓
Version Recorded
↓
Vulnerability Detected
↓
Applicability Validated
↓
Exposure & Exploitability Assessed
↓
Business Impact Determined
↓
Risk Rated
↓
Remediation Assigned
↓
Fix Implemented
↓
Application Tested
↓
Production Deployment Verified
↓
Security Scan Repeated
↓
Evidence Retained
↓
Finding Closed

Final Principle

Third-party component vulnerability management should not be treated as simply “scan → find CVE → upgrade.”

A mature process connects:

Component → Application → Version → Vulnerability → Exposure → Exploitability → Business Impact → Risk → Remediation → Verification

This gives the organization a defensible, repeatable process for managing software supply-chain vulnerabilities while keeping remediation focused on actual organizational risk.