DEV Community

kozhevniko
kozhevniko

Posted on

Automatisch Encrypts Credentials, but Exposure Also Depends on Keys

Automatisch Encrypts Credentials, but Exposure Also Depends on Keys

Automatisch is an open-source workflow automation platform. A deployment holds connections to third-party services, the flows that use those connections, and the webhook endpoints that can trigger work. The platform encrypts stored third-party credentials, but encryption at rest only answers part of the exposure question. The operator still has to protect the keys, the database, the webhook verifier, and every path that can execute a flow.

On 15 November 2026, ZoomEye returned 0 matches for app="Automatisch", 1,145 for title="Automatisch", and 11,481,600 for http.body="Automatisch". The third number is not a product-exposure estimate. "Automatisch" is a common German word, so the body query demonstrates why a broad term needs semantic review. The exact title is the usable product signal in this measurement.

Key responsibilities are separate

The project documentation uses ENCRYPTION_KEY to encrypt third-party credentials, WEBHOOK_SECRET_KEY to verify webhook requests, and an application secret for other session or signing behavior. The installation guidance warns that changing the first two keys breaks existing connections and flows. That makes key ownership a recovery problem as well as a confidentiality problem.

Keep the encryption key out of the application database and out of the same backup set unless the backup is protected with a separate control. The webhook secret should be long, unique per deployment, and unavailable to public browser code. An operator should know how to rotate each key, which data becomes unreadable after rotation, and how to test the webhook verifier before exposing a production flow.

The main and worker services share the same image and need the same environment. A worker with an overly broad database account or access to every secret increases the blast radius of a malicious or compromised integration. Review which service can execute flows, which can decrypt credentials, and whether a test deployment uses the production database.

Inventory executions, not only pages

List the connected services, credential owners, webhook URLs, schedules, and flow owners. Test a webhook with an invalid signature and confirm that no flow executes. Test a valid event twice and decide whether the flow is idempotent. Inspect execution logs for credential values and customer data. A workflow tool often records request bodies and error messages that contain secrets from the downstream service.

The exact title count is useful for finding candidates, not for assigning risk. Confirm ownership before sending any request. Then review the exposed URL, version, authentication configuration, key custody, worker scope, and disabled flows. A deployment can encrypt every credential and still be unsafe if anyone who reaches the database can recover the key.

References

Top comments (0)