mirror of
https://github.com/azaion/satellite-provider.git
synced 2026-06-21 11:31:14 +00:00
Oleksandr Bezdieniezhnykh
9cfd80babe
AZ-495 (1 SP): formalize the modules-only documentation convention for the WebApi component. _docs/02_document/module-layout.md now carries an explicit Documentation Layout section anchoring WebApi docs at modules/api_program.md; the components/06_web_api/ folder is intentionally absent. .cursor/skills/new-task/SKILL.md Step 4 directs future agents at the correct path. Cycle-1 + cycle-2 F1 findings in the two batch-review files are marked RESOLVED with back-reference to AZ-495. Cycle-2 retrospective decision-item list F1 updated. AZ-496 (2 SP): bump Microsoft.AspNetCore.OpenApi and JwtBearer in SatelliteProvider.Api.csproj from 8.0.21 to 8.0.25, closing CVE- 2026-26130 (SignalR DoS - not reachable in this app, but the runtime patch is the recommended hardening per cycle-1 D1 + cycle-2 D3). SatelliteProvider.Tests.csproj has no direct JwtBearer reference - it consumes JwtBearer transitively via ProjectReference to Api, so no edit needed there. Dockerfiles use floating mcr.microsoft.com/ dotnet/aspnet:8.0 / sdk:8.0 / runtime:8.0 tags which auto-resolve to >= 8.0.25 on rebuild. Security artifacts (dependency_scan.md, security_report.md) and current-state docs (module-layout.md, architecture.md, modules/api_program.md, modules/tests_unit.md) updated to reflect 8.0.25. Batch report + code review report (verdict PASS_WITH_WARNINGS with 2 Low findings, neither blocking) written under _docs/03_implementation. Test suite gate deferred to Step 16 (Final Test Run) per implement skill convention. Patch-level bump within .NET 8 LTS; regression risk very low. Co-authored-by: Cursor <cursoragent@cursor.com>
105 lines
9.0 KiB
Markdown
105 lines
9.0 KiB
Markdown
# Phase 1 — Dependency Scan
|
||
|
||
**Date**: 2026-05-11
|
||
**Method**: Manual inventory from `*.csproj` + targeted advisory search (WebSearch against GHSA / NVD / NuGet ReversingLabs).
|
||
**Reason for manual mode**: `dotnet list package --vulnerable` is on the project's "do not run from agent" list (AGENTS.md — these commands hang in this environment).
|
||
|
||
## Inventory
|
||
|
||
| Project | Package | Version | Notes |
|
||
|---------|---------|---------|-------|
|
||
| Api | Microsoft.AspNetCore.OpenApi | 8.0.21 | ASP.NET Core 8 LTS patch (one behind 8.0.25) |
|
||
| Api | Newtonsoft.Json | 13.0.4 | Latest 13.x |
|
||
| Api | Serilog.AspNetCore | 8.0.3 | |
|
||
| Api | Serilog.Sinks.File | 6.0.0 | |
|
||
| Api | SixLabors.ImageSharp | 3.1.11 | |
|
||
| Api | Swashbuckle.AspNetCore | 6.6.2 | |
|
||
| Common | SixLabors.ImageSharp | 3.1.11 | |
|
||
| DataAccess | Dapper | 2.1.35 | |
|
||
| DataAccess | Npgsql | 9.0.2 | |
|
||
| DataAccess | dbup-postgresql | 6.0.3 | |
|
||
| DataAccess | Microsoft.Extensions.Configuration.Abstractions | 9.0.10 | |
|
||
| DataAccess | Microsoft.Extensions.Logging.Abstractions | 9.0.10 | |
|
||
| TileDownloader | Microsoft.Extensions.Caching.Memory | 9.0.10 | |
|
||
| TileDownloader | Microsoft.Extensions.Http | 9.0.10 | |
|
||
| TileDownloader | Microsoft.Extensions.Logging.Abstractions | 9.0.10 | |
|
||
| TileDownloader | Microsoft.Extensions.Options.ConfigurationExtensions | 9.0.10 | |
|
||
| TileDownloader | Newtonsoft.Json | 13.0.4 | |
|
||
| Tests | coverlet.collector | 6.0.0 | |
|
||
| Tests | FluentAssertions | 8.8.0 | |
|
||
| Tests | Microsoft.Extensions.* | 9.0.10 | (multiple) |
|
||
| Tests | Microsoft.NET.Test.Sdk | 17.8.0 | NuGet.Frameworks transitive CVE flag — see findings |
|
||
| Tests | Moq | 4.20.72 | |
|
||
| Tests | xunit | 2.5.3 | |
|
||
| Tests | xunit.runner.visualstudio | 2.5.3 | |
|
||
|
||
## Findings
|
||
|
||
| # | Severity | Package | Version | Advisory | Disposition |
|
||
|---|----------|---------|---------|----------|-------------|
|
||
| D1 | Medium (production-risk: **Low**, exposure: not reachable) | Microsoft.AspNetCore.OpenApi → ASP.NET Core 8 runtime | 8.0.21 | [CVE-2026-26130](https://github.com/dotnet/aspnetcore/security/advisories/GHSA-4vgm-c2wm-63mw) — SignalR DoS via unbounded buffer | **RESOLVED (cycle 3, AZ-496)**: Bumped to `8.0.25` in `SatelliteProvider.Api.csproj`. Runtime base image already uses the floating `mcr.microsoft.com/dotnet/aspnet:8.0` tag which auto-resolves to ≥ 8.0.25, so deployed image automatically picks up the patched runtime on next build. Original disposition reproduced for traceability: **Not exploitable in this app** (codebase grep for `SignalR\|MapHub\|UseSignalR\|HubConnection` returns zero hits); the bump is hygiene rather than active-CVE closure. |
|
||
| D2 | Low (test-only) | Microsoft.NET.Test.Sdk | 17.8.0 | [CVE-2022-30184](https://github.com/microsoft/vstest/issues/4409) via transitive `NuGet.Frameworks <6.2.1` — information disclosure (CVSS 5.5) | **Not exploitable in production**: package is `IsTestProject=true` only; never shipped. Upgrade to `Microsoft.NET.Test.Sdk` ≥ 17.9.0 (which dropped the `NuGet.Frameworks` dependency entirely) the next time the test project's deps are touched. |
|
||
|
||
## Cross-version sanity (per `coderule.mdc`: keep dependency versions consistent)
|
||
|
||
- `Microsoft.Extensions.*` is uniformly **9.0.10** across DataAccess, TileDownloader, Tests, RegionProcessing, RouteManagement — consistent. ✓
|
||
- `Newtonsoft.Json` is **13.0.4** in both Api and TileDownloader — consistent. ✓
|
||
- `SixLabors.ImageSharp` is **3.1.11** in both Api and Common — consistent. ✓
|
||
- ASP.NET Core meta-package level is at **8.0.21** while extensions are at 9.0.10. The 9.x extensions ship a forward-compatible netstandard2.0 surface and load fine on the .NET 8 runtime — no functional issue, but worth flagging as a minor consistency drift for whoever next bumps the framework.
|
||
|
||
## Items checked clean
|
||
|
||
- SixLabors.ImageSharp 3.1.11 — newer than the patched 3.1.7 / 3.1.5 lines (CVE-2024-41131, CVE-2025-27598). No outstanding GHSA against 3.1.11 itself.
|
||
|
||
---
|
||
|
||
## Cycle 2 Delta (2026-05-11 — AZ-487 / AZ-488)
|
||
|
||
### New packages added this cycle
|
||
|
||
| Project | Package | Version | Notes |
|
||
|---------|---------|---------|-------|
|
||
| Api | `Microsoft.AspNetCore.Authentication.JwtBearer` | 8.0.21 | Added by AZ-487 (JWT validation baseline). Same patch line as `Microsoft.AspNetCore.OpenApi 8.0.21` — see D1. |
|
||
| Services.TileDownloader | `SixLabors.ImageSharp` | 3.1.11 | Added by AZ-488 to identify + decode UAV-supplied JPEGs (`Image.Identify`, `Image.Load<L8>`). Same version as the existing Api-level reference — consistent. |
|
||
| Tests (unit + integration) | `SixLabors.ImageSharp` | 3.1.11 | Added by AZ-488 to generate test fixtures. |
|
||
|
||
### New findings
|
||
|
||
#### D3 — `Microsoft.AspNetCore.Authentication.JwtBearer 8.0.21` shares the same 8.0.21 patch line as the D1-flagged OpenApi package (Low — production-risk: **Low**, exposure: not reachable) — **RESOLVED (cycle 3, AZ-496)**
|
||
|
||
- **Location**: `SatelliteProvider.Api/SatelliteProvider.Api.csproj` (added by AZ-487)
|
||
- **Detail**: D1 already recommends bumping `Microsoft.AspNetCore.OpenApi` to 8.0.25 because the underlying ASP.NET Core 8.0.21 runtime ships CVE-2026-26130 (SignalR DoS, not reachable in this app). Pinning a second package in the same 8.0.21 family in cycle 2 raises the cost of *not* doing the bump: every additional package implicitly hardcodes the runtime expectation. Cycle 1 disposition (`Not exploitable — no SignalR use`) still applies; cycle 2 escalation here is purely about consistency and operator clarity.
|
||
- **Disposition**: Same as D1 — bump *both* `Microsoft.AspNetCore.OpenApi` AND the new `Microsoft.AspNetCore.Authentication.JwtBearer` reference to the latest 8.0.x patch in a single PR. No separate Jira needed; fold into the D1 hardening task.
|
||
- **Resolution (cycle 3, AZ-496)**: Both packages bumped to `8.0.25` in `SatelliteProvider.Api.csproj`. `SatelliteProvider.Tests.csproj` does NOT have a direct `JwtBearer` reference — its JwtBearer usage flows transitively through the `ProjectReference` to `SatelliteProvider.Api`, so the Tests project automatically picks up `8.0.25` as well. No separate edit to Tests.csproj required.
|
||
|
||
#### F-DEPS-UAV — ImageSharp decode now runs on attacker-controlled JPEG bytes (Medium — exposure increase, not a new CVE)
|
||
|
||
- **Location**: `SatelliteProvider.Services.TileDownloader/UavTileQualityGate.cs:60-78` — `Image.Identify(...)` and `Image.Load<L8>(...)` on `ReadOnlyMemory<byte>` originating from `POST /api/satellite/upload`.
|
||
- **Detail**: Pre-cycle-2 the only ImageSharp call site was `GoogleMapsDownloaderV2`, which decodes responses from a known-good origin (Google's tile CDN under our API key). AZ-488 introduces a second call site that decodes **arbitrary client-supplied bytes**. ImageSharp 3.1.11 is patched against the published CVE line (CVE-2024-41131 / CVE-2025-27598 — both pre-3.1.7), so no known-CVE finding exists today. The change is in *exposure*: any future ImageSharp decode bug becomes a remote-attacker primitive on the upload endpoint.
|
||
- **Mitigation already in place** (AZ-488):
|
||
- Rule 1 (magic-byte check) runs *before* ImageSharp touches the bytes, narrowing the input to `FF D8 FF`-prefixed payloads.
|
||
- Rule 2 caps per-item bytes at 5 MiB (configurable); Kestrel + FormOptions cap the envelope at `MaxBatchSize × MaxBytes = 500 MiB`.
|
||
- Decode is wrapped in `try { … } catch (UnknownImageFormatException) { … } catch (InvalidImageContentException) { … }` so a malformed JPEG produces a structured `INVALID_FORMAT` reject, not an unhandled exception.
|
||
- **Disposition**: Accept for cycle 2 — the mitigations align with current best practice for "decode untrusted images" surfaces. Track as recurring follow-up:
|
||
- Subscribe to GHSA advisories for `SixLabors.ImageSharp` and bump aggressively (within 7 days of a patch).
|
||
- Re-evaluate whether to sandbox the decode (e.g. dedicated process pool, libvips with seccomp) the next time the upload trust boundary changes.
|
||
|
||
### Cross-version sanity (post-cycle-2)
|
||
|
||
- `SixLabors.ImageSharp` is **3.1.11** in Api, Common, Services.TileDownloader, Tests, IntegrationTests — consistent across 5 csprojs. ✓
|
||
- `Microsoft.AspNetCore.*` 8.0.21 in OpenApi + the new JwtBearer — consistent within the family but lagging one patch (8.0.25 is current). Cycle-2 D3 + cycle-1 D1 share remediation.
|
||
- No new Newtonsoft.Json / Npgsql / Dapper changes this cycle.
|
||
- Newtonsoft.Json 13.0.4 — past CVE-2024-21907 fix line (13.0.1).
|
||
- Npgsql 9.0.2 — outside the 4.x / 5.x / 6.x / 7.x / 8.x ranges affected by CVE-2024-32655 (SQL injection via protocol message size overflow). 9.0.x line was never affected.
|
||
- Dapper 2.1.35 — only "advisory" hit was a dependency-check false positive for SQLite CVE-2017-10989; not a Dapper issue.
|
||
- Swashbuckle.AspNetCore 6.6.2 — no published GHSA / CVE.
|
||
- Serilog.AspNetCore 8.0.3 — no published GHSA / CVE.
|
||
- dbup-postgresql 6.0.3 — no published GHSA / CVE.
|
||
|
||
## Self-verification
|
||
|
||
- [x] All package manifests scanned (8 csproj files)
|
||
- [x] Each finding has a CVE ID or advisory reference
|
||
- [x] Upgrade paths identified for every Medium/Low finding
|
||
- [x] No Critical or High finding remains open after exploitability triage
|