Security Best Practices

Kyuda implements a range of privacy and security measures meant to protect your data from unauthorised access. Since Kyuda's pipelines, sources, and other resources can run any NodeJS, Python, Go or Bash code and process any event data, you also have a responsibility to ensure you handle that code and data securely.

We've outlined a handful of best practices for you.

Store Secrets in Accounts or Environment Variables

Even if your pipeline code is private, you should never store secrets like API keys in code. These secrets should be stored in one of two ways:

• If Kyuda integrates the with app, use connected accounts to link the app / API.

• If Kyuda doesn't integrates the with app, use environment variables.

Transfer Data Securely

Whenever possible, encrypt data in transit to Kyuda (e.g. use HTTPS endpoints when sending HTTP traffic to a pipeline). When you connect to APIs in a pipeline, or deliver data to third-party destinations, encrypt that data in transit (e.g. use HTTPS endpoints when sending HTTP traffic to third parties).

Add Authentication to Incoming Event Data

You can add many public-facing triggers to your pipelines. For example, when you add an HTTP trigger to your pipeline, anyone with the associated trigger URL can invoke it. You should protect your pipeline with an authentication mechanism like Basic Auth, JWT, or others.

This pattern is typical for protecting pipelines: add the authentication logic in a step at the top of your pipeline, ending early if auth fails. If auth succeeds, Kyuda runs the remaining steps of your pipeline.

Validate Signatures for Incoming Events, Where Available

Many apps pass a signature with event data delivered via webhooks (or other push delivery systems). The signature is an opaque value computed from the incoming event data and a secret that only you and the app know. When you receive the event, you can validate the signature by computing it yourself and comparing it to the signature sent by the app. If the two values match, it verifies that the app sent the data, and not some third party.

Signatures are specific to the app sending the data, and the app should provide instructions for signature validation. Not all apps compute signatures, but when they do, you should always verify them.

When you use a Kyuda source as your pipeline trigger, Kyuda should verify the signature. You can always audit the code behind the event source to confirm this, and suggest further security improvements that you find.

See Stripe's signature docs for a real-world example.

Audit Code or Packages you Use

Kyuda pipeline are just code. Kyuda provides prebuilt triggers and actions that facilitate common use cases, but these are written and run as code within your pipeline. You can examine and modify this code in any way you'd like.

This also means that you can audit the code for any triggers or actions you use in your pipeline. We encourage this as a best practice. Even code authored by Kyuda can be improved, and if you notice a vulnerability or other issue, you can submit a patch or raise an issue.

The same follows for npm packages. Before you use a new npm package in your pipeline, review its page on npm and its repo, if available. Good packages should have recent updates. The package should have a healthy number of downloads and related activity (like GitHub stars), and the package author should be responsive to issues raised by the community. If you don't observe these signals, be wary of using the package in your pipeline.

Limit What You Log and Return From Steps

Kyuda retains a limited history of event data and associated logs for event sources and pipelines. If you cannot log specific data in Kyuda for privacy or security reasons, or if you want to limit risk, remember that Kyuda only stores data returned from or logged in steps. Specifically, Kyuda will only store:

• The event data emitted from event sources, and any console logs / errors

• The event data that triggers your pipeline, any console logs / errors, step exports, and any data included in error stack traces.

Variables stored in memory that aren't logged or returned from steps are not included in Kyuda logs. Since you can modify any code in your Kyuda pipeline, if you want to limit what gets logged from a Kyuda action or other step, you can adjust the code accordingly, removing any logs or step exports.