diff --git a/_articles/bg/security-best-practices-for-your-project.md b/_articles/bg/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..c1dd5f06a3f
--- /dev/null
+++ b/_articles/bg/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: bg
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/bn/security-best-practices-for-your-project.md b/_articles/bn/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..6fd0533b9da
--- /dev/null
+++ b/_articles/bn/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: bn
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/de/security-best-practices-for-your-project.md b/_articles/de/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..203d300298c
--- /dev/null
+++ b/_articles/de/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: de
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/el/security-best-practices-for-your-project.md b/_articles/el/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..8d1b80b51ca
--- /dev/null
+++ b/_articles/el/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: el
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/es/security-best-practices-for-your-project.md b/_articles/es/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..f7ea2bd134e
--- /dev/null
+++ b/_articles/es/security-best-practices-for-your-project.md
@@ -0,0 +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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/fa/security-best-practices-for-your-project.md b/_articles/fa/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..bcff793b68d
--- /dev/null
+++ b/_articles/fa/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: fa
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/fr/security-best-practices-for-your-project.md b/_articles/fr/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a048e13edcc
--- /dev/null
+++ b/_articles/fr/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: fr
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/hi/security-best-practices-for-your-project.md b/_articles/hi/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..386adeb8765
--- /dev/null
+++ b/_articles/hi/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: hi
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/hu/security-best-practices-for-your-project.md b/_articles/hu/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..b1bfd9df2ae
--- /dev/null
+++ b/_articles/hu/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: hu
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/id/security-best-practices-for-your-project.md b/_articles/id/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..1fbb5b55d11
--- /dev/null
+++ b/_articles/id/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: id
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/it/security-best-practices-for-your-project.md b/_articles/it/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..13026ec4831
--- /dev/null
+++ b/_articles/it/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: it
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ja/security-best-practices-for-your-project.md b/_articles/ja/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..7be942d99e7
--- /dev/null
+++ b/_articles/ja/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: ja
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ko/security-best-practices-for-your-project.md b/_articles/ko/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..5ddcd1a1380
--- /dev/null
+++ b/_articles/ko/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: ko
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ms/security-best-practices-for-your-project.md b/_articles/ms/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..0440ac47a65
--- /dev/null
+++ b/_articles/ms/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: ms
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/nl/security-best-practices-for-your-project.md b/_articles/nl/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..40b31985e9e
--- /dev/null
+++ b/_articles/nl/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: nl
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/pcm/security-best-practices-for-your-project.md b/_articles/pcm/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..424d1b04180
--- /dev/null
+++ b/_articles/pcm/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: pcm
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/pl/security-best-practices-for-your-project.md b/_articles/pl/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..3c7249de79e
--- /dev/null
+++ b/_articles/pl/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: pl
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/pt/security-best-practices-for-your-project.md b/_articles/pt/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..f8601c9b41b
--- /dev/null
+++ b/_articles/pt/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: pt
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ro/security-best-practices-for-your-project.md b/_articles/ro/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..b3ee8ac0fc1
--- /dev/null
+++ b/_articles/ro/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: ro
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ru/security-best-practices-for-your-project.md b/_articles/ru/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..cb4921815bc
--- /dev/null
+++ b/_articles/ru/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: ru
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/sw/security-best-practices-for-your-project.md b/_articles/sw/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..b4ad2295148
--- /dev/null
+++ b/_articles/sw/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: sw
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
index 82aaf08e79a..43cd8312dee 100644
--- a/_articles/ta/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
@@ -1,186 +1,185 @@
 ---
 lang: ta
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: திறந்த மூல பராமரிப்பாளர்களுக்கு சமநிலையை பராமரித்தல்
+description: சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது.
 class: balance
 order: 0
 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
 ---
 
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. 
+ஒரு திறந்த மூல திட்டம் பிரபலமடைந்து வருவதால், நீண்ட காலத்திற்கு புத்துணர்ச்சியுடனும், உற்பத்தித்திறனாகவும் இருக்க சமநிலையை பராமரிக்க உங்களுக்கு உதவ தெளிவான எல்லைகளை அமைப்பது முக்கியம். 
 
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+பராமரிப்பாளர்களின் அனுபவங்கள் மற்றும் சமநிலையைக் கண்டுபிடிப்பதற்கான அவர்களின் உத்திகள் பற்றிய நுண்ணறிவுகளைப் பெற, <a href="http://maintainers.github.com/"> பராமரிப்பாளர் சமூகம் </a> இன் 40 உறுப்பினர்களுடன் நாங்கள் ஒரு பட்டறையை நடத்தினோம், இது திறந்த மூலத்தில் எரியும் மற்றும் அவர்களின் பணிகளைத் தக்கவைத்துக் கொள்ள உதவிய நடைமுறைகளுடனான அவர்களின் மோசமான அனுபவங்களிலிருந்து கற்றுக்கொள்ள அனுமதிக்கிறது. தனிப்பட்ட சூழலியல் கருத்து நடைமுறைக்கு வருகிறது.
 
-So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+தனிப்பட்ட சூழலியல் என்றால் என்ன? <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">ராக்வுட் தலைமைத்துவ நிறுவனத்தால் விவரிக்கப்பட்ட</a>, இது "<strong>வாழ்நாள் முழுவதும் நமது ஆற்றலைத் தக்கவைக்க சமநிலை, வேகம் மற்றும் செயல்திறனைப் பராமரித்தல்</strong>" ஆகியவற்றை உள்ளடக்கியது. இது எங்கள் உரையாடல்களை வடிவமைத்து, பராமரிப்பாளர்கள் தங்கள் செயல்களையும் பங்களிப்புகளையும் காலப்போக்கில் உருவாகும் ஒரு பெரிய சுற்றுச்சூழல் அமைப்பின் பகுதிகளாக அங்கீகரிக்க உதவுகிறது. [WHO ஆல் வரையறுக்கப்பட்டுள்ளது](https://icd.who.int/browse/2025-01/foundation/en#129180281) நாள்பட்ட பணியிட மன அழுத்தத்தின் விளைவாக ஏற்படும் ஒரு நோய்க்குறியான எரிதல், பராமரிப்பாளர்களிடையே அசாதாரணமானது அல்ல. இது பெரும்பாலும் உந்துதல் இழப்பு, கவனம் செலுத்த இயலாமை மற்றும் நீங்கள் பணிபுரியும் பங்களிப்பாளர்கள் மற்றும் சமூகத்தின் மீது பச்சாதாபம் இல்லாததற்கு வழிவகுக்கிறது.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
-  I was unable to focus or start on a task. I had a lack of empathy for users.
+  என்னால் ஒரு பணியில் கவனம் செலுத்தவோ தொடங்கவோ முடியவில்லை. பயனர்களுக்கு பச்சாத்தாபம் இல்லாதது எனக்கு.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, தனது திறந்த மூல வேலைகளில் எரித்தலின் தாக்கம் குறித்து, Owncast live streaming server பராமரிப்பவர்
   </p>
 </aside>
 
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+தனிப்பட்ட சூழலியல் கருத்தை ஏற்றுக்கொள்வதன் மூலம், பராமரிப்பாளர்கள் எரியைத் தவிர்க்கலாம், சுய பாதுகாப்புக்கு முன்னுரிமை அளிக்கலாம், மேலும் அவர்களின் சிறந்த வேலையைச் செய்ய சமநிலை உணர்வை நிலைநிறுத்தலாம்.
 
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது:
 
