Whoobe Docsv0.3.3

Security results: v0.3.2 (patch of Operate: the publisher image)#

Recorded on 2026-10-27 from the public CI history, the reports of the runs and a check of the published images. Rules: README.md. Written after the release was published (2026-10-26, 23:03 UTC), not before as rule 3 asks; the runs and checks below were all done before publication, only this record came later.

What was run, and on which commit#

Release commit (tag v0.3.2) 57b9a1f, 2026-10-27
Commit the full security run was made on 9fa13d4 ("Release notes 0.3.2; documentation for the publisher change (F-063)"), one commit before the release commit
What differs between the two the version number in 21 package.json files, the release entry of CHANGES.md and the alignment line of docs/release/README.md. No code.
The run workflow security, started by hand with the DAST scan ticked: run 40400621940, 2026-10-26, 21:00 UTC
Result all jobs succeeded
The run on the release commit itself push run 40409761479: success (only the static scans ran: the commit changes no code)
Other runs on the tag upgrade 40409761383 (v0.3.1 to this tree): success; release 40409761657 (six images for amd64 and arm64, cosign signature, build provenance, draft release): success
The fix itself, on its branch run 40397598269 on fix/publisher-image-scan (68b521d, by hand): success
Job What it does Result
static scans dependency audit, secret scan of the tree and of the history, static analysis, shell lint, container and infrastructure configuration success (the accepted findings are in scripts/security/static/baseline.json, each with a reason and a review date)
API + browser suites on a disposable stack the API security suites, the unit tests, the browser tests, and the scan of the stack's images success
workspace isolation (two stacks) two workspaces started side by side; one must not reach the other success
DAST (OWASP ZAP) active scan of the running stack success
TLS template (testssl.sh), two nginx images the TLS policy of the rendered proxy configuration success (both images)

Counts, read from the reports of run 40400621940 (commit 9fa13d4): API suites 2341 passed, 0 failed, 2 skipped (93 test files; four more than 0.3.1: the publisher tests publish-sdk-tarballs and publish-runner); browser tests 56 passed, 0 failed, 5 skipped; isolation 14 passed, 0 failed.

The static report lists as warnings that do not fail the run the four semgrep hits named in the 0.3.1 record (three bypass-tls-verification in packages/core/src/db/client.test.ts, one react-dangerouslysetinnerhtml in packages/sdk/react/src/defaults.tsx) and a fifth that record did not name: direct-response-write at apps/core-api/src/server.ts (the CSV export of the audit log, a text/csv answer written with res.send, in the code since 2026-10-18). None is in the baseline yet. The moderate and low advisories are the same as in 0.3.1 (@tiptap/core, katex, sanitize-html, nodemailer three, fast-uri four, postcss-selector-parser); none is high or critical.

Image scan (trivy image, HIGH/CRITICAL, fixed only), run 40400621940: the six own images, publisher included for the first time (F-063), and garage 0; postgres:16-alpine 25, in the Go standard library of gosu (reported, not gating, decision of the owner 2026-10-23; F-050).

The published images. After the release run, the six images on ghcr.io were checked by the digests in the release notes of the GitHub Release:

  • the cosign signature of each image (keyless, identity https://github.com/swina/whoobe_project/.github/workflows/release.yml@refs/tags/v0.3.2, issuer https://token.actions.githubusercontent.com, cosign 2.5.0): verified, 6 of 6;
  • the SLSA build provenance stored with each image (cosign verify-attestation --new-bundle-format --type slsaprovenance1, same workflow and tag): verified, 6 of 6;
  • trivy image 0.58.1 (HIGH/CRITICAL, fixed only) on the published digests: 0 for all six on amd64, and 0 for publisher on arm64 as well (the other five were not scanned on arm64).

This closes F-063 on the published artefacts: the publisher of 0.3.1 had 171 fixable HIGH/CRITICAL.

The reports of run 40400621940 (security-reports-v0.3.2.zip) and the CycloneDX SBOMs of the six images (generated by trivy 0.58.1 from the published digests, amd64) were attached to the GitHub Release on 2026-10-27, after publication. The publisher's SBOM lists 729 components, the same production tree as core-api, gateway and asset-processor; the 0.3.1 publisher listed 1478.

The runs that failed first#

None: every run of the security workflow between the 0.3.1 record and the release commit succeeded (40397598269, 40399244854, 40400620009, 40400621940, 40409761479).

What this run did not cover#

The list of v0.3.0 still holds. For this release in particular:

  • a publication started from the dashboard with the new publisher image: the job runner was run against a local API in the image (a Vue and a Next site), not through the dashboard and the queue;
  • arm64 was built and scanned only by the release workflow and by the check above (publisher only); no site was generated on arm64;

Open items at the time#

Listed with owner and reason in status-summary.md, section 3: F-003 (moderate advisories listed above; braces, high with no fix, accepted until 2027-01-31), F-008, F-014, F-050 (gosu in the postgres image), the TLS check on a live host. F-063 is fixed. The register has no entry kept private under the disclosure policy.

Last updated