audit: env selection for report by larsgw · Pull Request #125 · npm/cli

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw · 2018-12-17T20:56:43Z

Select dependency environments with --only, --also and --production for
reports as well, instead of just for audit fix. Still reports the
filtered advisories, but changes the exit code (as is done with
advisories below --audit-level). Tests need updating due to the new way
of counting vulnerabilities.

See https://npm.community/t/3959

Select dependency environments with --only, --also and --production for reports as well, instead of just for audit fix. Still reports the filtered advisories, but changes the exit code (as is done with advisories below --audit-level). Tests need updating due to the new way of counting vulnerabilities. See https://npm.community/t/3959

sneakypete81 · 2018-12-17T21:31:50Z

Thanks very much for doing this.

Still reports the filtered advisories

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

larsgw · 2018-12-17T21:48:42Z

Maybe I've misunderstood, but if I run npm audit --only=prod I wouldn't expect to see any advisories from dev dependencies.

@sneakypete81 I know, but that requires either modifying the audit report, which could have unintended side effects, or changing all the reporters. Since --audit-level also reports advisories under the set severity (correct me if I'm wrong), this seemed like warranted behavior.

mikecbrant · 2018-12-19T15:12:22Z

Anxiously awaiting merge. Thanks, @larsgw

evilpacket · 2019-01-08T00:35:13Z

I did a quick test of --audit-level and it worked as I would intend it to.

I would expect these flags to be passed along to the reporters and for them to act appropriately, such as @sneakypete81 suggests when I say --only=prod to not show advisories that pertain to dev dependencies.

Looks like npm audit help would also need some updating to represent the new flags but I'm not sure the standard that's been set forth by the cli team for these things.

iarna · 2019-01-08T00:39:17Z

As Adam suggests, docs should be added to doc/cli/npm-audit.md and doc/misc/npm-config.md

Reporter filters go in https://github.com/npm/npm-audit-report/pulls and should be PRed there (please add a note here when they are)

larsgw · 2019-01-17T17:47:23Z

I added the docs. --audit-level doesn't filter the reports on my end (v6.5.0), should I add that as well as the env filters?

Details

$ npm ini -y
$ npm i underscore.string@3.3.4
$ npm audit
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
1
$ npm audit --audit-level high
=== npm audit security report === # Run npm install underscore.string@3.3.5 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ underscore.string │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/745 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 moderate severity vulnerability in 3 scanned packages
run `npm audit fix` to fix 1 of them.
$ echo $?
0

- npm/cli#125 - npm/npm#20575

The security script might come back when this is merged and released: npm/cli#125

perrosen · 2019-02-18T05:50:21Z

Any movement on this? Is there something I can do to help speeding this up? This is one of my most wanted features for npm audit since launch. Seeing CI builds fail because of dev dependencies is becoming a real annoyance.

The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

…d and gone The security check might come back when this is merged and released: npm/cli#125

The security script might come back when this is merged and released: npm/cli#125

IPWright83 · 2020-03-10T14:45:04Z

Are there updates on this at all? I've got builds failing on our pipeline (and similarly don't want to auto fix them during the build), but it's all because of jest dependencies - which really don't matter at runtime.

lucasfevi · 2020-03-10T15:59:11Z

@IPWright83 there is now a production flag for npm audit on npm version v6.10+. Check the release notes: https://github.com/npm/cli/releases/tag/v6.10.0

SoerenHenning · 2020-06-09T07:35:06Z

Even though the --production flag is a nice improvement, we could only take full advantage of it if accompanied by a --development flag or so. Our use case is as follows: We would like to run npm audit as part of our build pipeline for both production and development dependencies. However, the build process should only fail for vulnerabilities in production. For vulnerabilities in dev dependencies, only a warning should be generated.

