🔒 CONFIDENTIAL — Internal Use Only
Generated by Harness Product Security
Product Security
Security Advisory for Vulnerabilities found in Platform SMP 0.38.0
This advisory summarizes known vulnerabilities in third-party and base-OS components found in container images shipped with the specified Platform SMP version. Data is sourced from internal security scan results and may change as upstream vendors publish updates. Remediation timelines follow Harness SLA policies.
■ Total Findings
1162
0 unique CVEs
⚠ Total Critical
172
0 unique CVEs
▲ Total High
990
0 unique CVEs
⚠ Total SLA Breach Critical
0
0 unique CVEs
▲ Total SLA Breach High
0
0 unique CVEs
Executive Summary
Total Findings
0
Total Critical Findings
0
Total High Findings
0
Total SLA Breached
0
Under SLA
0
Waiting for Vendor Fix
0
Breaking Changes
0
Harness Compliance
?
How is this calculated?
Harness Compliance = CVEs Under SLA + CVEs Waiting for Vendor Fix + CVEs Fixed in Latest Version
These are findings where Harness is either actively remediating within SLA, waiting for an upstream vendor patch, or already fixed in the latest version — all considered compliant.
Under SLA 0
Waiting for Vendor 0
Fixed in Latest 0
Non-compliant 0
Compliant
0%
0 of 0 total
Remediation Status Breakdown
Actionable
0%
Waiting for Vendor
0
no upstream fix
Under SLA
0
within SLA window
Fixed in Latest
0
fixed in latest version
SLA Breached
0
under remediation
Breaking Changes
0
blocked by upstream
Module Breakdown
Top Affected Repositories
Fix Availability
No Fix Available — Critical & High
| CVE | Severity | Package | Repository |
|---|
Total Showing
1162
0 unique CVEs
Total Critical
172
27 unique CVEs
Total High
990
132 unique CVEs
Total SLA Breach Critical
0
0 unique CVEs
Total SLA Breach High
0
0 unique CVEs
Harness Compliance
?
How is this calculated?
Harness Compliance = CVEs Under SLA + CVEs Waiting for Vendor Fix + CVEs Fixed in Latest Version
These are findings where Harness is either actively remediating within SLA, waiting for an upstream vendor patch, or already fixed in the latest version — all considered compliant.
Under SLA 0
Waiting for Vendor 0
Fixed in Latest 0
Non-compliant 0
Compliant
0%
0 of 0 total
Remediation Status Breakdown
Actionable
0%
Waiting for Vendor
0
no upstream fix
Under SLA
0
within SLA window
Fixed in Latest
0
fixed in latest version
SLA Breached
0
under remediation
Breaking Changes
0
blocked by upstream
| Module | Severity | Repository | Tag | CVE | Package(s) | Version | SLA Breach | Comments |
|---|
📊
No Comparison Data Available
The Fix Summary tab shows CVEs that were fixed or newly introduced between two SMP versions.
To enable this comparison, re-run the report and provide the older version’s report for comparison.
🛡
No STIG Data Available
To view STIG compliance results, re-run the report and provide the RapidFort STIG advisory XLSX via
--stig-report.
📈
No History Data Available
To view release trends, re-run the report with
--history-dir pointing to a folder containing SMP-*.xlsx files.
Frequently Asked Questions
What are the SLA timelines for vulnerability remediation?
Harness follows strict remediation SLAs based on severity:
Critical: 30 days from fix availability
High: 60 days from fix availability
Findings exceeding these windows are marked as SLA breached in this advisory.
Critical: 30 days from fix availability
High: 60 days from fix availability
Findings exceeding these windows are marked as SLA breached in this advisory.
How is SLA Breach calculated?
SLA Breach is calculated at the time this report is generated (2026-03-07). For each vulnerability finding that has a fix available, the system checks how many days have passed since the fix was published (Fix Date). If the elapsed time exceeds the SLA threshold for that severity level (30 days for Critical, 60 days for High), the finding is marked as SLA Breached. If the source data already contains an SLA Breach column, those values are used directly. Otherwise, the breach status is computed automatically using the fix date and severity.
How is the data sourced?
Vulnerability data is sourced from container image security scans performed against the specified SMP release. Results reflect the scan-time state and may evolve as upstream vendors issue patches or advisories.
What does "Fix Available" mean?
A vulnerability is considered to have a fix available when the upstream vendor has released a patched version of the affected package. The fix date indicates when the patch was first published. "No fix" means the vendor has not yet released a remediation.
What do the Harness comment statuses mean?
Each CVE in the advisory is triaged by the Harness security team and assigned one of the following comment statuses:
● Fix available. Upgrade planned and within SLA window
An upstream fix exists and Harness has a planned upgrade path. The remediation is on track and will be delivered within the defined SLA timeline (30 days for Critical, 60 days for High). This status is considered compliant.
● Waiting for the vendor to release a fix. No upstream patch available
The vulnerability has no fix released by the upstream vendor yet. Harness cannot remediate until the vendor provides a patch. This is outside Harness's control and is considered compliant — the team is actively monitoring for a vendor release.
● Fix available in latest version
The vulnerability has already been fixed in the latest released version of the software. Customers running the latest version are not affected. This status is considered compliant.
● Breaking changes – fix blocked by upstream, actively being worked on
A fix exists upstream, but applying it introduces breaking changes that require additional engineering effort (e.g., major version bumps, API changes, dependency conflicts). The engineering team is actively working on the remediation. This status is non-compliant and requires attention.
● Under active remediation. Fix deployment aligned with next release cycle
The SLA window has been exceeded and the fix is being actively worked on. Deployment is planned for the next release cycle. This status is non-compliant (SLA breached) but under active remediation.
● Fix available. Upgrade planned and within SLA window
An upstream fix exists and Harness has a planned upgrade path. The remediation is on track and will be delivered within the defined SLA timeline (30 days for Critical, 60 days for High). This status is considered compliant.
● Waiting for the vendor to release a fix. No upstream patch available
The vulnerability has no fix released by the upstream vendor yet. Harness cannot remediate until the vendor provides a patch. This is outside Harness's control and is considered compliant — the team is actively monitoring for a vendor release.
● Fix available in latest version
The vulnerability has already been fixed in the latest released version of the software. Customers running the latest version are not affected. This status is considered compliant.
● Breaking changes – fix blocked by upstream, actively being worked on
A fix exists upstream, but applying it introduces breaking changes that require additional engineering effort (e.g., major version bumps, API changes, dependency conflicts). The engineering team is actively working on the remediation. This status is non-compliant and requires attention.
● Under active remediation. Fix deployment aligned with next release cycle
The SLA window has been exceeded and the fix is being actively worked on. Deployment is planned for the next release cycle. This status is non-compliant (SLA breached) but under active remediation.
How is Harness Compliance calculated?
Harness Compliance measures the percentage of CVEs that are in an acceptable, managed state. A CVE is considered compliant if its comment status is one of:
• Under SLA — fix planned within SLA window
• Waiting for Vendor — no upstream fix available (outside Harness's control)
• Fixed in Latest — already resolved in the latest version
Formula: Harness Compliance % = (Under SLA + Waiting for Vendor + Fixed in Latest) ÷ Total CVEs × 100
The remaining CVEs (Breaking Changes + SLA Breached) are classified as non-compliant and represent findings that need active engineering attention.
• Under SLA — fix planned within SLA window
• Waiting for Vendor — no upstream fix available (outside Harness's control)
• Fixed in Latest — already resolved in the latest version
Formula: Harness Compliance % = (Under SLA + Waiting for Vendor + Fixed in Latest) ÷ Total CVEs × 100
The remaining CVEs (Breaking Changes + SLA Breached) are classified as non-compliant and represent findings that need active engineering attention.