ci: gate releases on CVEs and unify Dependabot, Trivy and Docker Scout (PER-15358)

[EliMoshkovich]

Linear: PER-15886 · umbrella PER-15358

#337 cleared the 12 CVEs a customer found in permitio/pdp-v2:0.9.14. This PR closes the holes that let them reach a customer before they reached us, and then gives all three scanners — Dependabot, Trivy, Docker Scout — a consistent gate, report and alert.

---

⚙️ Required setup — read this first

Four things must be configured or parts of this PR are inert or actively broken. Items 1 and 2 are not optional; 2 fixes a live defect.

1. SLACK_WEBHOOK_URL — repository Actions secret

Every Slack path in this PR is a green no-op until this exists. It merges and runs green either way, printing ::notice::SLACK_WEBHOOK_URL is not set; skipping Slack notification. — so a green notify job proves nothing on its own. Open it and look for that annotation.

Create an incoming webhook in Slack, then:

gh secret set SLACK_WEBHOOK_URL --repo permitio/PDP --body 'https://hooks.slack.com/services/T…/B…/…'

Or: Settings → Secrets and variables → Actions → New repository secret. It starts posting the day the secret appears, with no workflow edit. The name matches the org convention (36 uses across permitio repos).

2. Dependabot secret store — fixes a live defect

Dependabot-triggered runs read only the Dependabot secret store, which is currently empty (gh api repos/permitio/PDP/dependabot/secrets → total_count: 0). So on every Dependabot PR today, build-pdp-image clones the private permitio/permit-opa with an empty token, dies, and takes pdp-tester and docker-scout with it via needs:. The image CVE gate does not run on the PRs it exists for.

These are the same values already in the Actions store — they must be duplicated, not moved:

gh secret set CLONE_REPO_TOKEN   --app dependabot --repo permitio/PDP
gh secret set DOCKERHUB_USERNAME --app dependabot --repo permitio/PDP
gh secret set DOCKERHUB_TOKEN    --app dependabot --repo permitio/PDP

Or: Settings → Secrets and variables → Dependabot.

3. Repository label dependencies

.github/dependabot.yml sets labels: ["dependencies"] on all five ecosystems. The repo has only the nine GitHub defaults, and specifying labels suppresses the defaults — so Dependabot PRs currently arrive with no labels at all.

gh label create dependencies --repo permitio/PDP --color 0366d6 --description "Dependency updates"

4. Dependabot security updates — repo setting, not a file

Currently disabled (gh api repos/permitio/PDP --jq .security_and_analysis). This PR configures version updates only; security updates are the leg that opens PRs for known advisories.

gh api -X PUT repos/permitio/PDP/automated-security-fixes

Not required, but do it once after merge

workflow_dispatch the scan to confirm Docker Scout resolves registry://permitio/pdp-v2:latest to the PURL pkg:docker/permitio/pdp-v2@latest. Docker's docs say it does; if it doesn't, all 7 OpenVEX waivers stop suppressing and you get alerted about already-triaged CVEs every run.

gh workflow run scheduled-security-scan.yml --repo permitio/PDP

Nothing else is needed

No GitHub App, no PAT, no bot credentials. GITHUB_TOKEN covers everything, including the Dependabot alerts API via vulnerability-alerts: read. There are deliberately no auto-PRs, so no push-capable token is involved.

---

Part 1 — why we heard this from a customer

We already ran a Docker Scout CVE gate. It didn't help, for two independent reasons.

1. A build-time gate can't protect a shipped image. The gate passed on 2026-08-04 and was the last word on that tag forever. Alpine published openssl 3.5.8-r0 afterwards. Every CVE disclosed after the build was invisible by construction. The image wasn't broken — it had rotted on the shelf.

2. Releases skipped the gate entirely.

docker-scout:
  if: github.event_name == 'pull_request'   # releases are not pull_request

