From 176f97c9bc30869f75a150bae9246343228285f4 Mon Sep 17 00:00:00 2001 From: Amirmahdi Teymouri Date: Tue, 28 Oct 2025 18:13:33 +0330 Subject: [PATCH] translated security-best-practices-for-your-projects to Persian (Farsi) --- ...ecurity-best-practices-for-your-project.md | 83 +++++++++---------- 1 file changed, 41 insertions(+), 42 deletions(-) diff --git a/_articles/fa/security-best-practices-for-your-project.md b/_articles/fa/security-best-practices-for-your-project.md index bcff793b68d..5fe34393772 100644 --- a/_articles/fa/security-best-practices-for-your-project.md +++ b/_articles/fa/security-best-practices-for-your-project.md @@ -1,84 +1,83 @@ --- 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. +title: بهترین روش‌های امنیتی برای پروژه شما +description: آینده پروژه خود را با ایجاد اعتماد از طریق روش‌های امنیتی ضروری تقویت کنید - از MFA و اسکن کد گرفته تا مدیریت ایمن وابستگی‌ها و گزارش‌دهی آسیب‌پذیری خصوصی. 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) +## اطمینان حاصل کنید که همه مشارکت‌کنندگان دارای دسترسی، احراز هویت چندعاملی (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. +پس از به دست آوردن دسترسی privileged، این بازیگر می‌تواند کد شما را تغییر دهد تا اقدامات ناخواسته انجام دهد (مانند استخراج ارز دیجیتال)، یا می‌تواند بدافزار را به زیرساخت کاربران شما توزیع کند، یا می‌تواند به مخازن کد خصوصی دسترسی یابد تا مالکیت فکری و داده‌های حساس، از جمله اعتبارنامه‌های سرویس‌های دیگر را سرقت کند. -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. +MFA یک لایه امنیتی اضافی در برابر تصاحب حساب ارائه می‌دهد. پس از فعال‌سازی، باید با نام کاربری و رمز عبور خود وارد شوید و شکل دیگری از احراز هویت را ارائه دهید که فقط شما آن را می‌دانید یا به آن دسترسی دارید. -## 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. +### رفع آسیب‌پذیری‌های امنیتی در کد شما، در صورت تشخیص زودهنگام در فرآیند، بسیار کم‌هزینه‌تر از زمانی است که در محیط 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. +از یک ابزار Static Application Security Testing (SAST) برای تشخیص آسیب‌پذیری‌های امنیتی در کد خود استفاده کنید. این ابزارها در سطح کد عمل می‌کنند و به محیط اجرایی نیاز ندارند، و بنابراین می‌توانند در مراحل اولیه فرآیند اجرا شوند و به طور یکپارچه در گردش کار توسعه معمول شما، در طول مرحله build یا مرور کد، ادغام شوند. -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) +چگونه ابزار SAST خود را انتخاب کنیم؟ +* مجوز را بررسی کنید: برخی ابزارها برای پروژه‌های متن‌باز رایگان هستند. برای مثال GitHub CodeQL یا SemGrep. +* پوشش زبان(های) برنامه‌نویسی خود را بررسی کنید. +* ابزاری را انتخاب کنید که به راحتی با ابزارها و فرآیندهای موجود شما ادغام می‌شود. برای مثال، بهتر است که هشدارها به عنوان بخشی از فرآیند و ابزار مرور کد موجود شما در دسترس باشند، نه اینکه برای مشاهده آنها به ابزار دیگری مراجعه کنید. +* مراقب هشدارهای کاذب (False Positives) باشید! شما نمی‌خواهید ابزار بدون دلیل شما را کند کند! +* ویژگی‌ها را بررسی کنید: برخی ابزارها بسیار قدرتمند هستند و می‌توانند ردیابی نشت داده (Taint Tracking) انجام دهند (مثال: GitHub CodeQL)، برخی پیشنهادات رفع مشکل تولید شده توسط هوش مصنوعی ارائه می‌دهند، و برخی نوشتن کوئری‌های سفارشی را آسان‌تر می‌کنند (مثال: SemGrep). -* 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 +### داده‌های حساس، مانند کلیدهای API، توکن‌ها و رمزهای عبور، گاهی اوقات ممکن است به طور تصادفی در مخزن شما commit شوند. -### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. +این سناریو را تصور کنید: شما maintainer یک پروژه متن‌باز محبوب با مشارکت توسعه‌دهندگان از سراسر جهان هستید. یک روز، یک مشارکت‌کننده ناخواسته برخی از کلیدهای API یک سرویس شخص ثالث را در مخزن commit می‌کند. روزها بعد، شخصی این کلیدها را پیدا می‌کند و از آنها برای دسترسی غیرمجاز به سرویس استفاده می‌کند. سرویس به خطر می‌افتد، کاربران پروژه شما downtime را تجربه می‌کنند و اعتبار پروژه شما آسیب می‌بیند. به عنوان maintainer، اکنون با وظایف دلهره‌آور لغو اسرار به خطر افتاده، بررسی اقدامات مخربانه‌ای که مهاجم می‌توانسته با این راز انجام دهد، اطلاع‌رسانی به کاربران affected و اجرای وصله‌ها روبرو هستید. -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. +برای جلوگیری از چنین حوادثی، راه‌حل‌های "اسکن اسرار" (secret scanning) وجود دارند که به شما در تشخیص این اسرار در کدتان کمک می‌کنند. برخی ابزارها مانند GitHub Secret Scanning و Trufflehog از Truffle Security اساساً از push شدن آنها به شاخه‌های remote جلوگیری می‌کنند، و برخی ابزارها به طور خودکار برخی اسرار را برای شما لغو می‌کنند. -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. +این را تصور کنید: پروژه‌ای که بر اساس بنیان محکم یک کتابخانه پرکاربرد ساخته شده است. این کتابخانه بعداً یک مشکل امنیتی بزرگ پیدا می‌کند، اما افرادی که برنامه را با استفاده از آن ساخته‌اند از آن اطلاعی ندارند. داده‌های حساس کاربر در معرض دید قرار می‌گیرند وقتی یک مهاجم از این ضعف سوء استفاده کرده و آنها را می‌دزدد. این یک مورد نظری نیست. این دقیقاً چیزی است که برای Equifax در سال ۲۰۱۷ اتفاق افتاد: آنها پس از اعلام تشخیص یک آسیب‌پذیری شدید، وابستگی Apache Struts خود را به‌روز نکردند. از آن سوء استفاده شد و نقض داده‌های معروف Equifax 144 میلیون کاربر را تحت تاثیر قرار داد. -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. +برای جلوگیری از چنین سناریوهایی، ابزارهای Software Composition Analysis (SCA) مانند Dependabot و Renovate به طور خودکار وابستگی‌های شما را برای یافتن آسیب‌پذیری‌های شناخته شده منتشر شده در پایگاه‌های داده عمومی مانند NVD یا GitHub Advisory Database بررسی می‌کنند و سپس pull requestهایی برای به‌روزرسانی آنها به نسخه‌های ایمن ایجاد می‌کنند. به‌روز ماندن با آخرین نسخه‌های ایمن وابستگی‌ها، پروژه شما را در برابر خطرات بالقوه محافظت می‌کند. -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. +## از تغییرات ناخواسته با شاخه‌های محافظت شده (protected branches) جلوگیری کنید -## 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. +یک مشارکت‌کننده جدید دسترسی write به شاخه اصلی دریافت می‌کند و به طور تصادفی تغییراتی را که تست نشده‌اند push می‌کند. یک نقص امنیتی فاجعه‌بار سپس آشکار می‌شود، به لطف آخرین تغییرات. برای جلوگیری از چنین مشکلاتی، قوانین محافظت از شاخه (branch protection rules) تضمین می‌کنند که تغییرات نمی‌توانند به شاخه‌های مهم push یا merge شوند مگر اینکه ابتدا مرور شده و بررسی‌های وضعیت مشخص شده را پشت سر بگذارند. با این اقدام اضافی در امان‌تر و در موقعیت بهتری هستید و هر بار کیفیت عالی را تضمین می‌کنید. -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? +این را تصور کنید: یک محقق امنیتی یک آسیب‌پذیری در پروژه شما کشف می‌کند اما راه روشن یا ایمنی برای گزارش آن پیدا نمی‌کند. بدون یک فرآیند مشخص شده، ممکن است یک issue عمومی ایجاد کند یا در مورد آن به طور آشکار در رسانه‌های اجتماعی بحث کند. حتی اگر خوش‌نیت باشند و یک وصله ارائه دهند، اگر آن را با یک pull request عمومی انجام دهند، دیگران قبل از merge شدن آن را خواهند دید! این افشای عمومی، آسیب‌پذیری را قبل از اینکه شما فرصت رسیدگی به آن را داشته باشید در معرض دید بازیگران مخرب قرار می‌دهد و به طور بالقوه منجر به یک اکسپلویت zero-day شده و پروژه شما و کاربرانش را مورد حمله قرار می‌دهد. -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) -### Security Policy +برای اجتناب از این، یک خط‌مشی امنیتی منتشر کنید. یک خط‌مشی امنیتی، که در یک فایل `SECURITY.md` تعریف می‌شود، مراحل گزارش نگرانی‌های امنیتی را به تفصیل شرح می‌دهد، یک فرآیند شفاف برای افشای هماهنگ شده ایجاد می‌کند و مسئولیت‌های تیم پروژه را برای رسیدگی به issues گزارش شده تعیین می‌کند. این خط‌مشی امنیتی می‌تواند به سادگی این باشد: "لطفاً جزئیات را در یک issue یا PR عمومی منتشر نکنید، یک ایمیل خصوصی به ما به آدرس security@example.com ارسال کنید"، اما می‌تواند حاوی جزئیات دیگری نیز باشد، مانند زمانی که باید انتظار دریافت پاسخ از شما را داشته باشند. هر چیزی که می‌تواند به اثربخشی و کارایی فرآیند افشا کمک کند. -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) -### Private Vulnerability Reporting +در برخی پلتفرم‌ها، می‌توانید فرآیند مدیریت آسیب‌پذیری خود را از دریافت تا انتشار، با استفاده از issues خصوصی، ساده‌تر و تقویت کنید. در GitLab، این کار را می‌توان با issues خصوصی انجام داد. در GitHub، این کار گزارش‌دهی خصوصی آسیب‌پذیری (PVR) نامیده می‌شود. PVR به maintainers امکان می‌دهد گزارش‌های آسیب‌پذیری را دریافت کرده و رسیدگی کنند، همه در داخل پلتفرم GitHub. GitHub به طور خودکار یک fork خصوصی برای نوشتن وصله‌ها و یک security advisory پیش‌نویس ایجاد می‌کند. همه اینها محرمانه باقی می‌مانند تا زمانی که شما تصمیم به افشای issues و انتشار وصله‌ها بگیرید. برای تکمیل فرآیند، security advisoryها منتشر می‌شوند و از طریق ابزار SCA به همه کاربران شما اطلاع رسانی کرده و آنها را محافظت می‌کنند. -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 +### با تشکر از همه maintainerهایی که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند! -### 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: +این راهنما توسط [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) نوشته شده است با مشارکت: [@JLLeitschuh](https://github.com/JLLeitschuh) -[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others! +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + بسیاری دیگر!