Security Analysis

Security Analysis

Overview

Structured process for triaging Dependabot alerts, grouping related vulnerabilities, applying severity rules, and producing actionable reports for HASTE's Python and JavaScript dependency stacks.

Key Concepts

HASTE Dependency Landscape

| Stack | Location | Tool | Key Risks |

|-------|----------|------|-----------|

| Python (API) | api/hastefuncapi/requirements.txt | pip audit | GDAL parsing, Azure SDK, rasterio |

| Python (Queues) | api/hastefuncqueues/requirements.txt | pip audit | Same as API |

| Python (Core) | hastelib/pyproject.toml | pip audit | Geospatial libs, ML deps |

| JavaScript (UI) | ui/package.json | npm audit | FluentUI, MSAL, build tools |

| JavaScript (Root) | package.json | npm audit | Azurite (dev only) |

Severity Rules

| Severity | Action | SLA |

|----------|--------|-----|

| Critical | Investigate immediately, create issue | Same day |

| High | Investigate promptly, create issue | 3 business days |

| Medium | Queue for next sprint | Next sprint |

| Low | Document and track | Backlog |

Patterns & Techniques

Alert Triage Process

Step 1: Gather alerts

# Python
pip audit --format json

# JavaScript
npm audit --json

Step 2: Group related vulnerabilities

• Same package, different CVEs → group together
• Same dependency chain → note the root cause package
• Transitive vs direct dependency → prioritize direct

Step 3: Assess HASTE impact

For each vulnerability, determine:

• Is the vulnerable code path reachable in HASTE?
• What data is at risk? (imagery, project metadata, user data)
• Is this in a production path or dev-only dependency?
• Can the vulnerability be exploited through HASTE's public interfaces?

Step 4: Produce report

## Security Triage Report — [Date]

### Critical/High Findings
| Package | CVE | Severity | Component | Reachable? | Action |
|---------|-----|----------|-----------|------------|--------|

### Medium/Low Findings
| Package | CVE | Severity | Component | Action |
|---------|-----|----------|-----------|--------|

### Dependencies to Watch
[Packages with recent churn, new maintainers, or declining activity]

HASTE-Specific Risk Areas

| Area | Why It Matters |

|------|---------------|

| GDAL/rasterio | File parsing vulnerabilities — common attack vector for malicious GeoTIFFs |

| Azure SDKs | Auth and credential handling — high-value targets |

| MSAL | Token handling and auth bypass — directly affects user security |

| boto3 | AWS S3 access for imagery sources — credential exposure risk |

| opencv-python | Image processing vulnerabilities — similar to GDAL risks |

Decision Framework

| Scenario | Action |

|----------|--------|

| Critical CVE in production dependency | Immediate triage, create issue, recommend upgrade |

| High CVE in production dependency | Investigate within 3 days, create issue |

| Any CVE in dev-only dependency (azurite, vite, eslint) | Document, lower priority |

| Upgrade introduces breaking changes | Document migration steps, flag for planning |

| No fix available | Document workaround or risk acceptance rationale |

Common Pitfalls

• Treating all alerts equally — Production critical > production high > dev-only
• Ignoring transitive dependencies — A safe direct dep can pull in vulnerable packages
• Auto-upgrading without testing — Always run hatch run test:pytest after upgrades
• Assuming dev-only deps are safe — Supply chain attacks can target build tools