Vulnerability analysis: uncover the known risks in open source
1. What we do in this chapter
Using the SBOM, you scan the open source components you depend on for known CVE vulnerabilities. Beyond simply listing them, this chapter also covers assessing severity with CVSS scores and setting response priorities.
In this chapter, the vulnerability-analyst agent automatically generates output/vulnerability/cve-report.md and output/vulnerability/remediation-plan.md. Both documents become the basis for the vulnerability identification, tracking, assessment, and response process required by ISO/IEC 18974.
2. Background knowledge
Why vulnerability analysis is necessary
“The open source you are using may already have known vulnerabilities. What you don’t know is more dangerous.”
The 2021 Log4Shell case (CVE-2021-44228) shows this clearly. Hundreds of millions of systems were vulnerable, and many organizations did not even know they were using log4j. With an SBOM, they could have immediately determined the scope of impact and prioritized their response.
ISO/IEC 18974 makes vulnerability identification a core requirement for three reasons:
- Preventable risk: known vulnerabilities are already registered in the CVE database. There is no excuse for ignoring risks you can find with a simple lookup.
- Free public data: anyone can search the CVE databases (NVD, OSV) for free. This is not a cost issue but a process issue.
- Timing is everything: without a monitoring system, you miss the patch window. Large-scale attacks on Log4Shell began the day it was disclosed.
The tools used
This chapter uses two tools. Both are free, and OSV works out of the box without Docker.
| Tool | Features | How to use |
|---|---|---|
| OSV (osv.dev) | Run by Google, simple queries via API, no installation required | HTTP API |
| Dependency Track | Web UI, SBOM upload, continuous monitoring, dashboard | Docker Compose |
| NVD | Run by the U.S. NIST, the reference for CVSS scoring | Reference database |
Recommended order: search quickly with the OSV API first, then set up continuous monitoring with Dependency Track.
For tool installation and execution commands, see the Install and set up tools page.
Determine vulnerability response priorities
CVSS (Common Vulnerability Scoring System) represents the severity of a vulnerability as a number between 0 and 10. This score determines the response deadline.
The CVSS-severity response-deadline table (the KWG baseline plus a stricter organizational SLA option) and the VEX concept that reduces CVE noise are consolidated in Vulnerability response deadlines and VEX.
This criterion must be documented as a process in output/process/vulnerability-response.md. If you have already completed Chapter 04-process, refer to that document.
Expected results for the sample project exercise
When using samples/java-vulnerable/ as the exercise target:
- Detection: log4j-core 2.14.1
- CVE: CVE-2021-44228 (Log4Shell) — remote code execution via JNDI lookup
- CVSS: 10.0 (Critical) → immediate response required
- Response: upgrade to log4j-core 2.17.1 or later
When using samples/python-mixed-license/ as the exercise target:
- GPL license mixing is detected by license analysis (handled in Chapter 05-1)
- Vulnerabilities still need to be checked separately depending on the package version
3. Self-study
With Dependency Track, the initial startup takes 3-5 minutes and NVD data synchronization takes 10 to 30 minutes. If you go with the OSV API approach first, you will see results immediately.
Check prerequisites:
Chapter 05-1 (Create SBOM) must be complete. First check whether a .cdx.json file exists in the output/sbom/ directory.
ls output/sbom/
# *.cdx.json file must exist
Step-by-step practice:
Step 1 — Verify existence of SBOM file
ls output/sbom/*.cdx.json
If the file does not exist, go back to Chapter 05-1 and create the SBOM first.
Step 2 — Run the vulnerability-analyst agent
Terminate the current Claude session first (/exit or Ctrl+C), then run the command below in a new terminal.
cd agents/05-vulnerability-analyst
claude
Step 3 — Let the agent process automatically
The agent automatically does the following:
- Parses the CycloneDX SBOM files in
output/sbom/ - Queries the OSV API for each component
- Classifies severity based on CVSS score
- Drafts a response plan
Expected output (for java-vulnerable):
[INFO] Load SBOM file: output/sbom/java-vulnerable.cdx.json
[INFO] 4 components found
[INFO] Querying OSV API...
[WARN] CVE-2021-44228 detected: log4j-core 2.14.1 (CVSS 10.0, Critical)
[INFO] Report generation complete
Step 4 — Check cve-report.md
cat output/vulnerability/cve-report.md
It must contain the following:
- A list of detected CVEs (CVE ID, component, version, CVSS, severity)
- A detailed analysis per component
- An impact scope assessment
Step 5 — Check remediation-plan.md
cat output/vulnerability/remediation-plan.md
It must contain the following:
- A prioritized patch plan (Critical → High → Medium → Low order)
- A response deadline for each vulnerability
- A patch version or alternative library
Step 6 — Review the response plan for Critical/High vulnerabilities
Review whether you can actually respond to the detected Critical/High vulnerabilities:
- Does a patched version exist?
- Are there any compatibility issues when applying the patch?
- If immediate patching is not possible, are there mitigations (add a WAF rule, disable the affected feature, etc.)?
Step 7 — (optional) Run Dependency Track
If you want to view the dashboard through the web UI:
# Run from the directory that contains docker-compose.yml
docker compose up -d
# Open http://localhost:8081 and upload the SBOM
Summary of expected results per step:
- After Step 3: terminal output of the CVE search results (for java-vulnerable, includes CVE-2021-44228)
- After Step 4:
cve-report.mdcreated (list of detected CVEs, CVSS scores, impact) - After Step 5:
remediation-plan.mdcreated (prioritized patch plan)
Completing this lab will meet the requirements below:
ISO/IEC 18974
| Item ID | Requirements | Self-certification checklist |
|---|---|---|
| 4.1.5 | vulnerability Response Procedure | Do you have a documented procedure to identify and remediate known vulnerabilities in supply software? |
| 4.3.2 | vulnerability identification and tracking | Do you have a process for identifying, tracking, and remediating known vulnerabilities in supply software? |
4. Completion checklist
You have completed this chapter when all of the items below are met.
-
output/vulnerability/cve-report.mdcreated -
output/vulnerability/remediation-plan.mdcreated - Critical/High vulnerabilities are included in the list (if none, mark it "none")
- Severity is classified based on CVSS score
- A response deadline is specified for each vulnerability
- A patch version or alternative is suggested
Main sections of an example cve-report.md:
## Detected vulnerability summary
| CVE ID | Component | Version | CVSS | Severity | Due Date |
| -------------- | ---------- | ------- | ---- | -------- | --------- |
| CVE-2021-44228 | log4j-core | 2.14.1 | 10.0 | Critical | Immediate |
## Detailed analysis by component
### log4j-core 2.14.1
- vulnerability: Log4Shell — JNDI lookup remote code execution
- Impact: Entire application server
- Patched version: 2.17.1 or later
This step meets ISO/IEC 18974 §4.3.2 requirements.
See the actual format of the generated files at Vulnerability output best practice.
5. Next steps
After completing this chapter, you move on to building your training system.
Terminate the current Claude session first (/exit or Ctrl+C), then run the command below in a new terminal.
cd agents/06-training-manager
claude
When the Claude prompt opens, type 시작.
Or, for the self-study path, go to Training system: raise open source awareness across your organization.
Check progress: you can see the overall percentage complete in the output/progress.md file.
Output status after completion:
output/
├── organization/ completed
├── policy/ completed
├── process/ completed
├── sbom/ completed
├── vulnerability/ completed <- this chapter
└── training/ next