-### Identify your motivations for working in open source
+### திறந்த மூலத்தில் பணியாற்றுவதற்கான உங்கள் உந்துதல்களை அடையாளம் காணவும்
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+திறந்த மூல பராமரிப்பின் எந்த பகுதிகள் உங்களை உற்சாகப்படுத்துகின்றன என்பதைப் பிரதிபலிக்க நேரம் ஒதுக்குங்கள். உங்கள் உந்துதல்களைப் புரிந்துகொள்வது, உங்கள் ஈடுபாட்டையும் புதிய சவால்களுக்கும் தயாராக இருக்கும் வகையில் வேலைக்கு முன்னுரிமை அளிக்க உதவும். இது பயனர்களிடமிருந்து நேர்மறையான பின்னூட்டமாக இருந்தாலும், சமூகத்துடன் ஒத்துழைப்பதற்கும் சமூகமயமாக்குவதன் மகிழ்ச்சியும் அல்லது குறியீட்டில் டைவிங் செய்வதன் திருப்தி, உங்கள் உந்துதல்களை அங்கீகரிப்பது உங்கள் கவனத்தை வழிநடத்த உதவும்.
 
-### Reflect on what causes you to get out of balance and stressed out
+### நீங்கள் சமநிலையிலிருந்து வெளியேறவும், வலியுறுத்தவும் என்ன காரணம் என்பதைப் பற்றி சிந்தியுங்கள்
 
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+நாம் எரிக்கப்படுவதற்கு என்ன காரணம் என்பதைப் புரிந்துகொள்வது முக்கியம். திறந்த மூல பராமரிப்பாளர்களிடையே நாங்கள் கண்ட சில பொதுவான கருப்பொருள்கள் இங்கே:
 
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+* **நேர்மறையான கருத்துக்கள் இல்லாதது:** பயனர்கள் புகார் இருக்கும்போது அடைய அதிக வாய்ப்புள்ளது. எல்லாம் நன்றாக வேலை செய்தால், அவர்கள் அமைதியாக இருக்க முனைகிறார்கள். உங்கள் பங்களிப்புகள் எவ்வாறு வித்தியாசத்தை ஏற்படுத்துகின்றன என்பதைக் காட்டும் நேர்மறையான பின்னூட்டமின்றி வளர்ந்து வரும் சிக்கல்களின் பட்டியலைக் காண்பது ஊக்கமளிக்கும்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
-  Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+  சில நேரங்களில் அது வெற்றிடத்தை கத்துவது போல உணர்கிறது, மேலும் கருத்து என்னை மிகவும் உற்சாகப்படுத்துகிறது என்பதை நான் காண்கிறேன். எங்களுக்கு நிறைய மகிழ்ச்சியான ஆனால் அமைதியான பயனர்கள் உள்ளனர்.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+— <a href="https://github.com/thisisnic">@thisisnic</a>, Apache Arrow பராமரிப்பவர்
   </p>
 </aside>
 
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+* **'இல்லை' என்று சொல்லவில்லை:** திறந்த மூல திட்டத்தில் நீங்கள் செய்ய வேண்டியதை விட அதிக பொறுப்புகளை ஏற்றுக்கொள்வது எளிதானது. இது பயனர்கள், பங்களிப்பாளர்கள் அல்லது பிற பராமரிப்பாளர்களிடமிருந்து வந்தாலும் - நாங்கள் எப்போதும் அவர்களின் எதிர்பார்ப்புகளுக்கு ஏற்ப வாழ முடியாது.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
-  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  FOSS-ல் பொதுவாக செய்யப்படுவது போல, ஒன்றுக்கு மேற்பட்ட வேண்டுகோளுக்கு நான் எடுத்துக்கொள்வதையும், பல நபர்களின் வேலையைச் செய்ய வேண்டியதையும் நான் கண்டேன்.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, Termux பராமரிப்பவர், அவர்களின் வேலையில் எரிவதற்கு என்ன காரணம்
   </p>
 </aside>
 
-* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+* **தனியாக வேலை செய்வது:** ஒரு பராமரிப்பாளராக இருப்பது முற்றிலும் தனிமையாக உணர முடியும். நீங்கள் பராமரிப்பாளர்களின் குழுவுடன் பணிபுரிந்திருந்தாலும், கடந்த சில ஆண்டுகளில் விநியோகிக்கப்பட்ட அணிகளை ஒன்றிணைப்பது கடினம்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+  குறிப்பாக கோவிட் (COVID) மற்றும் வீட்டிலிருந்து வேலை செய்வதால், யாரையும் ஒருபோதும் பார்க்கவோ அல்லது யாருடனும் பேசுவது கடினம்.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— <a href="https://github.com/gabek">@gabek</a>, தனது திறந்த மூல வேலைகளில் எரித்தலின் தாக்கம் குறித்து, Owncast live streaming server பராமரிப்பவர்
   </p>
 </aside>
 
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **போதுமான நேரம் அல்லது வளங்கள் இல்லை:** ஒரு திட்டத்தில் பணியாற்ற தங்கள் இலவச நேரத்தை தியாகம் செய்ய வேண்டிய தன்னார்வ பராமரிப்பாளர்களுக்கு இது குறிப்பாக உண்மை.
 
 <aside markdown="1" class="pquote">
