Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
# Security

This C2PA open-source library is maintained in partnership with Adobe. At this time, Adobe is taking point on accepting security reports through its HackerOne portal and public bug bounty program.
This C2PA open-source library is maintained in partnership with Adobe. Adobe accepts security reports through its public [Intigriti program](https://app.intigriti.com/programs/adobe/adobepublic/detail). C2PA is listed in the program for vulnerability disclosure, but is not currently eligible for bounty rewards. Adobe continues to accept reports for assets that are not bounty-eligible, including critical findings it considers important.

## Reporting a vulnerability

Please do not create a public GitHub issue for any suspected security vulnerabilities. Instead, please file an issue through [Adobe's HackerOne page](https://hackerone.com/adobe?type=team). If for some reason this is not possible, reach out to cai-security@adobe.com.
Please do not create a public GitHub issue for any suspected security vulnerabilities. Details on how to report security vulnerabilities are available on [Adobe's bug bounty program page](https://www.adobe.com/trust/security/bug-bounty.html).

## What counts as a reportable vulnerability?

Expand All @@ -14,11 +14,11 @@ We will follow this checklist when evaluating vulnerability tickets.

Tickets that match the following characteristics will generally be **rejected**:

* **Issues with the C2PA technical specification itself.** This library is only an implementation of the spec as written. Report suspected vulnerabilities within the spec in the [C2PA specification repository](https://github.com/c2pa-org/specifications/issues).
* **Denial-of-service attacks.** For example, out-of-memory conditions caused by sending large input data. It’s the responsibility of the host application to enforce size limits on raw input data based on configuration information specific to the host. **EXCEPTION:** When a “reasonably small” input generates an unreasonably large memory allocation, such as an input file of 1MB causing a 200MB memory allocation (i.e. the c2pa-rs allocation is a very large multiple of the original input), that ticket will generally be accepted.
* **Use of non-default configuration settings to bypass security requirements** provided the consequences of those settings are sufficiently documented in our [documentation on settings](docs/context-settings.md).
* **Generation of invalid C2PA manifests from valid inputs or credentials.** In these scenarios, the inputs were not maliciously altered, but due to a bug in the SDK a malformed manifest has been produced. These are welcome as ordinary bug reports, but are not security vulnerabilities.
* **Use of the SDK or command-line tools on unsupported platforms or unreleased versions.** Only platforms and build configurations listed as Tier 1A, Tier 1B, or Tier 2 on [our support tiers page](docs/support-tiers.md) are explicitly supported. A security ticket must include the version number of the SDK or c2patool and the host platform that was used. Only tagged releases will be accepted. If any non-standard build process (i.e. not using current Rust cargo to build from source or not using a pre-packaged binary provided by this team), that should be disclosed and may result in a ticket not being accepted.
* **Issues with the C2PA technical specification itself.** This library is only an implementation of the spec as written. Any suspected vulnerabilities within the spec can be reported [here](https://github.com/c2pa-org/specifications/issues).
* **Invalid or malicious inputs to API functions other than content likely to be generated off-device.** The primary untrusted input this library is designed to defend against is content that may have been generated off-device, principally C2PA manifests. Other direct inputs to API functions (configuration values, paths, options, and similar parameters supplied by the calling application) are assumed to be trustworthy. Similarly, resource stores and working stores are assumed to be trustworthy as they are assumed to have been developed and consumed on the same host system. It is the responsibility of the application developer to perform reasonable sanity checks on the direct inputs to API functions.

### ❌ _Temporarily_ unwelcome vulnerability tickets
Expand Down
Loading