* feat: add Application Default Credentials (ADC) support (npm#103) Extends the credential chain in get_token() to include ADC as a 4th source: 1. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE env var 2. Encrypted credentials (~/.config/gws/credentials.enc) 3. Plaintext credentials (~/.config/gws/credentials.json) 4. ADC — GOOGLE_APPLICATION_CREDENTIALS env var, then ~/.config/gcloud/application_default_credentials.json Both authorized_user and service_account ADC formats are detected via the 'type' field and parsed accordingly. This means users can authenticate with: gcloud auth application-default login --client-id-file=client_secret.json and gws will automatically pick up those credentials. Closesnpm#103 Co-Authored-By: Claude <noreply@anthropic.com> * fix(auth): address review feedback on ADC support - Extract duplicated JSON credential parsing into parse_credential_file() helper to reduce duplication between GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE and ADC code paths; uses serde_json::from_value to avoid second string parse - Fix well-known ADC path on macOS: dirs::config_dir() returns ~/Library/Application Support on macOS, not ~/.config; use dirs::home_dir().join('.config/gcloud/...') instead - Hard-error when GOOGLE_APPLICATION_CREDENTIALS points to a missing file (was: silently fall through to 'No credentials found') - Add test_load_credentials_adc_env_var_service_account covering service account credentials loaded via GOOGLE_APPLICATION_CREDENTIALS - Remove unnecessary unsafe blocks from env var tests (set_var/remove_var are not unsafe functions; thread safety is already handled by serial_test) - Update changeset to include GOOGLE_WORKSPACE_CLI_TOKEN at top of lookup order and clarify ADC fallback behaviour Addresses review feedback from jpoehnelt on npm#125. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

larsgw requested a review from a team as a code owner December 17, 2018 20:56

zkat added semver:minor new backwards-compatible feature needs-discussion labels Jan 7, 2019

doc: add docs for audit level and env selection
ca35059

zkat force-pushed the release-next branch 5 times, most recently from db63b89 to b09bc8cCompare January 23, 2019 18:36

zkat added the in-progress label Jan 28, 2019

DrSensor added a commit to DrSensor/bot-byte that referenced this pull request Jan 30, 2019
ci: employ npm magic tricks 😅
402c4be
- npm/cli#125 - npm/npm#20575

mischah added a commit to micromata/Baumeister that referenced this pull request Feb 7, 2019
feature: Remove security npm script since nsp is dead and gone
0031941
The security script might come back when this is merged and released: npm/cli#125

mischah mentioned this pull request Feb 7, 2019
feature: Remove security npm script since nsp is dead and gone micromata/Baumeister#267
Merged

mischah added a commit to micromata/Baumeister that referenced this pull request Feb 7, 2019
feature: Remove security npm script since nsp is dead and gone
a8052eb
The security script might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/Baumeister that referenced this pull request Feb 8, 2019
feature: Remove security npm script since nsp is dead and gone
ef784e7
The security script might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/cli-error-notifier that referenced this pull request Feb 11, 2019
chore: Remove security npm script since nsp is dead and gone
291a765
The security script might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/cli-error-notifier that referenced this pull request Feb 11, 2019
chore: Remove security npm script since nsp is dead and gone
888a82c
The security script might come back when this is merged and released: npm/cli#125

ngraef mentioned this pull request Feb 14, 2019
doc: add --audit-level param #159
Closed

mischah added a commit to micromata/generator-baumeister that referenced this pull request Feb 18, 2019
chore: Remove prepublish npm script since nsp is dead and gone
dc55477
The security check might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/generator-baumeister that referenced this pull request Feb 18, 2019
feature: Remove security npm script since nsp is dead and gone
71b9a5b
The security script might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/generator-baumeister that referenced this pull request Feb 18, 2019
chore: Remove the generators prepublish npm script since nsp is dea…
22d008f
…d and gone The security check might come back when this is merged and released: npm/cli#125

mischah added a commit to micromata/generator-baumeister that referenced this pull request Feb 18, 2019
feature: Remove security npm script since nsp is dead and gone
c22c22e
The security script might come back when this is merged and released: npm/cli#125

adrianjost mentioned this pull request Mar 4, 2020
create npm audit workflow hpi-schul-cloud/schulcloud-client#1629
Merged
1 task

darcyclarke added the Priority Backlog a "backlogged" item that will be tracked in a Project Board label Mar 10, 2020

darcyclarke added the Needs Review label Jul 31, 2020

ruyadorno assigned isaacs Aug 14, 2020

darcyclarke added Release 6.x work is associated with a specific npm 6 release and removed Priority Backlog a "backlogged" item that will be tracked in a Project Board labels Oct 1, 2020

darcyclarke modified the milestone: OSS - Sprint 17 Oct 5, 2020

darcyclarke closed this Feb 13, 2021

snyk-bot mentioned this pull request May 11, 2022
[Snyk] Upgrade read-package-json from 5.0.0 to 5.0.1 Mhmonicox/cli#3
Open

hojatA1 mentioned this pull request Jun 21, 2023
[Snyk] Security upgrade cross-spawn from 6.0.5 to 7.0.0 hojatA1/npm.cli#23
Open

CALISOULB mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities CALISOULB/cli#19
Open

This was referenced Nov 30, 2023
[Snyk] Security upgrade npm-registry-fetch from 9.0.0 to 14.0.0 varmakarthik12/cli#28
Closed
[Snyk] Fix for 1 vulnerabilities varmakarthik12/cli#30
Closed
[Snyk] Security upgrade npm-registry-fetch from 9.0.0 to 14.0.0 varmakarthik12/cli#31
Closed

bumplzz69 mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities bumplzz69/cli#38
Open

mtdev2 mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities mtdev2/cli#91
Open

Bhanditz mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities Bhanditz/cli#29
Open

varmakarthik12 mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities varmakarthik12/cli#38
Closed

baby636 mentioned this pull request Dec 1, 2023
[Snyk] Fix for 1 vulnerabilities baby636/cli#62
Open

varmakarthik12 mentioned this pull request Dec 1, 2023
[Snyk] Security upgrade npm-registry-fetch from 9.0.0 to 14.0.0 varmakarthik12/cli#42
Closed

MrBrain295 mentioned this pull request Dec 19, 2023
[Snyk] Fix for 3 vulnerabilities MrBrain295/cli#12
Open

CALISOULB mentioned this pull request Dec 20, 2023
[Snyk] Fix for 1 vulnerabilities CALISOULB/cli#21
Open

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 3, 2026
📊 대시보드 데이터 업데이트 (npm#125)
11b7c41

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 15, 2026
🔧 자동 수리 완료 (npm#125)
b09404b

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Aug 9, 2026
🔥 트렌드 선점 후보 갱신 (npm#125)
740d6b2