CRA Dossier

Vulnerability handling, disclosure policy and reporting playbook

Product: Seeker Scout version 0.11.0 Manufacturer: Bilal El Homsi Generated: 2026-10-24 by cra-dossier 0.1.0 from the repository seeker-scout at commit 19267dd96bc8 Regulation: Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024, http://data.europa.eu/eli/reg/2024/2847/oj

DRAFT generated from the repository for the manufacturer to review, complete and sign. This is not legal advice. This document makes no claim that the product conforms to Regulation (EU) 2024/2847 and no claim about CE marking; conformity is declared only by the manufacturer, on its sole responsibility, after completing the human items in the gap list.

1. Annex I, Part II status

Requirement Short Status Finding Action
Annex I, Part II, point (1) Identify and document vulnerabilities and components; machine-readable SBOM of at least top-level dependencies Evidence found SBOM generated: 803 components (32 top-level) in CycloneDX 1.7 JSON by cdxgen. Platform-native dependencies (Gradle, CocoaPods) are not in this SBOM unless the tool resolved them. Regenerate the SBOM on every release and keep each version with the technical documentation; decide whether to publish it to users (Annex II, point 9).
Annex I, Part II, point (2) Address and remediate vulnerabilities without delay; security updates separate from feature updates where feasible Manufacturer decision No automated dependency update configuration found. The remediation process is a written procedure. Write the vulnerability handling procedure (intake, triage, fix, release, disclosure) in 04_vulnerability_handling.md and follow it.
Annex I, Part II, point (3) Effective and regular security tests and reviews Partly shown 19 test files, 1 test or check scripts, 0 CI workflows. Security-specific tests and reviews (dependency audit, static analysis, penetration test, code review) were not found. Add a recurring security test and review cadence (dependency audit on every build, static analysis, a periodic manual review) and keep the reports (Annex VII, point 6).
Annex I, Part II, point (4) Publicly disclose fixed vulnerabilities (description, affected product, impact, severity, remediation) Partly shown Release notes or a changelog exist; security fixes need their own entries with description, affected versions, impact, severity and remediation. Publish a security advisory for each fixed vulnerability (a SECURITY-ADVISORIES.md or a page), with the fields listed in Annex I, Part II, point (4).
Annex I, Part II, point (5) Coordinated vulnerability disclosure policy, in place and enforced Not found No coordinated vulnerability disclosure policy was found. A draft is included (SECURITY.md). Adopt and publish the CVD policy, then enforce it (track every report).
Annex I, Part II, point (6) Facilitate vulnerability information sharing; contact address for reports Partly shown A security contact address exists in the repository or the answers; publish it where users and researchers can find it (security.txt, the store listing, the website). Publish the contact address (security.txt at /.well-known/, SECURITY.md, the store listing) and the single point of contact (Article 13(17)).
Annex I, Part II, point (7) Secure update distribution mechanism, automatic where applicable Not found No secure update distribution mechanism was found. Describe the secure update mechanism in 02_technical_file.md section 4.3.
Annex I, Part II, point (8) Security updates disseminated without delay, free of charge, with advisory messages Manufacturer decision Updates through an app store or package registry are free of charge to users by default; the advisory message that accompanies a security update is a process the manufacturer runs. Commit to free security updates with an advisory message (release notes plus the advisory in point (4)).

2. Procedure (Article 13(8), last subparagraph: policies and procedures to process and remediate potential vulnerabilities)

[HUMAN: adopt or edit this draft]

  1. Intake: reports arrive at seekerscoutapp@gmail.com (security.txt, SECURITY.md, the store listing). Acknowledge within 3 working days.
  2. Triage: reproduce, rate severity (CVSS or simple high/medium/low), decide exploitability in this product. Record in the vulnerability log (Article 13(7)).
  3. Component vulnerabilities: when the flaw is in a third-party component, report it to the maintainer and share any fix (Article 13(6)).
  4. Fix: ship the security fix as its own release where technically feasible, separate from feature work (Annex I, Part II, point (2)).
  5. Distribute: through New builds are produced with EAS Build, signed with the manufacturer's upload key, submitted to the Solana dApp Store publisher portal with release notes and installed or updated by the dApp Store client on the phone; the catalog is refreshed by a scheduled job with sanity gates and the lounge worker is deployed with wrangler., free of charge, with an advisory message (Annex I, Part II, points (7) and (8)).
  6. Disclose: publish the advisory with description, affected versions, impact, severity and remediation once the update is available (Annex I, Part II, point (4)); delay only in duly justified cases.
  7. Keep the fix available for at least 10 years or the rest of the support period (Article 13(9)).
  8. Update the risk assessment where the vulnerability changes it (Article 13(3), 13(7)).

3. Article 14 reporting playbook (in application since 2026-09-11)

From 11 September 2026 (Article 71(2)), a manufacturer notifies any actively exploited vulnerability and any severe incident having an impact on the security of the product to the CSIRT designated as coordinator and to ENISA via the single reporting platform (Article 16).

Actively exploited vulnerability (Article 14(1) and (2)):

Severe incident having an impact on the security of the product (Article 14(3) and (4)):

Article 14(5): an incident is severe where it negatively affects (or can affect) the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or has led or can lead to the introduction or execution of malicious code in the product or in a user’s network and information systems.

Article 14(8): after becoming aware, inform the impacted users (and where appropriate all users) of the vulnerability or incident and of mitigation and corrective measures, where appropriate in a structured, machine-readable format.

Which CSIRT: Article 14(7): the CSIRT of the Member State of the manufacturer’s main establishment in the Union; a manufacturer with no main establishment in the Union uses, in order, the Member State of its authorised representative, of its importer, of its distributor, or where the highest number of users are located. This manufacturer is established outside the EU (Lebanon); the Member State is determined by the Article 14(7) order: authorised representative, importer, distributor, then where the highest number of users are located.

Responsible person and rehearsal: [HUMAN: who files the 24-hour early warning, who writes the 72-hour notification, where the platform credentials are kept (not in this file), when the drill was run]

4. Coordinated vulnerability disclosure policy

The draft policy is SECURITY.md in this folder (Annex I, Part II, point (5)). The contact file is security.txt (RFC 9116), to be served at /.well-known/security.txt on the manufacturer's website (Annex I, Part II, point (6)).

5. Dependency state at generation