-  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  [எனக்கு] அதிக நிதி உதவி வேண்டும், இதனால் எனது சேமிப்பை வீணாக்காமல் திறந்த மூல வேலைகளில் கவனம் செலுத்த முடியும், பின்னர் அதை ஈடுசெய்ய நான் நிறைய ஒப்பந்தங்களைச் செய்ய வேண்டியிருக்கும் என்பதை அறிந்தும்.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— திறந்த மூல பராமரிப்பாளர்
   </p>
 </aside>
 
-* **Conflicting demands:**  Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+* **முரண்பட்ட கோரிக்கைகள்:**  திறந்த மூலக் குழுக்கள் பல்வேறு நோக்கங்களைக் கொண்ட குழுக்களால் நிறைந்துள்ளன, அவற்றை வழிநடத்துவது கடினமாக இருக்கலாம். திறந்த மூலக் குழுவில் பணியாற்ற உங்களுக்கு பணம் வழங்கப்பட்டால், உங்கள் முதலாளியின் நலன்கள் சில நேரங்களில் சமூகத்துடன் முரண்படக்கூடும்.
 
 <aside markdown="1" class="pquote">
-  With paid open source, conflict between employer's focus and what's best for the community
+  திறந்த மூலத்திற்கு நாம் பணம் பெறும்போது, ​​முதலாளிகளின் கவனத்திற்கும் சமூகத்திற்கு எது சிறந்தது என்பதற்கும் இடையே மோதல் எழும்.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— திறந்த மூல பராமரிப்பாளர்
   </p>
 </aside>
 
