By submitting your report, you agree to the terms of this Bug Bounty Program. Arm reserves the right to alter the terms and conditions of this program at any time and its sole discretion.

By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)

To be eligible for Arm's Trusted Firmware Bug Bounty Program, you must not:

• Be a resident of, or make your submission from, a country against which the US, UK or EU has embargoed, sanctioned, or otherwise controlled/restricted (e.g., Cuba, * Iran, North Korea, Sudan, Syria, Russia, etc.).
• Be, be affiliated with or work for, an entity which the US, UK or EU has embargoed, sanctioned, or otherwise controlled/restricted.
• Be legally prohibited from being rewarded by Arm, Trusted Firmware or Intigriti for any reason.
• Be a current employee of a Trusted Firmware member company, its affiliates or subsidiaries, or an employee who has left employment of a Trusted Firmware member company, its affiliates or subsidiaries within the past 12 months.
• Be an immediate family member of a current employee of a Trusted Firmware member company, its affiliates or subsidiaries, or an immediate family member of an employee who has left a Trusted Firmware member company, its affiliates or subsidiaries within the past 12 months.
• Be less than 18 years of age.

Your relationship with Arm in the context of your participation in any Arm Program (as defined in the Researcher T&C) is exclusively governed by the law of England & Wales, and the courts of London, England, will have sole jurisdiction for any claims or disputes between you and Arm in the context thereof.

Safe Harbor

Arm considers ethical hacking activities conducted consistent with the Researcher Guidelines, the Program description and restrictions (the Terms) to constitute “authorized” conduct under criminal law. Arm will not pursue civil action or initiate a complaint for accidental, good faith violations, nor will they file a complaint for circumventing technological measures used by us to protect the scope as part of your ethical hacking activities.

Please note that Arm is not able to grant authority or safe harbor to researchers for any security vulnerability testing of third-party software or systems.

General Eligibility

Vulnerability reports must:

• demonstrate a clear exploitable security impact. Compliance, hardening, missing zeroization issues, etc. are not in scope.
• be reproducible by Arm using either the main branch or a currently supported LTS branch of an in-scope project
• only use code that's intended for production deployment (e.g., code that is clearly marked as "experimental" or "examples" is out of scope)
• contain a proof-of-concept which runs on a supported platform and exploits the vulnerability in a realistic scenario.
  * Note: The proof-of-concept must demonstrate that the vulnerability is exploitable through legitimate use of the software. Calling individual functions out of context or building a script to simulate portions of the software is not sufficient.
  * Note: Using virtualised platform environments is acceptable.

General

• Trusted Firmware projects that are not listed as in scope.
  • Please submit vulnerability reports for other projects directly to Trusted Firmware.
• Vulnerabilities identified in code marked as experimental, test code or other non-production code e.g. support tooling are out of scope of the program
• Attacks that are outside the scope of the project's threat model
• Vulnerabilities in platform-specific code for non-Arm products, e.g.:
  • For TrustedFirmware-A, code in the /plat directory except for /platform/common/* and plat/arm/*
  • For TrustedFirmware-M, code in the /platform/ext/target/* directory except for /platform/ext/target/arm/*
  • For OP-TEE, code in the /core/arch/risk/* and /core/arch/arm/plat-* directories except for platforms owned by Arm
• Vulnerabilities in modifications or customisations of Trusted Firmware that do not exist in official Trusted Firmware repos.
• Vulnerabilities in Trusted Firmware's web estate
  • Trusted Firmware's web infrastructure is hosted by Linaro. To report vulnerabilities in Trusted Firmware's web estate please follow the Linaro Security Incident Handling Process.

Additional Exclusions

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DDoS attacks or brute force attacks
• Vulnerabilities that only work on devices that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device or compromised user accounts
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty
• Reports that state that software is out of date/vulnerable without a proof-of-concept.
• Reports that do not demonstrate a clear exploitable security impact. E.g. the bug only has a compliance impact or hardening recommendation.

The decision to grant a reward (bounty or bonus) for a vulnerability report, and the value of that reward (if any), is entirely within Arm’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the demonstrated impact and severity of the reported vulnerability.

Note: The maximum bounty that will be rewarded for vulnerabilities that are only exploitable by a Trusted Application (OP-TEE) or Secure Partition (TF-A & TF-M) is 'Low'.

Trusted Firmware has a detailed set of documentation which is linked from trustedfirmware.org. We strongly recommend you consult the relevant documentation for any questions you may have.

This program has received a high number of incorrect reports, largely driven by AI-generated reports being submitted without first verifying the findings.
Below are some examples of commonly rejected submissions, with advice on how to prevent this:

MBed TLS/TF-PSA-Crypto

• Compliance, hardening or missing zeroization findings do not constitute exploitable vulnerabilities on their own. Reports must demonstrate attacker-controlled input and concrete security impact.
• Session resumption after changing the TLS requirements is not considered an exploitable vulnerability. Reports must clearly demonstrate exploitability as well as impact.

OP-TEE

• Self-attacks involving malicious TAs, signed SPs or an already-compromised kernel are not in scope. Reports must demonstrate an impact outside the originating TA or Normal World component.

TF-A

• Boot failure or availability loss is not in scope. Reports must clearly demonstrate a confidentiality, integrity or control-flow impact.
• Experimental features and non-Arm platform-specific code are not in scope. Please check to ensure your report does not utilise these.
• Directly calling internal functions is not permitted. Ensure your PoC follows a valid TF-A flow.

TF-M

• Directly calling internal functions is not permitted. Ensure your PoC follows a valid TF-A flow.