Triage the 104 dependency alerts that became visible when the graph was enabled

Start by reviewing the shared Renovate preset, the repositories' lockfiles, and .github/workflows/codeql.yml to understand the existing automation. Triage the Dependabot and Scorecard findings, document the blocked cryptography advisory, apply feasible dependency updates, and add weekly lock-file maintenance. Done means the critical alerts and reachable high-impact findings have an explicit resolution or tracking decision.

What happened

A sweep of the org's security alerts found that the dependency graph produced zero manifests on six of eight repos, and Dependabot alerts were hard-disabled (HTTP 403) on python-package-copier and yohou-nixtla. Four more repos reported hasVulnerabilityAlertsEnabled: true while having nothing to scan — so "0 open alerts" measured nothing.

Meanwhile Scorecard's OSV scan, which reads the lockfiles directly, was reporting 72 vulnerabilities for kedro-azureml-pipeline and 13 for sklearn-optuna. Those numbers were correct; Dependabot just couldn't see them.

The org security configuration stateful-y baseline now enables dependency graph, Dependabot alerts, Dependabot security updates, secret scanning and push protection on all eight repos, and is the default for new repositories. (Code scanning default setup is deliberately not_set — every repo runs CodeQL from .github/workflows/codeql.yml, and default setup would override it and start rejecting the advanced workflow's uploads.)

The backlog that appeared

Open Dependabot alerts went from 3 to 107.

Malware: zero. All 83 distinct advisories classify as GENERAL via the GraphQL SecurityAdvisory.classification field. This is the first time that question has been answerable on six of these repos.

The four criticals, all in kedro-azureml-pipeline, all runtime

kedro-azureml-pipeline holds 77 of the 107 and every critical. It is the obvious place to start.

Known-blocked, do not spend time on it

cryptography (GHSA-g6cj-pr64-35w5, Bleichenbacher oracle in PKCS#7 EnvelopedData) affects kedro-dagster (48.0.1) and kedro-azureml-pipeline (46.0.5). The patch is 50.0.0 and it is unreachable: mlflow requires cryptography<50, azureml-mlflow requires <49.

Neither package uses PKCS#7 EnvelopedData — cryptography is pulled in for TLS and JWT — so the reachable action is a documented dismissal plus tracking the mlflow cap, not a lockfile change. kedro-azureml-pipeline can still move 46.0.5 → 48.x, which does not clear the advisory but closes the gap to its own ceiling.

Structural gap worth fixing alongside

The shared Renovate preset has no lockFileMaintenance, and config:recommended does not enable it. pymdown-extensions reached the lockfiles transitively via mkdocs-material, and nothing was configured to refresh it — which is part of why a known-vulnerable version sat in five repos. Adding lockFileMaintenance on the existing weekly schedule would stop transitive lock entries aging silently.