Technical documentation (Annex VII structure)
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.
Article 31(1): the technical documentation contains all relevant data or details of the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with Annex I, and at least the elements of Annex VII. Article 31(2): drawn up before placing on the market and continuously updated during the support period. Article 13(13): kept for at least 10 years after placing on the market or for the support period, whichever is longer.
1. General description of the product (Annex VII, point 1)
1(a) Intended purpose
Seeker Scout is a companion app for the Solana Seeker phone's dApp Store. It shows a trend-ranked catalog of the apps in the store with freshness and update signals, lets Seeker owners vouch for apps and reply to vouches after verifying ownership of the Seeker Genesis Token in their wallet, shows Staked SKR weight, and offers a paid Alpha digest tier. It is distributed through the Solana dApp Store to consumers.
Essential functionalities: Discover feed (trending and newest), search, app detail pages with ratings and release signals, owner vouches and replies tied to a wallet signature, Rewards and Lounge screens, Profile with wallet connect through the Mobile Wallet Adapter, optional notifications about catalog changes, and the Alpha digest (free preview, paid members' feed).
Users: consumers. Security environment provided by the manufacturer: Runs on a Solana Seeker (Android) obtained from the Solana dApp Store, which verifies the package signature on install and update. Wallet keys stay in the phone's Seed Vault; the app receives an address and message signatures only. All network calls are HTTPS to the manufacturer's catalog and lounge services on Cloudflare, to Solana Mobile dApp Store assets and to a public Solana RPC endpoint. The user is responsible for the device lock and for approving signatures in the wallet.
Reasonably foreseeable use and misuse (Article 3(24) and 3(25)): A tampered build distributed outside the dApp Store; Forged or replayed vouch signatures against the lounge worker; A vulnerable third-party SDK (wallet adapter, web3, storage) in the dependency tree; Catalog poisoning through the upstream catalog source read by the indexer; Abuse of the open ping or vouch endpoints (volume, spam); Phishing through look-alike apps imitating the wallet sheet
1(b) Versions of software affecting compliance with the essential requirements
| Identifier | Value | Source |
|---|---|---|
| npm package name | seeker-scout |
package.json |
| expo slug | seeker-scout |
app.json |
| android package | com.bilal.seekerscout |
app.json |
| android versionCode | 14 |
app.json |
| documentation covers | 0.11.0 (versionCode 14) and later patch builds that are not substantial modifications. | answers |
| repository state | branch main, 92 commits, last commit 2026-10-03, last tag v0.11.0 |
git |
1(c) Hardware photographs or illustrations
Not applicable: software-only product (Article 13(4) justification: there is no hardware whose external features, marking or internal layout could be shown).
1(d) User information and instructions (Annex II)
Drafted in 05_user_information.md; to be published with the product (Article 13(18)).
2. Design, development, production and vulnerability handling (Annex VII, point 2)
2(a) Design and development, system architecture
A single Expo / React Native Android app (TypeScript, Hermes runtime) with tab screens (Discover, Search, Rewards, Lounge, Profile) in src/screens and the catalog, vouch, SKR and alpha logic in src/lib. The app loads the catalog JSON from the manufacturer's Cloudflare Pages site (with a bundled seed catalog as fallback), reads dApp Store assets for icons and screenshots, and talks to the lounge worker for vouches, replies, the Alpha digest and the daily open ping. The indexer/ and lounge-worker/ folders in the repository are the manufacturer's server-side code for those two services; watcher/ and program/ are retired or auxiliary.
Components (from the answers):
- Mobile app (Expo SDK 53, React Native 0.79, Hermes): screens, catalog loader, vouch and SKR logic, wallet adapter client, notifications and a background task
- Catalog indexer and the published catalog JSON on Cloudflare Pages (remote data processing solution)
- Lounge worker on Cloudflare Workers (remote data processing solution): signature verification, vouches, replies, Alpha digest, open ping
- Solana Mobile Wallet Adapter: address and message signing in the Seed Vault wallet, outside the app
- Public Solana RPC endpoint: Genesis Token and Staked SKR reads
Data flows: The app downloads the catalog JSON and store assets over HTTPS. When the user connects, the wallet returns an address; the app verifies the Seeker Genesis Token through a public RPC read. A vouch or reply is a message signed in the wallet and posted to the lounge worker, which stores it with the public address. Once a day per install the app sends an open ping with a days-since-install bucket (no identifier beyond that bucket) used for retention counts. Preferences, the try-later list and cached data are kept in AsyncStorage on the device (unencrypted app-private storage); no password, email or private key is stored.
External services reached by the code (hosts found in source; query strings and paths removed):
| Host | Occurrences | Cleartext | Example file |
|---|---|---|---|
| seeker-scout-catalog.pages.dev | 6 | no | lounge-worker/src/game.js |
| seeker-lounge.bcrypto-eth.workers.dev | 5 | no | indexer/enrich-vouches.mjs |
| api.mainnet-beta.solana.com | 3 | no | lounge-worker/src/rpc.js |
| seekertracker.com | 1 | no | indexer/fetch-catalog.mjs |
| solanamobile.com | 1 | no | src/lib/catalog.ts |
| stake.solanamobile.com | 1 | no | src/lib/catalog.ts |
| seekerscout.com | 1 | no | src/lib/wallet.ts |
Third-party services relied on (Article 13(5) due diligence; guidance C(2026) 5252 section 7.3): Solana Mobile dApp Store asset hosts (app icons, screenshots and catalog metadata); Public Solana RPC endpoint (Genesis Token verification and Staked SKR reads); Cloudflare Pages and Workers (hosts the catalog and the lounge worker (remote data processing solutions))
Permissions and platform capabilities: Android permissions none declared; explicitly blocked: android.permission.READ_EXTERNAL_STORAGE, android.permission.WRITE_EXTERNAL_STORAGE, android.permission.SYSTEM_ALERT_WINDOW, android.permission.RECORD_AUDIO; Expo plugins: expo-dev-client, expo-asset, expo-font, expo-notifications, expo-background-task.
2(b) Vulnerability handling processes
- Software bill of materials:
sbom.cdx.json(CycloneDX 1.7, 803 components, 32 top-level, generated by cdxgen on 2026-10-24). Annex I, Part II, point (1). - Coordinated vulnerability disclosure policy:
SECURITY.md(draft) [HUMAN: publish it and record the URL]. Annex I, Part II, point (5). - Contact address for vulnerability reports: seekerscoutapp@gmail.com;
security.txt(draft) [HUMAN: serve it at /.well-known/security.txt]. Annex I, Part II, point (6); Article 13(17). - Secure distribution of updates: 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. Annex I, Part II, point (7).
- Vulnerability handling procedure:
04_vulnerability_handling.md.
2(c) Production and monitoring processes and their validation
Build and release: Unit tests, EAS production build, standalone device verification on a physical Seeker (mandatory step in the project notes), upload to the dApp Store portal with What's New text.
Development process: Single developer with Claude Code sessions; TypeScript, node --test unit tests for the catalog, vouch, SKR and reply logic and for the indexer; public repository with secrets kept out of git.
Testing: node --test suites in src/lib and indexer/test; device verification before each store submission; no continuous integration service is configured in the repository.
Monitoring after release: Worker health endpoint, catalog refresh log with sanity gates, store reviews and the support mailbox, portal install statistics; no crash-reporting SDK in the app.
3. Cybersecurity risk assessment (Annex VII, point 3; Article 13(2) to (4))
See 03_risk_assessment.md. Summary of how each Annex I, Part I, point (2) requirement is applicable (Article 13(3)):
| Requirement | Short | Status | How it is applied or why not |
|---|---|---|---|
| Annex I, Part I, point (1) | Appropriate level of cybersecurity based on the risks | Partly shown | A risk assessment input exists (answers or a security policy text). The appropriate level of cybersecurity is a judgment the manufacturer documents in the risk assessment (Article 13(2) and (3)). |
| Annex I, Part I, point (2)(a) | No known exploitable vulnerabilities at release | Not found | 51 known vulnerability advisories affect 23 components in the SBOM (OSV, 2026-10-23); 0 of them are in components the SBOM marks as required (likely shipped), the rest in optional or build-time components. Each needs triage: exploitable in this product or not, and if yes, fixed before release. |
| Annex I, Part I, point (2)(b) | Secure by default configuration, with reset to original state | Partly shown | Debug-only code paths exist; confirm they are compiled out of the release build and that shipped defaults are the secure ones. Permissions declared: none found; blocked: android.permission.READ_EXTERNAL_STORAGE, android.permission.WRITE_EXTERNAL_STORAGE, android.permission.SYSTEM_ALERT_WINDOW, android.permission.RECORD_AUDIO. |
| Annex I, Part I, point (2)(c) | Security updates, automatic where applicable, with notification and opt-out | Not found | No update distribution channel was found in the repository. |
| Annex I, Part I, point (2)(d) | Protection from unauthorised access; report possible unauthorised access | Partly shown | Access-control mechanisms were found (bearer token sent to a service; OAuth / OpenID / social sign-in; Mobile Wallet Adapter / wallet signing (Solana)). Whether they cover every protected function and whether possible unauthorised access is reported is for the manufacturer to confirm. |
| Annex I, Part I, point (2)(e) | Confidentiality of stored, transmitted or processed data (encryption at rest and in transit) | Partly shown | 7 external hosts are reached over https:// and 0 over http://. Unencrypted on-device storage is also used; list what it holds and why that is acceptable. |
| Annex I, Part I, point (2)(f) | Integrity of data, commands, programs and configuration; report corruptions | Partly shown | The app platform verifies the package signature on install and update, which protects program integrity; integrity of stored data and configuration against unauthorised modification is for the manufacturer to describe. |
| Annex I, Part I, point (2)(g) | Data minimisation | Partly shown | 0 Android permissions declared; 2 device-capability packages; no analytics or crash-reporting SDK found. |
| Annex I, Part I, point (2)(h) | Availability of essential functions, including after an incident and against denial of service | Partly shown | Rate limiting or throttling code was found. |
| Annex I, Part I, point (2)(i) | Minimise negative impact on other devices or networks | Manufacturer decision | Whether the product can degrade other devices or networks (traffic volume, broadcast behaviour, background work) is a design statement. |
| Annex I, Part I, point (2)(j) | Limited attack surfaces, including external interfaces | Partly shown | External interfaces found: 7 remote hosts, 0 permissions, 4 permissions explicitly blocked. Deep links and intents are an external interface on mobile apps; list every scheme and intent filter. |
| Annex I, Part I, point (2)(k) | Exploitation mitigation mechanisms | Manufacturer decision | Mobile platforms provide sandboxing, memory-safe runtimes and signed packages; which of these the product relies on, and what it adds (least privilege, no dynamic code loading, pinned dependencies), is a statement. |
| Annex I, Part I, point (2)(l) | Security-related logging and monitoring with a user opt-out | Partly shown | Logging or telemetry code found (console logging); no user opt-out setting was found. Security-relevant events (access to or modification of data, services or functions) need recording with an opt-out mechanism for the user. |
| Annex I, Part I, point (2)(m) | Secure and easy permanent removal of all data and settings | Partly shown | A sign-out or disconnect flow exists but no explicit delete-all-data flow was found. Uninstalling removes app-private data on mobile platforms; server-side data and any cloud backups need their own path. |
4. Support period information (Annex VII, point 4; Article 13(8))
See 06_support_period.md. Declared end of support: [HUMAN: YYYY-MM].
5. Standards applied or solutions adopted (Annex VII, point 5)
No harmonised standard with a reference published in the Official Journal, no common specification and no European cybersecurity certification scheme has been applied. As Annex VII, point 5 allows in that case, the solutions adopted to meet Annex I, Parts I and II, are described per requirement below and in the risk assessment. Presumption of conformity under Article 27 is therefore not claimed.
| Requirement | Short | Status | Solution adopted or gap |
|---|---|---|---|
| Annex I, Part I, point (1) | Appropriate level of cybersecurity based on the risks | Partly shown | A risk assessment input exists (answers or a security policy text). The appropriate level of cybersecurity is a judgment the manufacturer documents in the risk assessment (Article 13(2) and (3)). |
| Annex I, Part I, point (2)(a) | No known exploitable vulnerabilities at release | Not found | 51 known vulnerability advisories affect 23 components in the SBOM (OSV, 2026-10-23); 0 of them are in components the SBOM marks as required (likely shipped), the rest in optional or build-time components. Each needs triage: exploitable in this product or not, and if yes, fixed before release. |
| Annex I, Part I, point (2)(b) | Secure by default configuration, with reset to original state | Partly shown | Debug-only code paths exist; confirm they are compiled out of the release build and that shipped defaults are the secure ones. Permissions declared: none found; blocked: android.permission.READ_EXTERNAL_STORAGE, android.permission.WRITE_EXTERNAL_STORAGE, android.permission.SYSTEM_ALERT_WINDOW, android.permission.RECORD_AUDIO. |
| Annex I, Part I, point (2)(c) | Security updates, automatic where applicable, with notification and opt-out | Not found | No update distribution channel was found in the repository. |
| Annex I, Part I, point (2)(d) | Protection from unauthorised access; report possible unauthorised access | Partly shown | Access-control mechanisms were found (bearer token sent to a service; OAuth / OpenID / social sign-in; Mobile Wallet Adapter / wallet signing (Solana)). Whether they cover every protected function and whether possible unauthorised access is reported is for the manufacturer to confirm. |
| Annex I, Part I, point (2)(e) | Confidentiality of stored, transmitted or processed data (encryption at rest and in transit) | Partly shown | 7 external hosts are reached over https:// and 0 over http://. Unencrypted on-device storage is also used; list what it holds and why that is acceptable. |
| Annex I, Part I, point (2)(f) | Integrity of data, commands, programs and configuration; report corruptions | Partly shown | The app platform verifies the package signature on install and update, which protects program integrity; integrity of stored data and configuration against unauthorised modification is for the manufacturer to describe. |
| Annex I, Part I, point (2)(g) | Data minimisation | Partly shown | 0 Android permissions declared; 2 device-capability packages; no analytics or crash-reporting SDK found. |
| Annex I, Part I, point (2)(h) | Availability of essential functions, including after an incident and against denial of service | Partly shown | Rate limiting or throttling code was found. |
| Annex I, Part I, point (2)(i) | Minimise negative impact on other devices or networks | Manufacturer decision | Whether the product can degrade other devices or networks (traffic volume, broadcast behaviour, background work) is a design statement. |
| Annex I, Part I, point (2)(j) | Limited attack surfaces, including external interfaces | Partly shown | External interfaces found: 7 remote hosts, 0 permissions, 4 permissions explicitly blocked. Deep links and intents are an external interface on mobile apps; list every scheme and intent filter. |
| Annex I, Part I, point (2)(k) | Exploitation mitigation mechanisms | Manufacturer decision | Mobile platforms provide sandboxing, memory-safe runtimes and signed packages; which of these the product relies on, and what it adds (least privilege, no dynamic code loading, pinned dependencies), is a statement. |
| Annex I, Part I, point (2)(l) | Security-related logging and monitoring with a user opt-out | Partly shown | Logging or telemetry code found (console logging); no user opt-out setting was found. Security-relevant events (access to or modification of data, services or functions) need recording with an opt-out mechanism for the user. |
| Annex I, Part I, point (2)(m) | Secure and easy permanent removal of all data and settings | Partly shown | A sign-out or disconnect flow exists but no explicit delete-all-data flow was found. Uninstalling removes app-private data on mobile platforms; server-side data and any cloud backups need their own path. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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). |
| 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). |
| Annex I, Part II, point (7) | Secure update distribution mechanism, automatic where applicable | Not found | No secure update distribution mechanism was found. |
| 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. |
6. Test reports (Annex VII, point 6)
19 automated test files exist in the repository. [HUMAN: attach the reports of the tests that verify the Annex I requirements: dependency vulnerability check output per release (sbom_vulnerabilities.md), static analysis, security review notes, any penetration test]
7. Copy of the EU declaration of conformity (Annex VII, point 7)
07_declaration_of_conformity_DRAFT.md, unsigned until the gap list is closed.
8. Software bill of materials (Annex VII, point 8)
sbom.cdx.json, provided to a market surveillance authority on reasoned request.