Skip to content

Commit 4a479fe

Browse files
Update security-best-practices-for-your-project.md
update - ’ Signed-off-by: Kenyatta <[email protected]>
1 parent c56d32e commit 4a479fe

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

_articles/security-best-practices-for-your-project.md

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -2,69 +2,69 @@
22
lang: en
33
untranslated: true
44
title: Security Best Practices for your Project
5-
description: Strengthen your projects future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
5+
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.
66
class: security-best-practices
77
order: -1
88
image: /assets/images/cards/security-best-practices.png
99
---
1010

11-
Bugs and new features aside, a projects 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 projects security.
11+
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.
1212
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.
1313

1414
## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
1515

1616
### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
1717

18-
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.
18+
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.
1919

2020
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.
2121

2222
## Secure your code as part of your development workflow
2323

2424
### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
2525

26-
Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and dont 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.
26+
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.
2727

28-
Its 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.
28+
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.
2929

3030
How to choose your SAST tool?
3131
Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
3232
Check the coverage for your language(s)
33-
* Select one that easily integrates with the tools you already use, with your existing process. For example, its 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.
34-
* Beware of False Positives! You dont want the tool to slow you down for no reason!
33+
* 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.
34+
* Beware of False Positives! You don't want the tool to slow you down for no reason!
3535
* 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).
3636

3737
## Don’t share your secrets
3838

3939
### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
4040

41-
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 projects reputation takes a hit. As the maintainer, youre 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.
41+
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.
4242

4343
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.
4444

4545
## Check and update your dependencies
4646

4747
### 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.
4848

49-
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 dont 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.
49+
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.
5050

5151
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.
5252

5353
## Avoid unwanted changes with protected branches
5454

5555
### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
5656

57-
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. Youre safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
57+
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.
5858

5959
## Set up an intake mechanism for vulnerability reporting
6060

61-
### Its 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?
61+
### 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?
6262

63-
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 its 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.
63+
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.
6464

6565
### Security Policy
6666

67-
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 teams responsibilities for addressing reported issues. This security policy can be as simple as “Please dont publish details in a public issue or PR, send us a private email at [email protected]”, but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
67+
To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as “Please don't publish details in a public issue or PR, send us a private email at [email protected]”, but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
6868

6969
### Private Vulnerability Reporting
7070
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.

0 commit comments

Comments
 (0)