Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 41 additions & 41 deletions _articles/es/security-best-practices-for-your-project.md
Original file line number Diff line number Diff line change
@@ -1,84 +1,84 @@
---
lang: es
untranslated: true
title: Security Best Practices for your Project
description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
title: Buenas prácticas de seguridad para tu proyecto
description: Fortalece el futuro de tu proyecto generando confianza mediante prácticas esenciales de seguridad — desde la autenticación multifactor (MFA) y el análisis de código hasta la gestión segura de dependencias y la notificación privada de vulnerabilidades.
class: security-best-practices
order: -1
image: /assets/images/cards/security-best-practices.png
---

Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
Dejando de lado los errores y las nuevas funciones, la longevidad de un proyecto depende no solo de su utilidad, sino también de la confianza que gane de sus usuarios. Mantener esa confianza requiere contar con sólidas medidas de seguridad. A continuación, se presentan algunas acciones importantes que puedes tomar para mejorar significativamente la seguridad de tu proyecto.

## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
## Asegúrate de que todos los colaboradores con privilegios hayan activado la autenticación multifactor (MFA).

### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
### Un actor malicioso que logre hacerse pasar por un colaborador con privilegios en tu proyecto causará daños catastróficos.

Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
Una vez que obtienen el acceso con privilegios, este actor puede modificar tu código para que realice acciones no deseadas (por ejemplo, minar criptomonedas), distribuir malware en la infraestructura de tus usuarios, o acceder a repositorios de código privados para extraer propiedad intelectual y datos sensibles, incluyendo credenciales de otros servicios.

MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
La autenticación multifactor (MFA) ofrece una capa adicional de seguridad contra la toma de control de cuentas. Una vez activada, debes iniciar sesión con tu nombre de usuario y contraseña y proporcionar otra forma de autenticación que solo tú conozcas o a la que tengas acceso.

## Secure your code as part of your development workflow
## Asegura tu código como parte de tu flujo de trabajo de desarrollo.

### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
### Las vulnerabilidades de seguridad en tu código son más baratas de corregir si se detectan temprano en el proceso, que más tarde, cuando ya se encuentran en producción.

Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
Utiliza una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) para detectar vulnerabilidades de seguridad en tu código. Estas herramientas operan a nivel de código y no necesitan un entorno de ejecución; por lo tanto, pueden ejecutarse temprano en el proceso y pueden integrarse de manera fluida en tu flujo de trabajo de desarrollo habitual, ya sea durante la fase de compilación o durante la revisión de código.

It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
Es como tener a un experto capacitado revisando tu repositorio de código, ayudándote a encontrar vulnerabilidades de seguridad comunes que podrían estar ocultas a simple vista mientras programas.

How to choose your SAST tool?
Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
Check the coverage for your language(s)
Cómo elegir tu herramienta SAST?
Revisa la licencia: Algunas herramientas son gratuitas para proyectos de código abierto. Por ejemplo, GitHub CodeQL o SemGrep.
Verifica la cobertura para tu(s) lenguaje(s)

* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
* Beware of False Positives! You don't want the tool to slow you down for no reason!
* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
* Selecciona una que se integre fácilmente con las herramientas que ya usas y con tu proceso existente. Por ejemplo, es mejor que las alertas estén disponibles como parte de tu proceso y herramienta de revisión de código actual, en lugar de tener que ir a otra herramienta para verlas.
* ¡Cuidado con los falsos positivos! No quieres que la herramienta te haga perder tiempo innecesariamente.
* Revisa las funcionalidades: algunas herramientas son muy potentes y pueden realizar seguimiento de flujo de datos (taint tracking, por ejemplo, GitHub CodeQL), otras ofrecen sugerencias de corrección generadas por IA, y algunas facilitan la creación de consultas personalizadas (por ejemplo, SemGrep).

## Don't share your secrets
## No compartas tus credenciales ni secretos de desarrollo.

### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
### Los datos sensibles, como claves de API, tokens y contraseñas, a veces pueden terminar accidentalmente comprometidos en tu repositorio.

Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
Imagina este escenario: eres el mantenedor de un proyecto de código abierto popular, con contribuciones de desarrolladores de todo el mundo. Un día, un colaborador, sin darse cuenta, comete en el repositorio algunas claves de API de un servicio de terceros. Días después, alguien encuentra estas claves y las utiliza para acceder al servicio sin permiso. El servicio se ve comprometido, los usuarios de tu proyecto experimentan interrupciones y la reputación de tu proyecto se ve afectada. Como mantenedor, ahora te enfrentas a las abrumadoras tareas de revocar los secretos comprometidos, investigar qué acciones maliciosas podría haber realizado el atacante con estos secretos, notificar a los usuarios afectados e implementar soluciones.

To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
Para prevenir este tipo de incidentes, existen soluciones de "escaneo de secretos" que te ayudan a detectar esos secretos en tu código. Algunas herramientas, como GitHub Secret Scanning y Trufflehog de Truffle Security, pueden impedir que los subas a ramas remotas desde el principio, y otras herramientas pueden revocar automáticamente algunos secretos por ti.

## Check and update your dependencies
## Revisa y actualiza tus dependencias.

### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
### Las dependencias de tu proyecto pueden tener vulnerabilidades que comprometan la seguridad del mismo. Mantenerlas actualizadas de manera manual puede ser una tarea que consume mucho tiempo.

Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
Imagina esto: un proyecto construido sobre la sólida base de una biblioteca muy utilizada. Más tarde, la biblioteca descubre un gran problema de seguridad, pero las personas que desarrollaron la aplicación que la utiliza no lo saben. Los datos sensibles de los usuarios quedan expuestos cuando un atacante aprovecha esta vulnerabilidad para acceder a ellos. Esto no es un caso teórico: es exactamente lo que le ocurrió a Equifax en 2017. No actualizaron su dependencia de Apache Struts después de recibir la notificación de una vulnerabilidad grave. Esta fue explotada, y la famosa brecha de seguridad de Equifax afectó los datos de 144 millones de usuarios.

To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
Para prevenir estos escenarios, las herramientas de Análisis de Composición de Software (SCA), como Dependabot y Renovate, revisan automáticamente tus dependencias en busca de vulnerabilidades conocidas publicadas en bases de datos públicas como la NVD o la GitHub Advisory Database, y luego crean solicitudes de extracción (pull requests) para actualizarlas a versiones seguras. Mantenerse al día con las últimas versiones seguras de las dependencias protege tu proyecto de posibles riesgos.

## Avoid unwanted changes with protected branches
## Evita cambios no deseados con ramas protegidas.

### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
### El acceso sin restricciones a tus ramas principales puede provocar cambios accidentales o maliciosos que introduzcan vulnerabilidades o afecten la estabilidad de tu proyecto.

A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
Un nuevo colaborador obtiene acceso de escritura a la rama principal y accidentalmente sube cambios que no han sido probados. Como resultado, se descubre una grave falla de seguridad debido a estos últimos cambios. Para prevenir este tipo de problemas, las reglas de protección de ramas aseguran que no se puedan subir o fusionar cambios en ramas importantes sin antes someterlos a revisiones y pasar los controles de estado especificados. Con esta medida adicional, tu proyecto está más seguro y garantiza calidad de primera en todo momento.

## Set up an intake mechanism for vulnerability reporting
## Configura un mecanismo de recepción para el reporte de vulnerabilidades.

### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
### Es una buena práctica facilitar a tus usuarios el reporte de errores, pero la gran pregunta es: cuando este error tiene un impacto en la seguridad, ¿cómo pueden reportarlo de manera segura sin exponerte como objetivo a hackers maliciosos?

Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
Imagina esto: un investigador de seguridad descubre una vulnerabilidad en tu proyecto, pero no encuentra una forma clara o segura de reportarla. Sin un proceso designado, podría crear un issue público o comentarlo abiertamente en redes sociales. Incluso si tiene buenas intenciones y propone una solución, si lo hace mediante un pull request público, ¡otros lo verán antes de que se fusione! Esta divulgación pública expondrá la vulnerabilidad a actores maliciosos antes de que tengas oportunidad de solucionarla, lo que podría derivar en un exploit de día cero, atacando tu proyecto y a sus usuarios.

### Security Policy
### Política de Seguridad

To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at [email protected]", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
Para evitar esto, publica una política de seguridad. Una política de seguridad, definida en un archivo SECURITY.md, detalla los pasos para reportar problemas de seguridad, creando un proceso transparente de divulgación coordinada y estableciendo las responsabilidades del equipo del proyecto para atender los problemas reportados. Esta política de seguridad puede ser tan simple como: "Por favor, no publiques detalles en un issue o PR público; envíanos un correo privado a [email protected]", pero también puede incluir otros detalles, como el tiempo estimado de respuesta. Cualquier información que ayude a mejorar la efectividad y eficiencia del proceso de divulgación es recomendable.

### Private Vulnerability Reporting
### Reporte privado de vulnerabilidades.

On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
En algunas plataformas, puedes agilizar y fortalecer tu proceso de gestión de vulnerabilidades, desde la recepción hasta la divulgación, utilizando issues privados. En GitLab, esto se logra con issues privados. En GitHub, se denomina reporte privado de vulnerabilidades (PVR, por sus siglas en inglés). El PVR permite a los mantenedores recibir y atender los reportes de vulnerabilidades, todo dentro de la plataforma de GitHub. GitHub crea automáticamente un fork privado para desarrollar las correcciones y un borrador de aviso de seguridad. Todo esto permanece confidencial hasta que decidas divulgar los problemas y publicar las correcciones. Para cerrar el ciclo, los avisos de seguridad se publicarán, informando y protegiendo a todos tus usuarios a través de su herramienta de SCA.

## Conclusion: A few steps for you, a huge improvement for your users
## Conclusión: unos pocos pasos para ti, una gran mejora para tus usuarios.

These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
Estos pocos pasos pueden parecerte sencillos o básicos, pero son muy efectivos para hacer tu proyecto más seguro para sus usuarios, ya que ofrecen protección frente a los problemas más comunes.

## Contributors
## Colaboradores

### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
### Muchas gracias a todos los mantenedores que compartieron sus experiencias y consejos con nosotros para esta guía!

This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
Esta guía fue escrita por [@nanzggits](https://github.com/nanzggits) y [@xcorail](https://github.com/xcorail) con contribuidores de:

[@JLLeitschuh](https://github.com/JLLeitschuh)
[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
[@intrigus-lgtm](https://github.com/intrigus-lgtm) !y muchos mas!
Loading