andrewmusselman commented on issue #23: URL: https://github.com/apache/tooling-agents/issues/23#issuecomment-4491522997
@potiuk L1 run https://github.com/apache/tooling-agents/tree/main/ASVS/reports/airflow/airflow-core/41a6436 All 11 PRs from the prior L1 + L3 triage are merged ✅ (#66500, #66501, #66502, #66503, #66504, #66505, #66556, #66557, #66562, plus the Kerberos ccache and production-shaped warning PRs). None of those themes re-surface in this run. For this batch, my read of the 10 — happy to be wrong on any of these: **Looks actionable (7)** | # | Theme | Notes | |---|---|---| | F-002 | Unbounded `dag_runs_limit` | `Query(le=100)` one-liner in `routes/ui/dags.py` | | F-003 | Unbounded `run_ids` list | `Query(max_length=100)` companion to F-002 in `routes/ui/grid.py` | | F-004 | Markdown links missing `rel="noopener noreferrer"` | Small DOM-hardening change to `ReactMarkdown.tsx` | | F-005 | `mapIndex` URL-encoding inconsistency | Matches how `dagId`/`runId`/`taskId` are already handled in `Iframe.tsx` | | F-006 | JWKS URL mode lacks explicit algorithm allowlist | Defense-in-depth against JWKS endpoint compromise; default to `["RS256", "EdDSA"]` | | F-008 | `import_string` lacks subclass check on exception/trigger deserialization | Marginal — the audit's own description cites the trusted-DAG-author model. Small `issubclass` guard is reasonable defense-in-depth, but easy to argue either way | | F-010 | `DagRun.set_state()` no transition validation | Internal state-machine hygiene | **Should not have made it past the relevance filter (3)** | # | Theme | Why it shouldn't have been raised | |---|---|---| | F-001 | Bulk per-user session termination on disable/delete (ASVS 7.4.2) | **Regression** — this is the same as old L1 F-006, which you triaged as the external IdP's responsibility. The audit_guidance isn't capturing the "production uses FAB/Keycloak; IdP owns user lifecycle" stance. Marked High in this run, which makes it worse. | | F-007 | No cookie security configuration (ASVS 3.3.1) | The finding itself states *"Finding is speculative — no cookies are actually set in the analyzed code."* Coverage gap on a feature that doesn't exist on this surface — Bearer tokens go in the Authorization header. | | F-009 | No client-side storage cleanup on session terminate (ASVS 14.3.1) | The finding itself states *"no authenticated data (tokens, credentials) is stored in browser-accessible storage — only UI preferences."* Nothing to clear; same category as the L3 deployment-manager findings you previously triaged out. | I'm adding two new audit guidance files to catch these in future runs: - `external_auth_manager_credential_lifecycle.md` — production credential lifecycle (session termination on user disable, MFA, password rotation, lockout) is the external auth manager's responsibility, scoped against `security_model.rst` and `jwt_token_authentication.rst`. Covers F-001's category. - `airflow_ui_bearer_token_no_cookies.md` — UI uses Bearer tokens; no auth cookies on the core API surface; no auth data in client storage. Covers F-007 and F-009. Carves out the legitimate cookies (SimpleAuthManager dev login, JWTRefreshMiddleware refresh token) so real cookie-attribute findings on those flows are still in scope. If the new guidance reads accurately to you I'll keep both. If the framing is off let me know and I'll adjust before next run. One housekeeping note: this run's report shows `Commit | N/A` in the header — same on the recent task-sdk run. Looking into the orchestrator to make sure the commit hash gets wired through; reports without a commit hash aren't reproducible. Two threads still hanging on this issue: - The L3 follow-up from 4 days ago on commit 508d7fd ("looks like it needs more work fyi") — I'll re-run L3 with the new guidance files applied so we can close that one out. - Your triage on the 7 actionable findings above. -- 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]
