Add Eclipse Foundation June update

alpha/engagements/2026/Eclipse Foundation/update-2026-06.md

@@ -0,0 +1,52 @@
+# Vulnerability Reports Management
+
+### Project Support
+
+This month we continued the day-to-day work of supporting Eclipse Foundation projects through the vulnerability disclosure process. This included receiving incoming reports and handling their intake and triage, routing each to the appropriate project security team, and supporting those teams as they investigated and developed fixes. We also assisted with CVE drafting and publication through coordinated disclosure. This ongoing support remains a core function of our work, and it continued steadily throughout the month.
+
+### Reporting Infrastructure
+
+Building on prior efforts to consolidate report intake and triage, we ran an experiment to evaluate whether GitLab could streamline how project security teams coordinate collaboration and fix development. The aim was to provision a dedicated, embargo-friendly space for each Eclipse Foundation project, with membership automatically synchronized to the project's designated security team so that only authorized members could access and triage incoming reports. To test the approach, we built an automation utility to provision these spaces and set up the supporting pipelines.
+
+The tooling performed as designed: the utility provisions the project subgroups correctly, and the pipelines run as intended. The experiment's real purpose, however, was to validate the approach against actual workflow requirements before committing to it. In doing so, we identified a GitLab constraint around moving issues between subgroups that renders the current design unsuitable for the triage workflow we require. Surfacing this while the work was still exploratory is precisely the outcome such validation is meant to produce.
+
+We have therefore paused this experiment and begun evaluating alternative approaches to streamline our overall vulnerability report intake, triage, and coordinated disclosure process.
+
+# Project Identity Authority (PIA)
+
+### Authentication Hardening
+
+* A critical gap in the OIDC token validation logic was closed this month. Previously, any workflow in a registered GitHub repository could mint an OIDC token that PIA would accept on the project's behalf, including workflows triggered by pull request authors or comment events that do not require write access to the repository. An event\_name allowlist was introduced to restrict token minting to events whose triggers require direct write access, initially `push` and `workflow_dispatch` — ensuring that only maintainers can cause PIA to honor a token ([PR \#51](https://github.com/eclipse-csi/pia/pull/51)).
+
+### CI/CD and Supply Chain Hardening
+
+* Automated static analysis of GitHub Actions workflows was added through integration of zizmor, a tool that identifies common security misconfigurations in workflow files. The analysis runs via a dedicated GitHub Actions workflow and publishes results to GitHub Advanced Security, making findings visible in the repository's security dashboard ([PR \#48](https://github.com/eclipse-csi/pia/pull/48), [Issue \#11](https://github.com/eclipse-csi/pia/issues/11)).
+
+### SBOM Upload API
+
+* The response returned by the SBOM upload endpoint on success was tightened to expose only a `polling_url` pointing to the DependencyTrack token-polling endpoint, rather than relaying the raw DependencyTrack response body. This reduces the API surface by avoiding exposure of internal DependencyTrack details to callers while still giving publishers the information they need to track scan progress ([PR \#47](https://github.com/eclipse-csi/pia/pull/47), [Issue \#42](https://github.com/eclipse-csi/pia/issues/42)).
+
+# Open VSX
+
+### Malware & Zip Security
+
+* Unsafe archive path checking was strengthened in the core registry backend: the `MaliciousZipCheckService` now rejects extensions whose zip entries contain potentially unsafe path names before any further processing occurs, and the `ArchiveUtil.isSafePath` helper was extended with additional unsafe patterns backed by expanded unit test coverage ([PR \#1915](https://github.com/eclipse-openvsx/openvsx/pull/1915)). As a consequence, the safe-path check is now a hard pre-filter, so that the secret-check and blocklist-check services only operate on archives already verified to be structurally safe.  
+* The ClamAV file upload and processing size limits in the production deployment were increased to align with actual extension sizes observed in the registry, eliminating intermittent scan rejections caused by limit mismatches ([PR \#10843](https://github.com/EclipseFdn/open-vsx.org/pull/10843)). The YARA scanning deployment also received a Kubernetes `securityContext` configuration to constrain the process runtime environment, and the YARA rules PVC was corrected back to `ReadWriteOnce` access mode after a staging chart regression ([PR \#11144](https://github.com/EclipseFdn/open-vsx.org/pull/11144)).  
+* On the blocklist front, four separate updates were made to `EclipseFdn/publish-extensions` throughout the month to add newly identified malicious extensions to the block list, on 2 June, 11 June, 15 June, and 22 June respectively.
+
+### Content Security & XSS Hardening
+
+* A significant hardening of HTTP response headers was applied to all endpoints that serve files embedded within extensions ([PR \#1922](https://github.com/eclipse-openvsx/openvsx/pull/1922)). Previously, content types were inferred from file extensions without enforcing any browser-side security policy, opening a path to cross-site scripting via user-controlled content. The fix adds `X-Content-Type-Options: nosniff` to prevent MIME sniffing, applies the strictest possible `Content-Security-Policy` when serving user-controlled input, forces a `Content-Disposition: attachment` header for non-viewable files to prevent inline rendering, and explicitly sets `Content-Type: text/plain` for source-viewable files. This change ships as part of the v1.0.2 release.
+
+### Input Validation & URL Handling
+
+* Bounds validation was added to all paginated API endpoints that accept `size` and `offset` query parameters ([PR \#1892](https://github.com/eclipse-openvsx/openvsx/pull/1892)). Parameters are now rejected if negative, and upper limits of 1,000 for search and query endpoints and 100 for version and admin endpoints prevent unbounded result set requests. A related fix corrected the URL builder in the `Registry` abstraction to properly percent-encode path segments, preventing malformed or injection-prone URLs from being constructed when connecting to the configured upstream registry ([PR \#1893](https://github.com/eclipse-openvsx/openvsx/pull/1893)).  
+* A cache key normalisation fix was applied to ensure namespace and extension names are lowercased before being used as cache keys, matching the canonical form already enforced elsewhere in the codebase and preventing cache poisoning or isolation issues arising from case variations ([PR \#1924](https://github.com/eclipse-openvsx/openvsx/pull/1924)).
+
+### Infrastructure & Secrets Management
+
+* The EKS staging environment was migrated to a new Terraform-managed cluster, dropping the use of static AWS access keys in favour of IAM Roles for Service Accounts (IRSA) ([PR \#11219](https://github.com/EclipseFdn/open-vsx.org/pull/11219)). Alongside this, Elasticsearch password retrieval was refactored to read directly from the ECK-managed secret rather than a separate Secrets Manager copy, eliminating the dual-source drift risk and removing the manual bootstrap step that previously held unencrypted credentials ([PR \#11245](https://github.com/EclipseFdn/open-vsx.org/pull/11245)). PostgreSQL HA passwords in the staging cluster were also pinned via `existingSecret` backed by External Secrets Operator, ensuring credentials are sourced from Secrets Manager rather than Helm-generated values ([PR \#11244](https://github.com/EclipseFdn/open-vsx.org/pull/11244)).
+
+### Production Release
+
+* The v1.0.2 release was deployed to production on 24 June ([PR \#11349](https://github.com/EclipseFdn/open-vsx.org/pull/11349)), incorporating the HTTP security header hardening, the unsafe zip path checks, the input validation improvements, and the cache key normalisation fix described above.