Skip to main content

A Practical Property-Based Risk Assessment for Apps, Games, and Software

The Cyber Resilience Act (CRA) needs you to do a risk assessment, but let's be real, if you're building an indie game or a straightforward app, you need a practical approach. Forget overly complex frameworks for a moment. A solid starting point is to look at the "properties" your software must have according to Annex I, Part I of the CRA, and then ask: "What could go wrong with these?"

Linking Properties to Risks​

Annex I, Part I, point (2) lists several essential security properties your product must have, based on your initial risk assessment. For example, your software needs to:

  • Be made available without known exploitable vulnerabilities.
  • Have a secure by default configuration.
  • Ensure vulnerabilities can be addressed through security updates.
  • Protect from unauthorized access.
  • Protect confidentiality and integrity of data.
  • Protect availability of essential functions.
  • Limit attack surfaces.

Turning Properties into Questions​

A property-based assessment translates these into risk questions for your app or game:

  • Vulnerabilities: What's our process for ensuring we ship without known critical bugs in our code or our game engine? What if a new vulnerability is found in a library we use post-launch?
  • Secure Default: Does our app default to the safest settings for users? Or does it expose sensitive data by default?
  • Updates: How will we deliver security patches for our game? Is it automatic? Easy for users?
  • Access Control: If our app has user accounts, how are we preventing unauthorized access to someone else's profile or in-app purchases?
  • Data Protection: Is the player's progress in our game stored securely? Are API keys in our software hardcoded or protected?

This approach directly ties your risk identification to the CRA's essential requirements, making it very relevant.

Key Takeway​

For many software products like apps and games, a practical risk assessment can start by examining the essential security properties in Annex I. Ask what could compromise these properties in your product, and you've begun identifying your key risks.