# V5 Component Analysis

## Control Objective

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software components. Every component, direct or transitive, is a candidate for analysis. Risk inherited through the use of third-party software may directly affect the application or systems that rely on them.

### **Known Vulnerabilities**

There are multiple public and commercial sources of vulnerability intelligence. Vulnerabilities become known when they are published to services such as the National Vulnerability Database (NVD), or are otherwise documented in public defect trackers, commit logs, or other public source.

### **Component Version Currency**

If component versions are specified, then determining if a component is out-of-date or end-of-life is possible. Outdated and end-of-life components are more likely to be vulnerable and less likely to be supported as first-class entities. Out-of-date components can slow down system remediation due to interoperability issues. Using up-to-date components reduces exposure time and may include remediations of non-disclosed vulnerabilities.

### **Component Type**

Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. Libraries, frameworks, applications, containers, and operating systems are common component types.

### **Component Function**

Identifying and analyzing the purpose of each component may reveal the existence of components with duplicate or similar functionality. Potential risk can be reduced by minimizing the number of components for each function and by choosing the highest quality components for each function.

### **Component Quantity**

The operational and maintenance cost of using open source may increase with the adoption of every new component. Decreased ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

### **License**

Third-party and open-source software is typically released under one or more licenses. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Utilizing components with licenses which conflict with an organizations objectives or ability can create risk to the business.

## Verification Requirements

|     #    | Description                                                                                                                  |  L1 |  L2 |  L3 |
| :------: | ---------------------------------------------------------------------------------------------------------------------------- | :-: | :-: | :-: |
|  **5.1** | Component can be analyzed with linters and/or static analysis tools                                                          |  ✓  |  ✓  |  ✓  |
|  **5.2** | Component is analyzed using linters and/or static analysis tools prior to use                                                |     |  ✓  |  ✓  |
|  **5.3** | Linting and/or static analysis is performed with every upgrade of a component                                                |     |  ✓  |  ✓  |
|  **5.4** | An automated process of identifying all publicly disclosed vulnerabilities in third-party and open source components is used |  ✓  |  ✓  |  ✓  |
|  **5.5** | An automated process of identifying confirmed dataflow exploitability is used                                                |     |     |  ✓  |
|  **5.6** | An automated process of identifying non-specified component versions is used                                                 |  ✓  |  ✓  |  ✓  |
|  **5.7** | An automated process of identifying out-of-date components is used                                                           |  ✓  |  ✓  |  ✓  |
|  **5.8** | An automated process of identifying end-of-life / end-of-support components is used                                          |     |     |  ✓  |
|  **5.9** | An automated process of identifying component type is used                                                                   |     |  ✓  |  ✓  |
| **5.10** | An automated process of identifying component function is used                                                               |     |     |  ✓  |
| **5.11** | An automated process of identifying component quantity is used                                                               |  ✓  |  ✓  |  ✓  |
| **5.12** | An automated process of identifying component license is used                                                                |  ✓  |  ✓  |  ✓  |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://owasp-scvs.gitbook.io/scvs/v5-component-analysis.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.