project: update wrong flag name

Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>

PROJECT.md

@@ -165,7 +165,7 @@ This section is for some guidelines about what BuildKit considers a security iss
 ### Examples of issues not (currently) considered security
 
 - Multiple concurrent builds from separate client share their build resources without namespacing. For example, if both builds require pulling the same image, the pull only happens once and is authenticated only once. The same behavior happens with containers that use the same build secret or if local cache or cache mounts of a previous build are reused. If different behavior is needed, consider running multiple instances of buildkitd for each of the namespaces.
-- Remote cache resources provided with `--cache-to` need to be trusted by the user. If they have been manipulated by an attacker, this can result in an incorrect cache match by BuildKit solver.
+- Remote cache resources provided with `--cache-from` need to be trusted by the user. If they have been manipulated by an attacker, this can result in an incorrect cache match by BuildKit solver.
 - Application containers may cause the system to run out of resources (e.g. memory). In that case BuildKit should be configured with a cgroup parent.
 - By default, registry credentials are not shared with BuildKit daemon, and short-lived token is generated on client side instead. For backward compatibility this can be bypassed and daemon can choose to ask for credentials instead (this is always required for basic auth). In such cases, the sending of credentials should be logged by the client, but no special confirmation from the user is needed.
 - Untrusted frontends are free to run any builds, for example, they can run a container with a secret mounted and then read out the secret value. They are not allowed to see your registry credentials/tokens or signing keys.