-### Watch out for signs of burnout
+### சோர்வு அறிகுறிகளைக் கவனியுங்கள்
 
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+உங்களால் 10 வாரங்களா? 10 மாதங்களா? 10 வருடங்களா? உங்கள் வேகத்தைத் தொடர முடியுமா?
 
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+[@shaunagm](https://github.com/shaunagm) இல் உள்ள [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) போன்ற கருவிகள் உங்கள் தற்போதைய வேகத்தைப் பற்றி சிந்திக்கவும், நீங்கள் செய்யக்கூடிய ஏதேனும் மாற்றங்கள் உள்ளதா என்பதைப் பார்க்கவும் உதவும். சில பராமரிப்பாளர்கள் தூக்கத்தின் தரம் மற்றும் இதயத் துடிப்பு மாறுபாடு (இரண்டும் மன அழுத்தத்துடன் தொடர்புடையது) போன்ற அளவீடுகளைக் கண்காணிக்க அணியக்கூடிய தொழில்நுட்பத்தையும் பயன்படுத்துகின்றனர்.
 
 <aside markdown="1" class="pquote">
- I'm a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+ நான் நல்ல அணியக்கூடிய பொருட்களில் பெரிய நம்பிக்கை கொண்டவன். அதன் பின்னால் உள்ள அறிவியலைப் பயன்படுத்தி, நீங்கள் எவ்வாறு சிறப்பாகச் செய்திருக்க முடியும், நீங்கள் என்ன செய்ய விரும்புகிறீர்கள் என்பதற்கான உகந்த நிலையை எவ்வாறு அடைவது என்பதை நீங்கள் புரிந்து கொள்ளலாம்.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— திறந்த மூல பராமரிப்பாளர்
   </p>
 </aside>
 
-### What would you need to continue sustaining yourself and your community?
+### உங்களையும் உங்கள் சமூகத்தையும் தொடர்ந்து நிலைநிறுத்த உங்களுக்கு என்ன தேவை?
 
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+இது ஒவ்வொரு பராமரிப்பாளருக்கும் வித்தியாசமாகத் தோன்றும், மேலும் உங்கள் வாழ்க்கையின் கட்டம் மற்றும் பிற வெளிப்புற காரணிகளைப் பொறுத்து மாறும். ஆனால் நாங்கள் கேள்விப்பட்ட சில கருப்பொருள்கள் இங்கே:
 
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+* **சமூகத்தின் மீது சாய்ந்து கொள்ளுங்கள்.:** பங்களிப்பாளர்களையும் பிரதிநிதித்துவத்தையும் கண்டுபிடிப்பது, இதனால் பணிச்சுமையைக் குறைக்க முடியும். ஒரு திட்டத்திற்காக பல தொடர்பு புள்ளிகள் இருப்பது கவலைப்படாமல் ஓய்வு எடுக்க உதவும். [Maintainer Community](http://maintainers.github.com/) போன்ற குழுக்களில் பிற பராமரிப்பாளர்களுடனும் பரந்த சமூகத்துடனும் இணையுங்கள். சகாக்களின் ஆதரவு மற்றும் கற்றலுக்கு இது ஒரு சிறந்த ஆதாரமாக இருக்கும்.
 
-  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+  பயனர் சமூகத்துடன் ஈடுபடுவதற்கான வழிகளையும் நீங்கள் தேடலாம், இதன் மூலம் நீங்கள் தொடர்ந்து கருத்துக்களைக் கேட்கவும், உங்கள் திறந்த மூலப் பணியின் தாக்கத்தைப் புரிந்துகொள்ளவும் முடியும்.
 
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+* **நிதி தேடுங்கள்:** நீங்கள் பீட்சாவிற்கு ஸ்பான்சர் செய்ய யாரையாவது தேடினாலும் சரி, அல்லது முழுநேர ஓப்பன் சோர்ஸுக்கு மாற முயற்சித்தாலும் சரி, உதவ பல ஆதாரங்கள் உள்ளன! முதல் படியாக, உங்கள் ஓப்பன் சோர்ஸ் வேலையை மற்றவர்கள் ஸ்பான்சர் செய்ய அனுமதிக்க [GitHub ஸ்பான்சர்கள்](https://github.com/sponsors) ஐ இயக்குவதைக் கருத்தில் கொள்ளுங்கள். முழுநேரத்திற்கு முன்னேறுவது பற்றி நீங்கள் யோசித்தால், [GitHub Accelerator](http://accelerator.github.com/) இன் அடுத்த சுற்றுக்கு விண்ணப்பிக்கவும்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
- I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+ நான் சிறிது நேரத்திற்கு முன்பு ஒரு பாட்காஸ்டில் இருந்தேன், அப்போது நாங்கள் திறந்த மூல பராமரிப்பு மற்றும் நிலைத்தன்மை பற்றி பேசிக் கொண்டிருந்தோம். GitHub-இல் எனது பணியை ஒரு சிறிய எண்ணிக்கையிலான மக்கள் கூட ஆதரிப்பதைக் கண்டேன், இது விரைவான முடிவை எடுக்கவும், விளையாடுவதை விடவும், திறந்த மூலத்துடன் ஒரு சிறிய விஷயத்தைச் செய்யவும் எனக்கு உதவியது.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+— <a href="https://github.com/mansona">@mansona</a>, EmberJS பராமரிப்பாளர்
   </p>
 </aside>
 
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+* **கருவிகளைப் பயன்படுத்துங்கள்:** [GitHub Copilot](https://github.com/features/copilot/) மற்றும் [GitHub Actions](https://github.com/features/actions) போன்ற கருவிகளைப் பயன்படுத்தி சாதாரணமான பணிகளை தானியக்கமாக்கி, அர்த்தமுள்ள பங்களிப்புகளுக்கு உங்கள் நேரத்தை மிச்சப்படுத்துங்கள்.
 
 <aside markdown="1" class="pquote">
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ சலிப்பூட்டும் விஷயங்களுக்கு [Copilot](https://github.com/features/copilot/) பயன்படுத்தவும் - வேடிக்கையான விஷயங்களைச் செய்யவும்.
   <p markdown="1" class="pquote-credit">
-— open source maintainer
+— திறந்த மூல பராமரிப்பாளர்
   </p>
 </aside>
 
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+* **ஓய்வெடுத்து புத்துணர்ச்சி பெறுங்கள்:** திறந்த மூலத்தைத் தவிர்த்து உங்கள் பொழுதுபோக்குகள் மற்றும் ஆர்வங்களுக்கு நேரம் ஒதுக்குங்கள். வார இறுதி நாட்களில் ஓய்வெடுக்கவும் புத்துணர்ச்சி பெறவும் விடுமுறை எடுத்துக் கொள்ளுங்கள் - மேலும் உங்கள் கிடைக்கும் தன்மையை பிரதிபலிக்கும் வகையில் உங்கள் [GitHub நிலையை](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) அமைக்கவும்! ஒரு நல்ல இரவு தூக்கம் உங்கள் முயற்சிகளை நீண்ட காலத்திற்குத் தக்கவைத்துக்கொள்ளும் திறனில் பெரிய வித்தியாசத்தை ஏற்படுத்தும்.
 
-  If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+  உங்கள் திட்டத்தின் சில அம்சங்கள் குறிப்பாக சுவாரஸ்யமாக இருந்தால், உங்கள் வேலையை நாள் முழுவதும் அனுபவிக்கும் வகையில் கட்டமைக்க முயற்சிக்கவும்.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ மாலையில் அணைத்துவிட முயற்சிப்பதை விட, பகலின் நடுவில் 'படைப்பாற்றலின் தருணங்களை' தெளிக்க எனக்கு அதிக வாய்ப்பு கிடைக்கிறது.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+— <a href="https://github.com/danielroe">@danielroe</a>, Nuxt பராமரிப்பாளர்
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **எல்லைகளை அமைக்கவும்:** ஒவ்வொரு கோரிக்கைக்கும் நீங்கள் ஆம் என்று சொல்ல முடியாது. இது, "இப்போது என்னால் அதை அடைய முடியாது, எதிர்காலத்தில் எனக்கு எந்த திட்டமும் இல்லை" என்று சொல்வது போலவோ அல்லது README இல் நீங்கள் என்ன செய்ய விரும்புகிறீர்கள், என்ன செய்யக்கூடாது என்பதை பட்டியலிடுவது போலவோ எளிமையாக இருக்கலாம். உதாரணமாக, நீங்கள் இவ்வாறு கூறலாம்: "அவை ஏன் செய்யப்பட்டன என்பதற்கான காரணங்களை தெளிவாக பட்டியலிட்ட PRகளை மட்டுமே நான் ஒன்றிணைக்கிறேன்" அல்லது "மாற்று வியாழக்கிழமைகளில் மாலை 6 - 7 மணி வரை மட்டுமே நான் சிக்கல்களை மதிப்பாய்வு செய்கிறேன்." இது மற்றவர்களுக்கான எதிர்பார்ப்புகளை அமைக்கிறது, மேலும் உங்கள் நேரத்தில் பங்களிப்பாளர்கள் அல்லது பயனர்களிடமிருந்து வரும் தேவைகளைத் தணிக்க உதவும் வகையில் மற்ற நேரங்களில் சுட்டிக்காட்ட ஏதாவது ஒன்றை உங்களுக்கு வழங்குகிறது.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
-To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+இவற்றில் மற்றவர்களை அர்த்தமுள்ள வகையில் நம்புவதற்கு, ஒவ்வொரு கோரிக்கைக்கும் ஆம் என்று சொல்பவராக நீங்கள் இருக்க முடியாது. அவ்வாறு செய்வதன் மூலம், நீங்கள் தொழில் ரீதியாகவோ அல்லது தனிப்பட்ட முறையில்வோ எந்த எல்லைகளையும் பராமரிக்க மாட்டீர்கள், மேலும் நம்பகமான சக ஊழியராக இருக்க மாட்டீர்கள்.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, Homebrew பராமரிப்பாளர் [Saying No](https://mikemcquaid.com/saying-no/)
   </p>
 </aside>
 
-  Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+  நச்சு நடத்தை மற்றும் எதிர்மறை தொடர்புகளை நிறுத்துவதில் உறுதியாக இருக்க கற்றுக்கொள்ளுங்கள். நீங்கள் அக்கறை கொள்ளாத விஷயங்களுக்கு முயற்சி செய்யாமல் இருப்பது சரி.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
-My software is gratis, but my time and attention is not.
+ என்னுடைய மென்பொருள் இலவசம், ஆனால் என்னுடைய நேரமும் கவனமும் இலவசம் அல்ல.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, maintainer of Leaflet
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, Leaflet பராமரிப்பாளர்
   </p>
 </aside>
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
-It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.  
+திறந்த மூல பராமரிப்பு அதன் இருண்ட பக்கங்களைக் கொண்டுள்ளது என்பது இரகசியமல்ல, அவற்றில் ஒன்று சில நேரங்களில் மிகவும் நன்றியற்ற, உரிமையுள்ள அல்லது முற்றிலும் நச்சுத்தன்மையுள்ள நபர்களுடன் தொடர்பு கொள்ள வேண்டியிருக்கும். ஒரு திட்டத்தின் புகழ் அதிகரிக்கும் போது, ​​இந்த வகையான தொடர்புகளின் அதிர்வெண் அதிகரிக்கிறது, இது பராமரிப்பாளர்களால் சுமக்கப்படும் சுமையை அதிகரிக்கிறது மற்றும் பராமரிப்பாளர் சோர்வடைய ஒரு குறிப்பிடத்தக்க ஆபத்து காரணியாக மாறக்கூடும்.
   <p markdown="1" class="pquote-credit">
-— <a href="https://github.com/foosel">@foosel</a>, maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— <a href="https://github.com/foosel">@foosel</a>, Octoprint பராமரிப்பாளர் [நச்சுத்தன்மையுள்ளவர்களை எப்படி கையாள்வது](https://www.youtube.com/watch?v=7lIpP3GEyXs)
   </p>
 </aside>
 
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+நினைவில் கொள்ளுங்கள், தனிப்பட்ட சூழலியல் என்பது உங்கள் திறந்த மூல பயணத்தில் நீங்கள் முன்னேறும்போது உருவாகும் ஒரு தொடர்ச்சியான நடைமுறையாகும். சுய பாதுகாப்புக்கு முன்னுரிமை அளித்து சமநிலை உணர்வைப் பேணுவதன் மூலம், திறந்த மூல சமூகத்திற்கு நீங்கள் திறம்பட மற்றும் நிலையான முறையில் பங்களிக்க முடியும், இது உங்கள் நல்வாழ்வையும் நீண்ட காலத்திற்கு உங்கள் திட்டங்களின் வெற்றியையும் உறுதி செய்கிறது.
 
-## Additional Resources
+## கூடுதல் வளங்கள்
 
-* [Maintainer Community](http://maintainers.github.com/)
-* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [பராமரிப்பாளர் சமூகம்](http://maintainers.github.com/)
+* [திறந்த மூல சமூக ஒப்பந்தம்](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
 * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
-* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [நச்சுத்தன்மையுள்ளவர்களை எப்படி கையாள்வது](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
 * [SustainOSS](https://sustainoss.org/)
-* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [ராக்வுட்டின் தலைமைத்துவக் கலை](https://rockwoodleadership.org/art-of-leadership/)
 * [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
 * [Governing Open](https://governingopen.com/)
 * Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
 
-## Contributors
+## பங்களிப்பாளர்கள்
 
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும், உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி!
 
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+இந்த வழிகாட்டியை எழுதியவர் [@abbycabs](https://github.com/abbycabs), மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகளுடன்:
 
 [@agnostic-apollo](https://github.com/agnostic-apollo)
 [@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -217,4 +216,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
 [@thisisnic](https://github.com/thisisnic)
 [@tudoramariei](https://github.com/tudoramariei)
 [@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + இன்னும் பலர்!
diff --git a/_articles/ta/security-best-practices-for-your-project.md b/_articles/ta/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a6fa1939ad4
--- /dev/null
+++ b/_articles/ta/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: ta
+title: உங்கள் திட்டத்திற்கான சிறந்த பாதுகாப்பு நடைமுறைகள்
+description: சார்புநிலை மற்றும் தனியார் பாதிப்பு அறிக்கையிடலைப் பாதுகாக்க அத்தியாவசிய பாதுகாப்பு நடைமுறைகள், MFA மற்றும் குறியீடு ஸ்கேனிங் மூலம் நம்பிக்கையை வளர்ப்பதன் மூலம் உங்கள் திட்டத்தின் எதிர்காலத்தை பலப்படுத்துங்கள்.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+பிழைகள் மற்றும் புதிய அம்சங்கள் ஒருபுறம் இருக்க, ஒரு திட்டத்தின் நீண்ட ஆயுள் அதன் பயனை மட்டுமல்ல, அதன் பயனர்களிடமிருந்து அது சம்பாதிக்கும் நம்பிக்கையையும் சார்ந்துள்ளது. இந்த நம்பிக்கையை உயிர்ப்புடன் வைத்திருக்க வலுவான பாதுகாப்பு நடவடிக்கைகள் முக்கியம். உங்கள் திட்டத்தின் பாதுகாப்பை கணிசமாக மேம்படுத்த நீங்கள் எடுக்கக்கூடிய சில முக்கியமான நடவடிக்கைகள் இங்கே.
+
+## அனைத்து சலுகை பெற்ற பங்களிப்பாளர்களும் Multi-Factor Authentication (MFA) இயக்கப்பட்டிருப்பதை உறுதிசெய்யவும்.
+
+### உங்கள் திட்டத்திற்கு சலுகை பெற்ற பங்களிப்பாளராக ஆள்மாறாட்டம் செய்யும் ஒரு தீங்கிழைக்கும் நபர், பேரழிவு தரும் சேதங்களை ஏற்படுத்துவார்.
+
+சலுகை பெற்ற அணுகலைப் பெற்றவுடன், இந்த நபர் உங்கள் குறியீட்டை தேவையற்ற செயல்களைச் செய்ய மாற்றியமைக்கலாம் (எடுத்துக்காட்டு: கிரிப்டோகரன்சியை சுரங்கப்படுத்துதல்), அல்லது உங்கள் பயனர்களின் உள்கட்டமைப்பிற்கு தீம்பொருளை விநியோகிக்கலாம் அல்லது அறிவுசார் சொத்து மற்றும் முக்கியமான தரவை, பிற சேவைகளுக்கு வெளியேற்ற தனியார் குறியீடு களஞ்சியங்களை அணுகலாம். 
+
+கணக்கு கையகப்படுத்தலுக்கு எதிராக MFA கூடுதல் பாதுகாப்பை வழங்குகிறது. இயக்கப்பட்டதும், உங்கள் பயனர்பெயர் மற்றும் கடவுச்சொல்லுடன் உள்நுழைந்து, உங்களுக்கு மட்டுமே தெரிந்த அல்லது அணுகக்கூடிய மற்றொரு வகையான அங்கீகாரத்தை வழங்க வேண்டும்.
+
+## உங்கள் மேம்பாட்டின் ஒரு பகுதியாக உங்கள் குறியீட்டைப் பாதுகாக்கவும்.
+
+### உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளை, பின்னர் உற்பத்தியில் பயன்படுத்துவதை விட, செயல்பாட்டின் ஆரம்பத்தில் கண்டறியப்பட்டால் சரிசெய்வது மலிவானது.
+
+உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளைக் கண்டறிய நிலையான பயன்பாட்டு பாதுகாப்பு சோதனை (SAST - Static Application Security Testing) கருவியைப் பயன்படுத்தவும். இந்த கருவிகள் குறியீடு மட்டத்தில் இயங்குகின்றன, மேலும் செயல்படுத்தும் சூழல் தேவையில்லை, எனவே செயல்பாட்டின் ஆரம்பத்தில் செயல்படுத்தப்படலாம், மேலும் உருவாக்கத்தின் போது அல்லது குறியீடு மதிப்பாய்வு கட்டங்களின் போது உங்கள் வழக்கமான மேம்பாட்டு பணிப்பாய்வில் தடையின்றி ஒருங்கிணைக்கப்படலாம். 
+
+இது உங்கள் குறியீட்டை ஒரு திறமையான நிபுணர் பார்ப்பது போன்றது, இது வெளிப்படையான பார்வையில் மறைந்திருக்கக்கூடிய பொதுவான பாதுகாப்பு பாதிப்புகளைக் கண்டறிய உதவுகிறது. 
+
+உங்கள் SAST கருவியை எவ்வாறு தேர்வு செய்வது?
+உரிமத்தைச் சரிபார்க்கவும்: சில கருவிகள் திறந்த மூல திட்டங்களுக்கு இலவசம். உதாரணமாக GitHub CodeQL அல்லது SemGrep.
+உங்கள் மொழிகளுக்கான கவரேஜைச் சரிபார்க்கவும்.
+
+* நீங்கள் ஏற்கனவே பயன்படுத்தும் கருவிகளுடன், உங்கள் தற்போதைய செயல்முறையுடன் எளிதாக ஒருங்கிணைக்கக்கூடிய ஒன்றைத் தேர்ந்தெடுக்கவும். எடுத்துக்காட்டாக, விழிப்பூட்டல்களைப் பார்க்க வேறொரு கருவிக்குச் செல்வதற்குப் பதிலாக, உங்கள் தற்போதைய குறியீடு மதிப்பாய்வு செயல்முறை மற்றும் கருவியின் ஒரு பகுதியாக அவை கிடைத்தால் நல்லது.
+* தவறான நேர்மறைகளைப் பற்றி எச்சரிக்கையாக இருங்கள்! எந்த காரணமும் இல்லாமல் கருவி உங்களை மெதுவாக்குவதை நீங்கள் விரும்பவில்லை!
+* அம்சங்களைச் சரிபார்க்கவும்: சில கருவிகள் மிகவும் சக்திவாய்ந்தவை மற்றும் கறை கண்காணிப்பைச் செய்ய முடியும் (எடுத்துக்காட்டு: GitHub CodeQL), சில செயற்கை நுண்ணறிவு (AI) உருவாக்கிய சரிசெய்தல் பரிந்துரைகளை முன்மொழிகின்றன, சில தனிப்பயன் வினவல்களை எழுதுவதை எளிதாக்குகின்றன (எடுத்துக்காட்டு: SemGrep).  
+
+## உங்கள் ரகசியங்களைப் பகிர்ந்து கொள்ளாதீர்கள்.
+
+### API விசைகள், டோக்கன்கள் மற்றும் கடவுச்சொற்கள் போன்ற முக்கியமான தகவல்கள் சில நேரங்களில் தற்செயலாக உங்கள் களஞ்சியத்தில் கவரப்படலாம்.
+
+இந்தக் காட்சியை கற்பனை செய்து பாருங்கள்: உலகெங்கிலும் உள்ள டெவலப்பர்களின் பங்களிப்புகளுடன் கூடிய பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளராக நீங்கள் இருக்கிறீர்கள். ஒரு நாள், ஒரு பங்களிப்பாளர் அறியாமல் ஒரு மூன்றாம் தரப்பு சேவையின் சில API விசைகளை களஞ்சியத்தில் ஒப்படைப்பார். சில நாட்களுக்குப் பிறகு, யாரோ ஒருவர் இந்த விசைகளைக் கண்டுபிடித்து, அனுமதியின்றி சேவையில் நுழைய அவற்றைப் பயன்படுத்துகிறார். சேவை சமரசம் செய்யப்படுகிறது, உங்கள் திட்டத்தின் பயனர்கள் செயலிழப்பு நேரத்தை அனுபவிக்கிறார்கள், மேலும் உங்கள் திட்டத்தின் நற்பெயர் பாதிக்கப்படுகிறது. பராமரிப்பாளராக, சமரசம் செய்யப்பட்ட ரகசியங்களைத் திரும்பப் பெறுதல், தாக்குபவர் இந்த ரகசியத்தைக் கொண்டு என்ன தீங்கிழைக்கும் செயல்களைச் செய்திருக்க முடியும் என்பதை ஆராய்தல், பாதிக்கப்பட்ட பயனர்களுக்குத் தெரிவித்தல் மற்றும் திருத்தங்களைச் செயல்படுத்துதல் போன்ற கடினமான பணிகளை நீங்கள் இப்போது எதிர்கொள்கிறீர்கள். 
+
+இதுபோன்ற சம்பவங்களைத் தடுக்க, உங்கள் குறியீட்டில் உள்ள அந்த ரகசியங்களைக் கண்டறிய உதவும் "ரகசிய ஸ்கேனிங்" தீர்வுகள் உள்ளன. GitHub Secret Scanning, மற்றும் Truffle Security-இன் Trufflehog போன்ற சில கருவிகள், அவற்றை முதலில் தொலைதூர கிளைகளுக்குத் தள்ளுவதைத் தடுக்கலாம், மேலும் சில கருவிகள் உங்களுக்காக சில ரகசியங்களைத் தானாகவே ரத்து செய்யும். 
+
+## உங்கள் சார்புகளைச் சரிபார்த்து புதுப்பிக்கவும்.
+
+### உங்கள் திட்டத்தில் உள்ள சார்புநிலைகள் உங்கள் திட்டத்தின் பாதுகாப்பை சமரசம் செய்யும் பாதிப்புகளைக் கொண்டிருக்கலாம். சார்புநிலைகளை கைமுறையாகப் புதுப்பித்த நிலையில் வைத்திருப்பது நேரத்தை எடுத்துக்கொள்ளும் பணியாக இருக்கலாம்.
+
+இதைப் பற்றி யோசித்துப் பாருங்கள்: பரவலாகப் பயன்படுத்தப்படும் நூலகத்தின் உறுதியான அடித்தளத்தில் கட்டமைக்கப்பட்ட ஒரு திட்டம். நூலகம் பின்னர் ஒரு பெரிய பாதுகாப்பு சிக்கலைக் காண்கிறது, ஆனால் அதைப் பயன்படுத்தி பயன்பாட்டை உருவாக்கியவர்களுக்கு இது பற்றித் தெரியாது. ஒரு தாக்குபவர் இந்த பலவீனத்தைப் பயன்படுத்தி, அதைப் பிடிக்க பாய்ந்து வரும்போது, முக்கியமான பயனர் தரவு அம்பலப்படுத்தப்படுகிறது. இது ஒரு தத்துவார்த்த வழக்கு அல்ல. 2017 இல் Equifax க்கு இதுதான் நடந்தது: கடுமையான பாதிப்பு கண்டறியப்பட்டதாக அறிவிக்கப்பட்ட பிறகு அவர்கள் தங்கள் Apache Struts சார்புநிலையைப் புதுப்பிக்கத் தவறிவிட்டனர். இது சுரண்டப்பட்டது, மேலும் பிரபலமற்ற Equifax மீறல் 144 மில்லியன் பயனர்களின் தரவைப் பாதித்தது. 
+
+இதுபோன்ற சூழ்நிலைகளைத் தடுக்க, Dependabot மற்றும் Renovate போன்ற மென்பொருள் கலவை பகுப்பாய்வு (SCA - Software Composition Analysis ) கருவிகள், NVD அல்லது GitHub ஆலோசனை தரவுத்தளம் போன்ற பொது தரவுத்தளங்களில் வெளியிடப்பட்ட அறியப்பட்ட பாதிப்புகளுக்கு உங்கள் சார்புகளை தானாகவே சரிபார்த்து, பின்னர் அவற்றை பாதுகாப்பான பதிப்புகளுக்குப் புதுப்பிக்க இழுப்பு கோரிக்கைகளை உருவாக்குகின்றன. சமீபத்திய பாதுகாப்பான சார்பு பதிப்புகளுடன் புதுப்பித்த நிலையில் இருப்பது உங்கள் திட்டத்தை சாத்தியமான ஆபத்துகளிலிருந்து பாதுகாக்கிறது. 
+
+## பாதுகாக்கப்பட்ட கிளைகளுடன் தேவையற்ற மாற்றங்களைத் தவிர்க்கவும்.
+
+### உங்கள் முக்கிய கிளைகளுக்கான கட்டுப்பாடற்ற அணுகல் தற்செயலான அல்லது தீங்கிழைக்கும் மாற்றங்களுக்கு வழிவகுக்கும், அவை பாதிப்புகளை அறிமுகப்படுத்தலாம் அல்லது உங்கள் திட்டத்தின் நிலைத்தன்மையை சீர்குலைக்கலாம்.
+
+ஒரு புதிய பங்களிப்பாளர் பிரதான கிளைக்கு எழுதும் அணுகலைப் பெறுகிறார், மேலும் தற்செயலாக சோதிக்கப்படாத மாற்றங்களைத் தள்ளுகிறார். சமீபத்திய மாற்றங்களின் காரணமாக, ஒரு கடுமையான பாதுகாப்பு குறைபாடு பின்னர் கண்டறியப்படுகிறது. இதுபோன்ற சிக்கல்களைத் தடுக்க, கிளை பாதுகாப்பு விதிகள் மாற்றங்களை முதலில் மதிப்பாய்வுகளுக்கு உட்படுத்தாமல் மற்றும் குறிப்பிட்ட நிலை சோதனைகளில் தேர்ச்சி பெறாமல் முக்கியமான கிளைகளில் தள்ளவோ அல்லது இணைக்கவோ முடியாது என்பதை உறுதி செய்கின்றன. இந்த கூடுதல் நடவடிக்கை நடைமுறையில் இருப்பதால் நீங்கள் பாதுகாப்பாகவும் சிறப்பாகவும் இருக்கிறீர்கள், ஒவ்வொரு முறையும் உயர்தர தரத்தை உறுதி செய்கிறீர்கள்.
+
+## பாதிப்பு அறிக்கையிடலுக்கான உட்கொள்ளும் பொறிமுறையை அமைக்கவும்.
+
+### உங்கள் பயனர்கள் பிழைகளைப் புகாரளிப்பதை எளிதாக்குவது ஒரு நல்ல நடைமுறைதான், ஆனால் பெரிய கேள்வி என்னவென்றால்: இந்தப் பிழை பாதுகாப்பு தாக்கத்தை ஏற்படுத்தும் போது, தீங்கிழைக்கும் ஹேக்கர்களுக்கு உங்கள் மீது இலக்கு வைக்காமல் அவர்கள் அதை எவ்வாறு பாதுகாப்பாக உங்களிடம் புகாரளிக்க முடியும்?
+
+இதைப் பற்றி யோசித்துப் பாருங்கள்: ஒரு பாதுகாப்பு ஆராய்ச்சியாளர் உங்கள் திட்டத்தில் ஒரு பாதிப்பைக் கண்டறிந்தாலும், அதைப் புகாரளிக்க தெளிவான அல்லது பாதுகாப்பான வழியைக் கண்டுபிடிக்கவில்லை. நியமிக்கப்பட்ட செயல்முறை இல்லாமல், அவர்கள் ஒரு பொதுப் பிரச்சினையை உருவாக்கலாம் அல்லது சமூக ஊடகங்களில் வெளிப்படையாக விவாதிக்கலாம். அவர்கள் நல்ல நோக்கத்துடன் ஒரு தீர்வை வழங்கினாலும், அவர்கள் அதை ஒரு பொது இழுப்பு கோரிக்கையுடன் செய்தால், அது இணைக்கப்படுவதற்கு முன்பு மற்றவர்கள் அதைப் பார்ப்பார்கள்! இந்த பொது வெளிப்படுத்தல், நீங்கள் அதை நிவர்த்தி செய்ய வாய்ப்பு கிடைக்கும் முன்பே தீங்கிழைக்கும் நடிகர்களுக்கு பாதிப்பை வெளிப்படுத்தும், இது பூஜ்ஜிய நாள் (Zero-day) சுரண்டலுக்கு வழிவகுக்கும், உங்கள் திட்டத்தையும் அதன் பயனர்களையும் தாக்கும்.
+
+### பாதுகாப்புக் கொள்கை
+
+இதைத் தவிர்க்க, ஒரு பாதுகாப்புக் கொள்கையை வெளியிடுங்கள். `SECURITY.md` கோப்பில் வரையறுக்கப்பட்ட ஒரு பாதுகாப்புக் கொள்கை, பாதுகாப்புக் கவலைகளைப் புகாரளிப்பதற்கான படிகளை விவரிக்கிறது, ஒருங்கிணைந்த வெளிப்படுத்தலுக்கான வெளிப்படையான செயல்முறையை உருவாக்குகிறது மற்றும் புகாரளிக்கப்பட்ட சிக்கல்களைத் தீர்ப்பதற்கான திட்டக் குழுவின் பொறுப்புகளை நிறுவுகிறது. இந்தப் பாதுகாப்புக் கொள்கை "பொதுப் பிரச்சினை அல்லது மக்கள் தொடர்புத் தகவலில் விவரங்களை வெளியிட வேண்டாம், security@example.com இல் எங்களுக்கு ஒரு தனிப்பட்ட மின்னஞ்சலை அனுப்பவும்" என்பது போல எளிமையாக இருக்கலாம், ஆனால் அவர்கள் உங்களிடமிருந்து எப்போது பதிலைப் பெறுவார்கள் என்பது போன்ற பிற விவரங்களையும் கொண்டிருக்கலாம். வெளிப்படுத்தல் செயல்முறையின் செயல்திறன் மற்றும் செயல்திறனுக்கு உதவும் எதையும்.
+
+### தனியார் பாதிப்பு அறிக்கையிடல்
+
+சில தளங்களில், தனிப்பட்ட சிக்கல்கள் இருந்தால், உட்கொள்ளல் முதல் ஒளிபரப்பு வரை, உங்கள் பாதிப்பு மேலாண்மை செயல்முறையை நீங்கள் நெறிப்படுத்தலாம் மற்றும் வலுப்படுத்தலாம். GitLab இல், இது தனிப்பட்ட சிக்கல்களுடன் செய்யப்படலாம். GitHub இல், இது தனியார் பாதிப்பு அறிக்கையிடல் (PVR - private vulnerability reporting) என்று அழைக்கப்படுகிறது. PVR பராமரிப்பாளர்கள் பாதிப்பு அறிக்கைகளைப் பெறவும், நிவர்த்தி செய்யவும் உதவுகிறது, இவை அனைத்தும் GitHub தளத்திற்குள் உள்ளன. GitHub தானாகவே திருத்தங்களை எழுத ஒரு தனியார் ஃபோர்க்கையும், ஒரு வரைவு பாதுகாப்பு ஆலோசனையையும் உருவாக்கும். சிக்கல்களை வெளிப்படுத்தவும், திருத்தங்களை வெளியிடவும் நீங்கள் முடிவு செய்யும் வரை இவை அனைத்தும் ரகசியமாகவே இருக்கும். வளையத்தை மூட, பாதுகாப்பு ஆலோசனைகள் வெளியிடப்படும், மேலும் உங்கள் அனைத்து பயனர்களுக்கும் அவர்களின் SCA கருவி மூலம் தகவல் அளித்து பாதுகாக்கும்.
+
+## முடிவு: உங்களுக்காக ஒரு சில படிகள், உங்கள் பயனர்களுக்கு ஒரு பெரிய முன்னேற்றம்.
+
+இந்த சில படிகள் உங்களுக்கு எளிதானதாகவோ அல்லது அடிப்படையானதாகவோ தோன்றலாம், ஆனால் அவை உங்கள் திட்டத்தை அதன் பயனர்களுக்கு மிகவும் பாதுகாப்பானதாக மாற்றுவதற்கு நீண்ட தூரம் செல்கின்றன, ஏனெனில் அவை மிகவும் பொதுவான சிக்கல்களுக்கு எதிராக பாதுகாப்பை வழங்கும்.
+
+## பங்களிப்பாளர்கள்
+
+### இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும் உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி!
+
+இந்த வழிகாட்டியை [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) எழுதியுள்ளனர், மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகள்: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + இன்னும் பலர்!
diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a5d380f0831
--- /dev/null
+++ b/_articles/tr/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: tr
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/_articles/zh-hant/security-best-practices-for-your-project.md b/_articles/zh-hant/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..c43ca139d8f
--- /dev/null
+++ b/_articles/zh-hant/security-best-practices-for-your-project.md
@@ -0,0 +1,84 @@
+---
+lang: zh-hant
+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.
+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.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+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. 
+
+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.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+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. 
+
+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. 
+
+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)
+
+* 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).  
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+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. 
+
+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. 
+
+## Check and update your dependencies
+
+### 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.
+
+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. 
+
+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. 
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+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.
+
+## Set up an intake mechanism for vulnerability reporting
+
+### 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?
+
+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.
+
+### Security Policy
+
+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 security@example.com", 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.
+
+### Private Vulnerability Reporting
+
+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.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+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.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others!
diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index ff37581f374..566205b4f49 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -23,7 +23,7 @@ $section_translation: (
         "pt": "",
         "ro": "",
         "ru": "",
-        "ta": "",
+        "ta": "பிரிவு",
         "tr": "",
         "zh-hant": "章節",
         "zh-hans": "章节",