release.yml reaches tests.yml via workflow_call, where github.event_name is the caller's event — release. Verified empirically rather than from the YAML: the actual 0.9.14 release run (30900950607) shows pdp-tests/docker-scout SKIPPED alongside build-and-push-pdp success. Same on 0.9.13. The gate landed 2026-03-24 in #304 and every release since went out ungated.

Removing that condition fixes it. build-and-push-pdp already declares needs: pdp-tests, so a failing gate now blocks the push.

Part 2 — what each scanner does now

	PR gate	Scheduled alert	Release gate
Trivy	blocks, in the sticky comment	published tags, in the shared digest	scans the shipped tag by digest, both platforms
Docker Scout	blocks, same comment	latest, same digest	same job
Dependabot	new dependency-review job	alerts API poll, same digest	—

PR gate and report

The Trivy step moves from exit-code: 1 to scan-to-JSON → format → a separate fail step, so findings exist as a file and can be reported rather than living only in a step log. The gate does not weaken: severity, trivyignores, ignore-unfixed and vuln-type carry over byte-identical, so critical + high > 0 is the old predicate evaluated two steps later — plus three report-unreadable failure modes the old exit code could not express.

One sticky comment per PR, marker <!-- pdp-image-scan -->, covering Trivy and Scout together. Scout's own write-comment goes to false on both steps, so a PR gets at most two bot comments instead of three. Guarded for fork and Dependabot PRs (read-only token there), with $GITHUB_STEP_SUMMARY and one ::error:: per finding as fallbacks.

dependency-review is new: it gates the dependency diff at fail-on-severity: high and posts its own comment on-failure, so a clean PR shows nothing. The repo is public, so the dependency graph is free and this needs no GHAS.

One schedule, one message

scheduled-security-scan.yml runs all three scanners as parallel jobs on 17 6 */3 * * (every third day) and a digest job merges them into one Slack message:

*Trivy* - 2 published tag(s): 1 clean, 1 not clean.
  • permitio/pdp-v2:latest -> SOURCE (3 findings: 1 CRITICAL, 2 HIGH)
  • permitio/pdp-v2:v0.9.15 -> CLEAN
*Docker Scout* - found 3 unwaived CRITICAL/HIGH finding(s) in permitio/pdp-v2:latest...
*Dependabot* - 1 new unwaived CRITICAL alert: CVE-2026-99999 in requests.

They ran on separate crons at first, each sending its own message, so one CVE produced three notifications on the same morning — three scanners agreeing, which reads as three problems. The digest keys each scanner on its job result, not its finding count: Scout exports a body on the clean path too, so the body alone cannot tell "the gate passed" from "the gate never ran", and a scanner that did not run must never read as clean. status only escalates ok → warn → fail, so a clean Dependabot result cannot talk down a Trivy SOURCE verdict.

*/3 in the day-of-month field means days 1, 4, 7 … 31 and resets each month, so the 31st→1st gap is one day. Cron has no true "every 72 hours". Both directions are bounded: a short gap only overlaps the window and may repeat an alert once; a long gap cannot occur.

The Dependabot filter is load-bearing

All three currently-open HIGH alerts — CVE-2026-50271 (ddtrace), CVE-2026-54283 and CVE-2026-48818 (starlette) — are CVEs already waived in .trivyignore.yaml and the VEX doc. An unfiltered feed would repeat the same three every run until the channel was muted, and then the alert that matters arrives in a muted channel.

Verified against the live feed: 6 open → 3 at critical/high → 0 reported, 3 recognised as waived. A control run with the waiver set emptied reports exactly those three, so the zero is the filter working, not a dead code path. Consequence worth knowing: adding a waiver also silences its Dependabot alert.

There is no dependabot_alert workflow trigger, so this leg is a poll. It reports a delta over a 73-hour window (72 + 1h overlap) and the standing backlog, so a scheduled run GitHub drops does not lose that day permanently.

Release gate

