Cybersecurity risk assessment

Product: COOK version 2.0.0 Manufacturer: Bilal El Homsi Generated: 2026-10-24 by cra-dossier 0.1.0 from the repository cook at commit cd17b114fbab 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 13(2): the manufacturer undertakes an assessment of the cybersecurity risks associated with the product and takes the outcome into account during planning, design, development, production, delivery and maintenance. Article 13(3): documented and updated during the support period; it comprises at least an analysis of risks based on the intended purpose, reasonably foreseeable use and conditions of use (operational environment, assets to be protected, expected time in use), says whether and how each Annex I, Part I, point (2) requirement applies and is implemented, and how Part I, point (1) and Part II are applied. Article 13(4): where a requirement is not applicable, the technical documentation includes a clear justification. Guidance C(2026) 5252, section 7, describes the evaluation and treatment of risks and due diligence on external dependencies.

1. Context

• Intended purpose: COOK lets a Seeker phone owner type a thought or pick a photo, receive an AI-generated meme character with a meme and sticker pack, and, only if the user chooses, launch that character as a Solana meme coin through one of four launch rails (the COOK Kitchen on Meteora's dynamic bonding curve, Pump.fun, Jupiter Studio or Bags). The app never holds private keys: every transaction is signed by the user's Seed Vault wallet through the Solana Mobile Wallet Adapter. It is distributed through the Solana dApp Store to consumers.
• Operational environment: Runs on a Solana Seeker (Android) obtained from the Solana dApp Store, which verifies the package signature on install and update. Keys live in the phone's Seed Vault; the app receives signatures only. Network access is over HTTPS to Solana RPC endpoints, the COOK metadata and feed worker (Cloudflare), the launch-rail APIs and an AI model gateway. The user is responsible for the device lock, for keeping the phone and the app updated, and for approving each transaction in the wallet sheet.
• Expected time in use: 5 years (support period decision in 06_support_period.md)
• Platforms and interfaces (from the scan): Expo / React Native, Android; 25 external hosts; 7 Android permissions.

2. Assets to protect

• User funds in the connected wallet: the app builds transactions the user signs; a wrong or malicious transaction could move funds
• Integrity of the app build and of the worker: a tampered build or worker could alter transactions or metadata
• Coin metadata and images: served publicly from the worker; integrity matters for creators
• Availability of the worker and RPC endpoints: without them the app cannot create or show coins

3. Threats considered

• A malicious or tampered build distributed outside the dApp Store
• Compromise of the worker or its upload token leading to altered metadata
• A vulnerable third-party SDK (bonding curve, wallet adapter, web3) in the dependency tree
• Prompt or name-check abuse to produce offensive or infringing coins (handled by the guard data and the grader)
• RPC endpoint outage or rate limiting causing failed or stuck launches
• Phishing through look-alike apps or deep links imitating the wallet sheet

4. Risks accepted

• Meme coin launches are speculative by nature; the app shows the fee model and the grade but does not control the market

5. Annex I, Part I: applicability and implementation per requirement

Annex I, Part I, point (1): Appropriate level of cybersecurity based on the risks

Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

• Applicable: Yes

• Status from the scan: 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)).

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(a): No known exploitable vulnerabilities at release

be made available on the market without known exploitable vulnerabilities;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: Not found. 59 known vulnerability advisories affect 21 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.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(b): Secure by default configuration, with reset to original state

be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: Manufacturer decision. No cleartext endpoints found. Whether the shipped defaults are secure, and how the user resets the product to its original state, is a manufacturer statement.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(c): Security updates, automatic where applicable, with notification and opt-out

ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. Updates are delivered through Solana dApp Store; on Android and iOS the store applies updates automatically by default on the user’s device with a user-controlled opt-out, and notifies the user. An in-app version check or update prompt was found. Whether security updates ship separately from feature updates (Annex I, Part II, point (2)) is a process statement.
• Evidence:
  • App.tsx:58 // x-cook-version on every worker call is the Android versionCode. eas.json
  • src/config.ts:13 * EXPO_PUBLIC_COOK_STORE (see eas.json). Defaults to the Solana dApp Store, so an
  • scripts/check-copy.cjs:640 { path: 'dapp-store/config.yaml', kind: 'doc' },
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(d): Protection from unauthorised access; report possible unauthorised access

ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. Access-control mechanisms were found (bearer token sent to a service; Mobile Wallet Adapter / wallet signing (Solana); API key header sent to a service). Whether they cover every protected function and whether possible unauthorised access is reported is for the manufacturer to confirm.
• Evidence:
  • worker/src/lib/imagecheck.js:638 headers: { authorization: [redacted], 'content-type': 'application/json', 'x-title': OR_TITLE },
  • worker/src/lib/namecheck.js:911 headers: { authorization: [redacted], 'content-type': 'application/json', 'x-title': OR_TITLE },
  • worker/src/lib/openrouter.js:470 headers: { authorization: [redacted], 'content-type': 'application/json', 'x-title': OR_TITLE },
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(e): Confidentiality of stored, transmitted or processed data (encryption at rest and in transit)

protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. 25 external hosts are reached over https:// and 0 over http://. Encrypted secure storage is used for some data.
• Evidence:
  • src/components/Playbook.tsx:3 import * as SecureStore from 'expo-secure-store';
  • src/screens/CoinScreen.tsx:17 import * as SecureStore from 'expo-secure-store';
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(f): Integrity of data, commands, programs and configuration; report corruptions

protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. Solana dApp Store 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.
• Evidence:
  • src/services/link.ts:104 // no crypto.subtle on Hermes and no extra dependency.
  • worker/src/lib/auth.js:79 const k = await crypto.subtle.importKey('raw', enc.encode(String(key)), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(g): Data minimisation

process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: Manufacturer decision. 7 Android permissions declared (android.permission.CAMERA, android.permission.INTERNET, android.permission.SYSTEM_ALERT_WINDOW, android.permission.READ_EXTERNAL_STORAGE, android.permission.RECORD_AUDIO, android.permission.VIBRATE, android.permission.WRITE_EXTERNAL_STORAGE); 4 device-capability packages; no analytics or crash-reporting SDK found.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(h): Availability of essential functions, including after an incident and against denial of service

protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. Rate limiting or throttling code was found.
• Evidence:
  • src/services/solana.ts:7 // some methods, rate-limit and stall; mainnet txs without priority fees get
  • worker/src/cron/grader.js:631 // the public one among them, rate-limit it and then refuse the whole batch.
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(i): Minimise negative impact on other devices or networks

minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: Manufacturer decision. Whether the product can degrade other devices or networks (traffic volume, broadcast behaviour, background work) is a design statement.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(j): Limited attack surfaces, including external interfaces

be designed, developed and produced to limit attack surfaces, including external interfaces;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: Partly shown. External interfaces found: 25 remote hosts, 7 permissions, 2 permissions explicitly blocked. Deep links and intents are an external interface on mobile apps; list every scheme and intent filter.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(k): Exploitation mitigation mechanisms

be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]

• Status from the scan: 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.

• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]

• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(l): Security-related logging and monitoring with a user opt-out

provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. Logging or telemetry code found (console logging; opt-out or telemetry setting); an 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.
• Evidence:
  • docs/humour-v10/ref-ab/scripts/blind-pack.mjs:259 console.log(pack: ${r.out} (${r.pictures} pictures in ${r.groups} groups));
  • docs/humour-v10/ref-ab/scripts/blind-score.mjs:158 console.log(o.json ? JSON.stringify(r, null, 1) : text(r));
  • docs/humour-v10/ref-ab/scripts/drive.mjs:92 console.log(${ideas[i].slug} m${m + 1} ${bad ? UNSAFE ${JSON.stringify(s.unsafe)} EMPTY ${s.empty}` : 'ok'} words=${p.words} trims=${JSON…
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

Annex I, Part I, point (2)(m): Secure and easy permanent removal of all data and settings

provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.

• Applicable: Yes [HUMAN: confirm, or mark not applicable with a justification]
• Status from the scan: Partly shown. A data-deletion or reset flow was found; confirm it removes all data and settings permanently, including server-side data.
• Evidence:
  • src/services/feed.ts:652 else await SecureStore.deleteItemAsync(HIDDEN_KEY);
  • src/services/kit.ts:454 if (claim) await SecureStore.deleteItemAsync(CLAIM_KEY(mint)).catch(() => undefined);
  • src/screens/HomeScreen.tsx:24 import { connectStopKey, connectWallet, disconnectWallet, switchWallet } from '../services/wallet';
• How the requirement is implemented: [HUMAN: describe the measure, or the reason it is not needed for this product]
• Residual risk and acceptance: [HUMAN: low / medium / high, accepted by whom, on what date]

6. Vulnerability handling (Annex I, Part II) as applied

See 04_vulnerability_handling.md; Article 13(3) asks this assessment to say how Part II is applied: [HUMAN: one paragraph]

7. Review log