asf-tooling commented on issue #1066:
URL:
https://github.com/apache/tooling-trusted-releases/issues/1066#issuecomment-4409848744
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@2da7807a`
**Type:** `documentation` • **Classification:** `actionable` •
**Confidence:** `medium`
**Application domain(s):** `sbom_analysis`, `shared_infrastructure`
### Summary
This issue requests a documented policy for risk-based vulnerability
remediation timeframes (SLAs by severity). It's explicitly a documentation gap
rather than a code deficiency. The project already has vulnerability detection
infrastructure (OSV scanning in atr/sbom/osv.py, SBOM quality scoring in
atr/tasks/sbom.py), but no written policy defining how quickly detected
vulnerabilities must be remediated. The issue appears to originate from an
automated ASVS L1 audit (references FINDING-306, FINDING-307, section 15.1.1).
There are no human comments or prior discussion.
### Where this lives in the code today
#### `atr/sbom/osv.py` — `scan_bundle` (lines 88-105)
_currently does this_
This is the existing vulnerability detection infrastructure that the issue
acknowledges exists. It scans SBOM components against the OSV database but has
no policy-level remediation tracking.
```python
async def scan_bundle(bundle: models.bundle.Bundle) ->
tuple[list[models.osv.ComponentVulnerabilities], list[str]]:
components = list(bundle.bom.components)
queries, ignored = _scan_bundle_build_queries(components)
if _DEBUG:
print(f"[DEBUG] Scanning {len(queries)} components for
vulnerabilities")
ignored_count = len(ignored)
if ignored_count > 0:
print(f"[DEBUG] {ignored_count} components ignored (missing purl
or version)")
# Reusable HTTP session we can use for all fetches
async with util.create_secure_session(timeout=_API_TIMEOUT) as session:
component_vulns_map = await
_scan_bundle_fetch_vulnerabilities(session, queries, 1000)
if _DEBUG:
print(f"[DEBUG] Total components with vulnerabilities:
{len(component_vulns_map)}")
await _scan_bundle_populate_vulnerabilities(session,
component_vulns_map)
result: list[models.osv.ComponentVulnerabilities] = []
for ref, vulns in component_vulns_map.items():
result.append(models.osv.ComponentVulnerabilities(ref=ref,
vulnerabilities=vulns))
return result, ignored
```
#### `atr/tasks/sbom.py` — `osv_scan` (lines 73-88)
_currently does this_
The task that orchestrates OSV scanning. Detects and reports vulnerabilities
but has no enforcement of remediation timelines.
```python
@checks.with_model(args.FileArgs)
async def osv_scan(args: args.FileArgs) -> results.Results | None:
revision_str = str(args.revision_number)
path_str = str(args.file_path)
base_dir = paths.get_unfinished_dir_for(args.project_key,
args.version_key, args.revision_number)
if not await aiofiles.os.path.isdir(base_dir):
raise SBOMScanningError("Revision directory does not exist",
{"base_dir": str(base_dir)})
full_path = base_dir / path_str
full_path_str = str(full_path)
if not (full_path_str.endswith(".cdx.json") and await
aiofiles.os.path.isfile(full_path)):
raise SBOMScanningError("SBOM file does not exist", {"file_path":
path_str})
bundle = sbom.utilities.path_to_bundle(full_path.path)
if not bundle:
raise SBOMScanningError("Could not load bundle")
vulnerabilities, ignored = await sbom.osv.scan_bundle(bundle)
```
### Where new code would go
- `SECURITY.md` — after ## Supported versions section
Adding a dependency vulnerability remediation policy section to the
existing security policy document keeps all security-related policies
consolidated.
### Proposed approach
Add a 'Dependency Vulnerability Remediation Policy' section to SECURITY.md.
This is the simplest approach since SECURITY.md already serves as the project's
security policy document and is in the repo root where contributors can easily
find it. The section should define severity-based remediation SLAs, document
the emergency override process for critical vulnerabilities, identify high-risk
dependencies, and describe enforcement mechanisms. This avoids needing to
create a new documentation file and update the docs index/build system.
Note: The specific SLA timeframes (48h/7d/30d/90d), high-risk dependency
list, and enforcement mechanisms proposed in the issue body should be reviewed
by the maintainers since they represent project commitments. The diff below is
a starting point based on the issue's recommendation but the actual values need
team agreement.
### Suggested patches
#### `SECURITY.md`
Add dependency vulnerability remediation policy section with risk-based SLAs
as requested in the issue.
````diff
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -39,3 +39,52 @@
## Supported versions
ATR is a continuously deployed service. We address security issues in the
current production version. There are no separately maintained release branches
at this time.
+
+## Dependency vulnerability remediation policy
+
+ATR implements automated vulnerability detection through OSV scanning, SBOM
quality scoring, and pre-commit hooks. This section documents our risk-based
remediation commitments.
+
+### Risk-based remediation timeframes
+
+| Severity | CVSS Score Range | Remediation SLA | Notes |
+|----------|------------------|-----------------|-------|
+| Critical | 9.0 - 10.0 | 48 hours | Emergency patching process available |
+| High | 7.0 - 8.9 | 7 days | Prioritized in sprint planning |
+| Medium | 4.0 - 6.9 | 30 days | Scheduled in regular maintenance |
+| Low | 0.1 - 3.9 | 90 days | Addressed during dependency updates |
+
+### Emergency override process
+
+For Critical vulnerabilities:
+
+1. Security team reviews vulnerability details
+2. If confirmed exploitable, emergency PR created immediately
+3. Expedited review and deployment process initiated
+4. Post-incident review conducted within 7 days
+
+### High-risk dependencies
+
+The following dependencies receive enhanced monitoring due to their
security-critical nature:
+
+- **cryptography**: Used for TLS, HMAC, JWT signing
+- **aiohttp**: Handles all outbound HTTPS connections
+- **jinja2**: Template rendering (XSS risk)
+- **sqlalchemy**: Database operations (SQL injection risk)
+- **pyjwt**: JWT validation (authentication bypass risk)
+
+### Enforcement mechanisms
+
+1. **Automated Detection**: OSV scanning runs against SBOMs for all release
candidates
+2. **Pre-commit Hooks**: pip-audit blocks commits with known vulnerable
dependencies
+3. **SBOM Quality Scoring**: Tracks vulnerability remediation progress per
release
+4. **Regular Audits**: Monthly review of open vulnerability reports
````
### Open questions
- The specific SLA timeframes (48h/7d/30d/90d) need team review and buy-in
before being committed as policy — are these realistic for a volunteer-driven
ASF project?
- The high-risk dependency list in the issue body should be verified against
the actual requirements/pyproject.toml to ensure accuracy (e.g., is pyjwt the
actual package name used?)
- Should this policy apply to ATR's own dependencies only, or also to
dependencies detected in release artifacts being processed by ATR?
- The issue references 'atr/tasks/sbom.py lines 280-350' but the actual
vulnerability scanning code is at lines 148-200 (osv_scan function). This may
indicate the issue was generated from an outdated version or by automated
tooling with inaccurate line references.
- Would the team prefer a separate document in atr/docs/ (which would need
index.md updates and the doc build system) or is SECURITY.md the right location?
### Files examined
- `SECURITY.md`
- `atr/sbom/osv.py`
- `atr/tasks/sbom.py`
- `atr/docs/index.md`
- `atr/docs/developer-guide.md`
- `atr/docs/code-policies.md`
- `atr/docs/how-to-contribute.md`
- `atr/models/results.py`
### Related issues
This issue appears related to: #1132.
_Both address undocumented or missing policy documentation for dependency
and vulnerability management_
---
*Draft from a triage agent. A human reviewer should validate before merging
any change. The agent did not run tests or verify diffs apply.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