New verify-published-image job scans the tag that actually shipped, by digest, per platform — the only place linux/arm64 is ever scanned, since tests.yml builds amd64 only and no-cache-filters: main means the pushed build re-resolves packages and can genuinely differ from the one the gate passed. update-pdp-api-ecs-service now lists it in needs:, so an unwaived CRITICAL/HIGH in a freshly published image stops the rollout. It runs after the push, so it cannot un-publish the tag; what it prevents is rolling that image to the fleet.

Part 3 — supporting changes

• Base images pinned by digest. Upstream rebuilds tags in place; python:3.13-alpine3.23 silently gained a new digest with patched OpenSSL between 0.9.14's build and the customer's scan, and because the tag string never changed there was nothing for a human or a bot to notice. Pinning inverts that into a Dependabot digest-bump PR. Costs no package freshness — apk upgrade still floats the Alpine set at build time.
• Dependabot config where there was none: pip, cargo, github-actions weekly; docker / daily (the 0.9.14 signal); docker /test_offline_mode weekly. Documented ignore entries with removal gates for starlette/ddtrace (capped by opal-common, so a bump PR is unmergeable) and websockets majors.
• .trivyignore.yaml — Trivy counterpart to the OpenVEX doc. Every entry carries expired_at, so a waiver cannot silently become permanent. Parity gap closed 5 → 7 (CVE-2026-48710, CVE-2026-48817 were VEX-only) and now enforced by a waiver-parity pre-commit hook rather than a comment.
• classify_image_cves.py fails closed. A zero-byte report was reported as CLEAN with exit 0; it now exits 2 with verdict=ERROR. It splits a case that "a fix exists" hides: /app/bin/opa is compiled from permit-opa, so a grpc or x/crypto CVE needs a go.mod bump in that repo and no release here can clear it.
• format_scan_report.py, check_waiver_parity.py, check_dependabot_alerts.py — 81 tests in horizon/tests/, which is the path the required pytests job actually runs.
• notify-slack.yml — reusable notifier, a green no-op until the secret exists, and it reports its own delivery failures (errors: true plus an exported delivery outcome, because continue-on-error alone makes a dead webhook invisible).
• The rolling [image-cve] GitHub issue is removed, not deprecated. Slack replaces it.
• PyYAML declared — it was reaching a required check only via uvicorn[standard].
• docs/image-vulnerability-management.md — the posture, a tested triage runbook, a known-good image reference, and the gaps deliberately left open.

Verification

