# Securing plugins

## using 3rd party code

Plugins introduce a third-party dependency in your pipeline. They provide a way to introduce executable code into your pipeline beyond scripts in your repository and access to the `pipeline.yml`.

## Recommended security practices

To keep your code and pipelines as secure as possible, we recommended the following best practices:

 * Always pin to a particular version of a plugin i.e. `docker-compose#287293c4`. You can pin to any type of git ref. The agent will check out the specified ref the first time it encounters the plugin, and will re-use the checked out code when you next reference the plugin.
 * Follow the [Unofficial Bash Strict Mode](http://redsymbol.net/articles/unofficial-bash-strict-mode/) and check your work with [shellcheck](https://github.com/koalaman/shellcheck).
 * Apply special care to avoid executing arbitrary code passed in to plugins by config. As these are just environment variables, anything that can set environment variables can mess with plugin configuration.
 * Don't put secrets directly into your pipelines, always use an Agent hook or a parameter store. For more information, see the [Managing Secrets guide](/docs/pipelines/secrets). 

In high-security environments you can disable plugins selectively by removing them from the `BUILDKITE_PLUGINS` variable in your `environment` hook. To disable plugins entirely, agents can be run with the `--no-plugins` flag.

# Securing plugins

Plugins introduce a third-party dependency to your pipeline. They provide a way to introduce executable code into your pipeline, beyond scripts in your repository, and have access to the `pipeline.yml` file. Any plugins not written by you should be assessed for risks prior to use in your pipeline. 

For more detailed suggestions on keeping your pipeline secure, see the recommendations below.

## Recommended security practices

To keep your code and pipelines as secure as possible, we recommended the following best practices:

 * Always pin to a particular version of a plugin i.e. `docker-compose#287293c4`. You can pin to any type of git ref. The agent will check out the specified ref the first time it encounters the plugin, and will re-use the checked out code when you next reference the plugin.
 * Follow the [Unofficial Bash Strict Mode](http://redsymbol.net/articles/unofficial-bash-strict-mode/) and check your work with [shellcheck](https://github.com/koalaman/shellcheck).
 * Apply special care to avoid executing arbitrary code passed in to plugins by config. As these are just environment variables, anything that can set environment variables can mess with plugin configuration.
 * Don't put secrets directly into your pipelines, always use an Agent hook or a parameter store. For more information, see the [Managing Secrets guide](/docs/pipelines/secrets). 

In high-security environments you can disable plugins selectively by removing them from the `BUILDKITE_PLUGINS` variable in your `environment` hook. To disable plugins entirely, agents can be run with the `--no-plugins` flag.

Make 3rd party section into intro
Make 3rd party section into intro
