Shipmark / Sample report

Sample CRA report: a real Flutter app, four releases

Generated 7 November 2026 with the open-source Shipmark SBOM Action and OSV.dev · Real data, not a mock-up

This is what a Shipmark check looks like on a real app. We used Immich, a popular open-source photo app built with Flutter, because its code and lockfiles are public.

The current release (3.3.6) has 247 components and no known vulnerabilities in OSV.dev.
A release from September 2023 (1.78.0) shipped a version of the archive library with two high-severity advisories, published 13 days before that release, with a fix already available.
A known vulnerability is not automatically a reportable one. Below is how to judge it, and what an ENISA early warning would contain if it ever were.

The app and the method

Immich is an open-source, self-hosted photo and video app. Its mobile client is written in Flutter. We took the lockfiles from four tagged releases on GitHub (mobile/pubspec.lock for the Dart side and mobile/ios/Podfile.lock for the iOS side), built a CycloneDX 1.6 SBOM for each with the Shipmark SBOM Action, and checked every component against OSV.dev.

Immich is used here only because it is public and well known. Nothing on this page says anything about the security of Immich today, and the project is not affiliated with Shipmark.

Results across four releases

Release	Components and findings
3.3.6 (November 2026) Download SBOM	247 components (237 Dart, 10 CocoaPods) No known vulnerabilities
1.123.0 Download SBOM	252 components No known vulnerabilities
1.102.1 Download SBOM	240 components No known vulnerabilities
1.78.0 (September 2023) Download SBOM	225 components 2 high, both in `archive` 3.3.7

The SBOM files are the real output, in CycloneDX JSON. Open one in any text editor or import it into a tool such as Dependency-Track.

The two findings in release 1.78.0

Advisory	What it is
CVE-2023-39139 CVSS 7.8, high	Path traversal in `archive` 3.3.7 and earlier when extracting a crafted zip file. Fixed in 3.3.8. Published 31 August 2023.
CVE-2023-39137 CVSS 7.8, high	Filename spoofing in `archive` 3.3.7, which can cause inconsistent filename parsing. Fixed in 3.3.8. Published 31 August 2023.

Release 1.78.0 was tagged on 13 September 2023, so both advisories and the fix existed for about two weeks before it shipped. That is the gap a daily check closes: the update was one version bump away.

How to judge a finding

Under the CRA, a known vulnerability in a dependency is something to handle and fix (Annex I, Part II). It only has to be reported to ENISA within 24 hours if it is actively exploited: if there is reliable evidence that a malicious actor has exploited it (Article 3(42) and Article 14). For these two findings, an agency would note:

archive is a transitive dependency in this release: the lockfile shows it was pulled in by another package, not added by the team.
Both advisories have a local attack vector that needs user interaction (CVSS AV:L/UI:R). Whether the app ever extracts untrusted zip files decides if the flaw is reachable at all.
A fixed version exists, so the normal action is an update in the next release, recorded in the vulnerability log.
Nothing in the advisories indicates active exploitation, so no ENISA report would be triggered.

If it were actively exploited: an example early warning

To show the other path, here is what the 24-hour early warning under Article 14(2)(a) could look like for a fictional client app that shipped the same library, if there were reliable evidence of exploitation. It is an illustration, not a report about any real app.

Early warning – actively exploited vulnerability (Art. 14(2)(a) CRA)
Manufacturer:     Example Retail SRL (fictional)
Product:          Example Shop for Android and iOS, version 2.4.0
Vulnerability:    CVE-2023-39139, path traversal in the archive library 3.3.7
Became aware:     2026-11-07 09:40 CET (initial assessment completed)
Evidence:         crafted zip files observed in user uploads, files written outside the app sandbox
Member States where the product is made available: RO, BG, HU
Status:           update with archive 3.3.8 in preparation; notification to follow within 72 hours

The reporting guide explains the 72-hour notification and the final report, and the deadline calculator gives the exact times.

What the client receives

An agency would turn the same data into a short, plain report for the client, who is usually the manufacturer. For release 1.78.0 it would say, in substance: one third-party library had two known high-severity flaws; neither is known to be exploited; the fix is an update that is already available; it will ship in the next release; no report to ENISA is required. The SBOM is attached as evidence for the technical documentation.

What this check does not cover

It only sees what the lockfiles declare. Immich's Android build does not use Gradle dependency locking, so Android native libraries are not in these SBOMs.
OSV.dev has little advisory data for CocoaPods, so iOS native components are listed in the SBOM but rarely matched to vulnerabilities.
It does not analyse the app's own code or test the running app.

Want the same for one of your apps? Send a lockfile and we prepare the report for free.

Get a free CRA check

Sources

immich-app/immich on GitHub: tags v1.78.0, v1.102.1, v1.123.0 and v3.3.6.
OSV: GHSA-9v85-q87q-g4vg (CVE-2023-39139) and GHSA-r285-q736-9v95 (CVE-2023-39137).
Regulation (EU) 2024/2847 (Cyber Resilience Act): Articles 3(42) and 14, Annex I Part II.

Results are from OSV.dev on 7 November 2026 and can change as new advisories are published. This page is an example, not legal advice.