• actionlint: 8 findings, all pre-existing — zero introduced, one cleared vs the baseline.
• zizmor: clean on every new workflow; 17 pre-existing findings cleared across the branch.
• 81 tests pass; every mutation applied during review was caught.
• pre-commit run --all-files: all 17 hooks pass.
• All 10 action pins re-resolved live against the API — zero version comments that disagree with their SHA. (An earlier revision shipped docker/scout-action # v1.24.0 on a v1.20.4 SHA; corrected.)
• Gate strength re-derived independently by extracting the real run: bodies and driving them over 13 fixtures; the merged digest over 12 more. Both scanners' gates confirmed running and reporting on the same CI run.

Known gaps, documented rather than fixed

• dependency-review is a third waiver surface that does not read .trivyignore.yaml, so a PR touching the starlette or ddtrace pins can be failed on an already-waived advisory. check_waiver_parity.py covers 2 of 3 surfaces.
• All 7 waivers expire 2026-12-31 together. Trivy prunes an expired entry, so every PR would go red the same morning. security-digest.yml warns 30 days ahead — that weekly roll-up is the only thing looking past that date.
• No Python lockfile. The root reason GitPython could drift in. Highest-value structural fix outstanding.
• No auto-rebuild cadence, no image signing, no SBOM publication. Deliberate; the reasoning is in the doc.
• security/snyk (permit) returns a quota error on every recent PR — broken integration, not a finding.

Related: permitio/permit-opa#49 (merged), permitio/permit-opa#50, permitio/opal#957.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VvR24Cibs2Z8cVsEqkp3Es

[linear-code]

PER-15358

PER-15886

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:9a55b612b2a629439eb020d066d2fee7c7460c37d95bbd4bea4aafd43c496697
vulnerabilities
platform	linux/amd64
size	139 MB
packages	247

📦 Base Image python:3.13-alpine3.23

also known as	3.13.15-alpine3.23 b3fdbd3f0fb569f6c053a23e74b6e99a856bf9efe5823bca837a80a875ee7a9f
digest	sha256:c694844958d415b76979bb3e0927273b013294ab36e715ca1fc4962713a8ee69
vulnerabilities

starlette 0.50.0 (pypi) pkg:pypi/starlette@0.50.0 Allocation of Resources Without Limits or Throttling Affected range >=0.4.1 <1.3.1 Fixed version 1.3.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.397% EPSS Percentile 33rd percentile Description Summary request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. Details request.form() dispatches to a different parser depending on the Content-Type. For multipart/form-data the max_files, max_fields, and max_part_size limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no max_fields or max_part_size parameter to receive them, and it appends every field with no count check and accumulates each field's name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies. Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects: Field count drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as f0=v&f1=v&...) blocks the worker's event loop for several seconds while parsing, during which the worker serves no other request. Field size drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the FormData, forcing memory allocation proportional to the request body. The equivalent multipart/form-data request is correctly rejected with 400 Too many fields / 400 Field exceeded maximum size. Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) that call request.form() on application/x-www-form-urlencoded requests. A single request with a very large number of fields blocks the event loop for several seconds, and a single request with a very large field forces unbounded memory allocation; in either case, parallel requests can render the service unusable. A reverse proxy that enforces a request body size limit reduces but does not eliminate the exposure, since a sub-10MB body is already enough to block the event loop. Mitigation Upgrade to a patched version, which forwards max_fields and max_part_size to the url-encoded parser and enforces them while parsing, raising before the oversized field or excess fields are accumulated. The defaults match multipart/form-data (max_fields=1000, max_part_size=1MB) and can be customized via request.form(max_fields=..., max_part_size=...). Server-Side Request Forgery (SSRF) Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.368% EPSS Percentile 30th percentile Description Summary When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts. Details StaticFiles.lookup_path() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected. This only affects the default configuration (follow_symlink=False), which uses os.path.realpath. The follow_symlink=True branch uses os.path.abspath, which performs no I/O. Impact Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses. Mitigation Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved. Improper Validation of Unsafe Equivalence in Input Affected range <=1.0.0 Fixed version 1.0.1 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N EPSS Score 36.257% EPSS Percentile 98th percentile Description Summary In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed. Details When a client requests http://example.com/foo, it sends: GET /foo HTTP/1.1 Host: example.com Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example: GET /foo HTTP/1.1 Host: example.com/abc?bar= reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed. Impact Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere. Mitigation Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values. Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.213% EPSS Percentile 12th percentile Description Summary When dispatching a request, HTTPEndpoint selects the handler by lowercasing the HTTP method and looking it up as an attribute with getattr, without restricting the lookup to a known set of HTTP verbs. When an HTTPEndpoint subclass is registered through Route(...) without an explicit methods= argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. Details HTTPEndpoint uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as _DO_DELETE therefore resolves an attribute like _do_delete and invokes it. Non-standard methods are valid RFC 9110 token methods, so an endpoint must not treat the method name as a trusted attribute selector. Impact An application is affected when all of the following hold: It defines an HTTPEndpoint subclass and registers it via Route(...) without an explicit methods= argument. The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single request argument and return a response. This also affects frameworks built on Starlette, like FastAPI. Mitigation Register HTTPEndpoint subclasses with an explicit methods= argument on the Route, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with 405 Method Not Allowed before it reaches the endpoint, so non-standard methods cannot resolve an attribute. Improper Input Validation Affected range <1.3.0 Fixed version 1.3.0 CVSS Score 3.7 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @<!-- -->google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. Details When a client requests a path that does not start with /: GET @<!-- -->google.com HTTP/1.1 Host: localhost affected versions reconstruct the URL as http://localhost@<!-- -->google.com. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path: request.url == "http://localhost@<!-- -->google.com" request.url.hostname == "google.com" request.url.path == "" The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host header was validated when constructing request.url; the path was not. This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"]. Impact Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first. Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@<!-- -->google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers. Mitigation Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@<!-- -->google.com with request.url.hostname == "localhost".

