diff --git a/pkg_security.pt.Rmd b/pkg_security.pt.Rmd
new file mode 100644
index 000000000..6ca28992b
--- /dev/null
+++ b/pkg_security.pt.Rmd
@@ -0,0 +1,86 @@
+
+# Práticas recomendadas de segurança no desenvolvimento de pacotes {#package-development-security-best-practices}
+
+```{block, type="summaryblock"}
+Este capítulo em desenvolvimento inclui [orientações sobre o gerenciamento de credenciais em pacotes] (#pkgsecrets), além de [links para leituras complementares] (#furthersecreading).
+```
+
+## Diversos {#miscellaneous}
+
+Recomendamos a leitura do artigo [Dez dicas rápidas para você se manter seguro on-line](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008563), de Danielle Smalls e Greg Wilson.
+
+## Segurança no acesso ao GitHub {#git-hub-access-security}
+
+- Recomendamos que você [proteja sua conta do GitHub com uma autenticação 2FA (autenticação de dois fatores)](https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/). Essa medida é *obrigatória* para todos os membros da organização ropensci e colaboradores externos que usam GitHub, portanto, certifique-se de ativá-la antes que seu pacote seja aprovado.
+
+- Também recomendamos que você verifique regularmente quem tem acesso ao repositório do seu pacote e remova qualquer acesso não utilizado (como o de antigos colaboradores).
+
+## https {#https}
+
+- Se o serviço Web que seu pacote utiliza oferecer tanto https quanto http, opte por https.
+
+## Segredos em pacotes {#pkgsecrets}
+
+Esta seção oferece orientações para quando você desenvolve pacotes que interagem com recursos da Web que exigem credenciais (como chaves de API, tokens, etc.). Consulte também [a vignette do pacote `httr` sobre compartilhamento de credenciais](https://httr.r-lib.org/articles/secrets.html).
+
+### Credenciais em pacotes e proteção do usuário {#secrets-in-packages-and-user-protection}
+
+Digamos que seu pacote precise de uma chave de API para fazer solicitações em nome dos(as) usuários(as) do seu pacote.
+
+- Na documentação do seu pacote, oriente o(a) usuário(a) para que a chave de API não seja registrada no arquivo .Rhistory ou no script dos(as) usuários(as) do seu pacote.
+  
+  - Incentive o uso de variáveis de ambiente para armazenar a chave da API (ou até mesmo remova a possibilidade de passá-la como um argumento para as funções). Você pode, na documentação, fazer referência a [introdução aos arquivos de inicialização](https://rstats.wtf/r-startup.html) e a função [`usethis::edit_r_environ()`](https://usethis.r-lib.org/reference/edit.html).
+  
+- Ou seu pacote pode depender ou incentivar o uso de [`keyring` para ajudar o(a) usuário(a) a armazenar variáveis](https://github.com/r-lib/keyring#readme) nos gerenciadores de credenciais específicos do sistema operacional (mais seguro do que .Renviron), ou seja, você criaria uma função para definir a chave e teria outra para recuperá-la; ou o(a) usuário(a) escreveria `Sys.setenv(SUPERSECRETKEY = keyring::key_get("myservice"))` no início de seu script.
+  
+  - Não imprima a chave da API, nem mesmo no modo verbose, em nenhuma mensagem, aviso ou erro.
+
+- No modelo de issues do GitHub, deve ser declarado que nenhuma credencial deve ser compartilhada. Se um(a) usuário(a) do seu pacote compartilhar acidentalmente as credenciais em uma issue, certifique-se de que ele(a) esteja ciente disso para que possa revogar a chave (ou seja, pergunte explicitamente, em uma resposta, se ele percebeu que compartilhou a chave).
+
+### Credenciais em pacotes e desenvolvimento {#secrets-in-packages-and-development}
+
+Você precisará proteger suas credenciais da mesma forma que protege as credenciais dos(as) usuários(as), mas há mais aspectos a serem considerados e mantidas em mente.
+
+#### Credenciais e solicitações registradas em testes {#secrets-and-recorded-requests-in-tests}
+
+Se você utiliza [`vcr`](https://docs.ropensci.org/vcr/) ou [`httptest`](https://enpiar.com/r/httptest/) em testes para armazenar as respostas da API em cache, é importante garantir que as requisições ou configurações registradas não contenham credenciais. Consulte [o guia de segurança do pacote `vcr`](https://books.ropensci.org/http-testing/security-chapter.html) e [o guia do pacote `httptest` "Redigindo e modificando requisições registradas"](https://enpiar.com/r/httptest/articles/redacting.html). Além disso, inspecione suas requisições gravadas ou configurações antes de realizar o primeiro commit para garantir que você fez a configuração correta.
+
+Como o `vcr` é um pacote da rOpenSci, você pode postar qualquer dúvida que tiver no [Fórum da rOpenSci](https://discuss.ropensci.org/).
+
+#### Compartilhe credenciais com os serviços de CI {#share-secrets-with-ci-services}
+
+Agora, você pode precisar compartilhar credenciais com [serviços de integração contínua](#ci).
+
+Você pode armazenar as chaves de API como variáveis de ambiente ou credenciais, consultando a documentação do serviço de CI.
+
+Para obter mais detalhes e orientações sobre o fluxo de trabalho, consulte [o artigo do pacote gargle - "Gerenciando tokens com segurança"](https://gargle.r-lib.org/articles/articles/managing-tokens-securely.html) e o [capítulo sobre segurança do livro HTTP testing in R](https://books.ropensci.org/http-testing/security-chapter.html).
+
+Documente as etapas que você fez em [CONTRIBUINDO.md](#friendlyfiles) para que você, ou um novo mantenedor, possa se lembrar como proceder da próxima vez.
+
+#### Credenciais e colaborações {#secrets-and-collaborations}
+
+E quanto a pull requests de colaboradores externos?
+No GitHub, por exemplo, as credenciais só estão disponíveis para GitHub Actions em pull requests iniciados a partir do próprio repositório, e não a partir de um fork.
+Os testes que usam suas credenciais falharão, a menos que você use algum tipo de resposta simulada ou em cache, portanto, pode ser interessante ignorá-los dependendo do contexto.
+Por exemplo, na sua conta de CI, você poderia criar uma variável de ambiente chamada `THIS_IS_ME` e, então, ignorar os testes com base na presença dessa variável.
+ Isso significa, portanto, que as verificações de PR feitas pela CI não serão exaustivas e, como consequência, você precisará verificar o PR localmente para executar todos os testes.
+
+Documente o comportamento do seu pacote em relação a PRs externos no arquivo [CONTRIBUTING.md](#friendlyfiles). Isso será útil tanto para quem faz PRs quanto para quem os revisa, seja você no futuro ou outros mantenedores do pacote.
+
+### Credenciais e CRAN {#secrets-and-cran}
+
+No CRAN, ignore quaisquer testes (`skip_on_cran()`) e exemplos (`dontrun`) que exijam credenciais.
+
+[Gere previamente as vignettes](https://ropensci.org/technotes/2019/12/08/precompute-vignettes/) que requerem credenciais.
+
+## Leitura adicional {#furthersecreading}
+
+Materiais úteis sobre segurança:
+
+- [a sessão da comunidade rOpenSci "Segurança para R"](https://ropensci.org/commcalls/2019-05-07/) (veja a gravação, slides, etc. e, em particular, [a lista de recursos](https://ropensci.org/blog/2019/04/09/commcall-may2019/#resources));
+
+- [os projetos relacionados à segurança do unconf18](https://ropensci.org/blog/2018/06/06/unconf18_recap_2/);
+
+- [artigo do pacote `gargle` "Gerenciando tokens de forma segura"](gargle.r-lib.org/articles/articles/managing-tokens-securely.html)
+
+