wasm-micro-runtime/doc/security_need_to_know.md

# About security issues

This document aims to explain the process of identifying a security issue and the steps for managing a security issue.

## identifying a security issue

It is commonly stated that a security issue is an issue that:

- Exposes sensitive information to unauthorized parties.
- Allows unauthorized modification of data or system state.
- Affects the availability of the system or its services.
- Permits unauthorized access to the system.
- Enables users to perform actions they should not be able to.
- Allows users to deny actions they have performed.

Given that WASI is a set of Capability-based APIs, all unauthorized actions are not supposed to happen. Most of the above security concerns can be alleviated. What remains for us is to ensure that the execution of Wasm modules is secure. In other words, do not compromise the sandbox. Unless it is explicitly disabled beforehand.

### Is this bug considered a security vulnerability?

For someone who finds a problem, if a bug causes the program to stop working(CRASH), please treat it as a security problem and report it to a security advisor. The person in charge will look into it and change its category if needed.

For those in charge, please use the following guidelines to determine if a bug or advisory is a security issue:

Only bugs that affect tier A platforms or features should be considered.

Anything that works immediately without setup is a security issue. However, actions that differ from Wasm rules (like calculating wrong values) are not seen as security issues as long as they stay within the sandbox.

As embedded code, trusts inputs from the guest. Those who call functions should ensure they provide correct parameters. Especially, memory regions passed by pointers.

.wasm files are not trusted, but .aot files are trusted. Users with wamrc should use correct command line options during converting .wasm to .aot.

A denial-of-service (DoS) attack is a cyberattack that aims to make a computer or network resource unavailable to its users. If the service (runtime in this case) can recover and start another module or run another function within the same instance, it is not considered unavailable, and thus not a Denial of Service (DoS). 

Another type of execution we usually do not classify as a security problem is if it is caused by an infinite loop or incorrect recursive function call chain.

>[!NOTE]
> Might need a diagram or a cheat sheet for quick reference eventually.

### When you identify a problem that should be classified as a security vulnerability

Act quickly and reduce exposure. Once you realize the issue or pull request describes a real or possible security vulnerability, handle it as sensitive information. Do not share technical details publicly on the issue or pull request.

Close or edit the public discussion. Thank the person who reported it and explain that issues related to security should go through the Security Advisory process. Close the public issue or pull request as soon as possible to stop further public sharing. If details are already shared, think about editing or asking GitHub staff to remove sensitive content.

Direct the reporter to the right channel. Set up a Security Advisory for the project and invite the reporter to join as a collaborator. If the reporter is not comfortable using GitHub Security Advisories, offer another secure way to communicate (like encrypted email).

Follow the guidelines in [the security issue runbook](./security_issue_runbook.md) for the next steps.

## reporting a security issue

Follow the [same guidelines](https://bytecodealliance.org/security) as other projects within the Bytecode Alliance.

## managing a security issue

Once a security issue is confirmed, please refer to [the runbook](./security_issue_runbook.md) for the subsequent steps to take.