golang.org/x/crypto 0.55.0 (golang) pkg:golang/golang.org/x/crypto@0.55.0 Affected range <0.56.0 Fixed version 0.56.0 EPSS Score 0.315% EPSS Percentile 24th percentile Description Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every packet other than the open confirmation/failure, without blocking and without tearing down the connection. Affected range <0.56.0 Fixed version 0.56.0 EPSS Score 0.378% EPSS Percentile 31st percentile Description Previously, after a channel has been established, a malicious peer could send crafted messages that would deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of buffering and blocking. Affected range >=0 Fixed version Not Fixed Description The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.

ddtrace 3.19.8 (pypi) pkg:pypi/ddtrace@3.19.8 Uncontrolled Resource Consumption Affected range <4.8.2 Fixed version 4.8.2 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.793% EPSS Percentile 54th percentile Description Impact Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed. Patches This is resolved in version 4.8.2 and later of the dd-trace-py library Workarounds If users cannot upgrade immediately: Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently). Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb). Resources Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j

github.com/containerd/containerd/v2 2.2.5 (golang) pkg:golang/github.com/containerd/containerd/v2@2.2.5 Uncontrolled Resource Consumption Affected range >=2.2.0 <2.2.8 Fixed version 2.2.8 CVSS Score 6.8 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.193% EPSS Percentile 9th percentile Description Impact A bug in containerd's CRI ExecSync implementation allows exec probes and lifecycle hooks with background child processes to keep containerd's stdio-drain goroutines indefinitely blocked. Because the I/O drain phase lacks a default timeout or context cancellation handling, repeated ExecSync invocations (like probes) that include long-lived background processes against a container can cause containerd to leak goroutines and host memory. Over time, this resource exhaustion can cause the containerd daemon to be terminated by the OOM killer, rendering containerd unavailable until it is restarted. This issue affects containerd on Linux systems running with the CRI plugin enabled. Users not using containerd's CRI implementation or not running containers on Linux are not affected. Patches This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue. Workarounds Ensure exec probes and lifecycle hooks do not launch long-lived background child processes. Credits The containerd project would like to thank XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com), including Guannan Wang, Zhanpeng Liu, Jiashuo Liang, and Guancheng Li, and @IamwhatIamSY who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If there are any questions or comments about this advisory: Open an issue in containerd Send an email to [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: Report a new vulnerability Send an email to [security@containerd.io](mailto:security@containerd.io)

busybox 1.37.0-r30 (apk) pkg:apk/alpine/busybox@1.37.0-r30?os_name=alpine&os_version=3.23 Affected range <=1.37.0-r30 Fixed version Not Fixed EPSS Score 0.291% EPSS Percentile 22nd percentile Description

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:9a55b612b2a629439eb020d066d2fee7c7460c37d95bbd4bea4aafd43c496697
vulnerabilities
platform	linux/amd64
size	139 MB
packages	247

📦 Base Image python:3.13-alpine3.23

also known as	3.13.15-alpine3.23 b3fdbd3f0fb569f6c053a23e74b6e99a856bf9efe5823bca837a80a875ee7a9f
digest	sha256:c694844958d415b76979bb3e0927273b013294ab36e715ca1fc4962713a8ee69
vulnerabilities

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

PDP image vulnerability report

Image: permitio/pdp-v2:next

✅ No CRITICAL or HIGH findings after waivers.

Trivy

No CRITICAL or HIGH findings.

Docker Scout

No CRITICAL or HIGH findings.

---

Scanned by Trivy, Docker Scout. Waivers: .trivyignore.yaml + .docker/scout/pdp-v2.vex.json. View run