Compare commits

...

3 Commits

Author SHA1 Message Date
Sladyn
f939f16b7a
Merge c04530396e into 1aab8b2d5a 2025-06-23 23:52:15 +00:00
Jordan Harband
1aab8b2d5a
[meta] update security policy; add IRP 2025-06-23 16:11:48 -07:00
Sladyn Nunes
c04530396e
Add check to nvm profile for nvm path 2021-03-18 17:21:05 +05:30
3 changed files with 167 additions and 8 deletions

117
.github/INCIDENT_RESPONSE_PLAN.md vendored Normal file
View File

@ -0,0 +1,117 @@
# Incident Response Process for **nvm**
## Reporting a Vulnerability
We take the security of **nvm** very seriously. If you believe youve found a security vulnerability, please inform us responsibly through coordinated disclosure.
### How to Report
> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
Instead, please use one of these secure channels:
1. **GitHub Security Advisories**
Use the **Report a vulnerability** button in the Security tab of the [nvm-sh/nvm repository](https://github.com/nvm-sh/nvm).
2. **Email**
Follow the posted [Security Policy](https://github.com/nvm-sh/nvm/security/policy).
### What to Include
**Required Information:**
- Brief description of the vulnerability type
- Affected version(s) and components
- Steps to reproduce the issue
- Impact assessment (what an attacker could achieve)
**Helpful Additional Details:**
- Full paths of affected scripts or files
- Specific commit or branch where the issue exists
- Required configuration to reproduce
- Proof-of-concept code (if available)
- Suggested mitigation or fix
## Our Response Process
**Timeline Commitments:**
- **Initial acknowledgment**: Within 24 hours
- **Detailed response**: Within 3 business days
- **Status updates**: Every 7 days until resolved
- **Resolution target**: 90 days for most issues
**What Well Do:**
1. Acknowledge your report and assign a tracking ID
2. Assess the vulnerability and determine severity
3. Develop and test a fix
4. Coordinate disclosure timeline with you
5. Release a security update and publish an advisory and CVE
6. Credit you in our security advisory (if desired)
## Disclosure Policy
- **Coordinated disclosure**: Well work with you on timing
- **Typical timeline**: 90 days from report to public disclosure
- **Early disclosure**: If actively exploited
- **Delayed disclosure**: For complex issues
## Scope
**In Scope:**
- **nvm** project (all supported versions)
- Installation and update scripts (`install.sh`, `nvm.sh`)
- Official documentation and CI/CD integrations
- Dependencies with direct security implications
**Out of Scope:**
- Third-party forks or mirrors
- Platform-specific installs outside core scripts
- Social engineering or physical attacks
- Theoretical vulnerabilities without practical exploitation
## Security Measures
**Our Commitments:**
- Regular vulnerability scanning via GitHub Actions
- Automated security checks in CI/CD pipelines
- Secure scripting practices and mandatory code review
- Prompt patch releases for critical issues
**User Responsibilities:**
- Keep **nvm** updated
- Verify script downloads via PGP signatures
- Follow secure configuration guidelines for shell environments
## Legal Safe Harbor
**We will NOT:**
- Initiate legal action
- Contact law enforcement
- Suspend or terminate your access
**You must:**
- Only test against your own installations
- Not access, modify, or delete user data
- Not degrade service availability
- Not publicly disclose before coordinated disclosure
- Act in good faith
## Recognition
- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
## Security Updates
**Stay Informed:**
- Subscribe to GitHub releases for **nvm**
- Enable GitHub Security Advisory notifications
**Update Process:**
- Patch releases (e.g., v0.40.3 → v0.40.4)
- Out-of-band releases for critical issues
- Advisories via GitHub Security Advisories
## Contact Information
- **Security reports**: Security tab of [nvm-sh/nvm](https://github.com/nvm-sh/nvm/security)
- **General inquiries**: GitHub Discussions or Issues

17
.github/SECURITY.md vendored
View File

@ -1,6 +1,6 @@
# Security # Security
Please email [@ljharb](https://github.com/ljharb) or see https://tidelift.com/security if you have a potential security vulnerability to report. Please file a private vulnerability report via GitHub, email [@ljharb](https://github.com/ljharb), or see https://tidelift.com/security if you have a potential security vulnerability to report.
## OpenSSF CII Best Practices ## OpenSSF CII Best Practices
@ -12,16 +12,17 @@ There are three “tiers”: passing, silver, and gold.
We meet 100% of the “passing” criteria. We meet 100% of the “passing” criteria.
### Silver ### Silver
We meet 95% of the “silver” criteria. The gaps are as follows: We meet 100% of the “silver” criteria.
- we do not have a DCO or a CLA process for contributions.
- because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
- we do not currently document “what the user can and cannot expect in terms of security” for our project. This is planned to be completed in 2023.
### Gold ### Gold
We meet 65% of the “gold” criteria. The gaps are as follows: We meet 78% of the “gold” criteria. The gaps are as follows:
- we do not yet have the “silver” badge; see all the gaps above. - because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
- We do not include a copyright or license statement in each source file. Efforts are underway to change this archaic practice into a suggestion instead of a hard requirement. - We do not include a copyright or license statement in each source file. Efforts are underway to change this archaic practice into a suggestion instead of a hard requirement.
## Threat Model ## Threat Model
See [THREAT_MODEL.md](./THREAT_MODEL.md). See [THREAT_MODEL.md](.github/THREAT_MODEL.md).
## Incident Response Plan
Please see our [Incident Response Plan](.github/INCIDENT_RESPONSE_PLAN.md).

View File

@ -0,0 +1,41 @@
#!/bin/sh
setup () {
HOME="."
NVM_ENV=testing \. ../../install.sh
touch ".bashrc"
touch ".zshrc"
touch ".profile"
}
cleanup () {
unset HOME
unset NVM_ENV
unset NVM_DETECT_PROFILE
unset BASH_VERSION
unset ZSH_VERSION
unset -f setup cleanup die
rm -f ".bashrc" ".bash_profile" ".zshrc" ".profile" "test_profile" > "/dev/null" 2>&1
}
die () { echo "$@" '$NVM_DETECT_PROFILE:' "$NVM_DETECT_PROFILE"; cleanup; exit 1; }
setup
# check if nvm_path already exists in bashrc
NVM_DETECT_PROFILE="$(BASH_VERSION="1"; unset PROFILE; nvm_detect_profile)"
echo "export NVM_DIR="$HOME/.nvm"" > $HOME/.bashrc
OUTPUT = "$(nvm_do_install)"
EXPECTED_OUTPUT='nvm source string already in ${NVM_PROFILE}'
if [ "${OUTPUT#*$EXPECTED_OUTPUT}" = "${OUTPUT}" ]; then
die "Path already exists in the profile, so should have returned >${EXPECTED_OUTPUT}<. Instead it returned >${OUTPUT}<"
fi
# .zshrc should be detected for zsh
NVM_DETECT_PROFILE="$(ZSH_VERSION="1"; unset PROFILE; unset BASH_VERSION; nvm_detect_profile)"
echo "export NVM_DIR="$HOME/.nvm"" > $HOME/.zshrc
OUTPUT = "$(nvm_do_install)"
EXPECTED_OUTPUT='nvm source string already in ${NVM_PROFILE}'
if [ "${OUTPUT#*$EXPECTED_OUTPUT}" = "${OUTPUT}" ]; then
die "Path already exists in the profile, so should have returned >${EXPECTED_OUTPUT}<. Instead it returned >${OUTPUT}<"
fi