Question about pipeline failure functionality

[z4l1nux]

It's not clear to me whether the tool has the functionality to fail the pipeline only when new vulnerabilities are found, instead of simply scanning the entire repository again. This would allow blocking only the introduction of new vulnerabilities without affecting already known issues.

Additionally, I would like to know if it's possible to configure the tool to consider only High and Critical vulnerabilities initially, paranoia levels can be created from any severity (Critical, High, Medium or Low), allowing other modules (malware, license, popularity, maintenance, security posture and threats) to be enabled progressively as the team gains maturity.

[abhisek]

@z4l1nux Yep. Both are possible with vet

It's not clear to me whether the tool has the functionality to fail the pipeline only when new vulnerabilities are found, instead of simply scanning the entire repository again.

We built vet-action to wrap vet and easily integrate in GitHub Action with differential scanning support. vet-action can be triggered with a PR where it can detect the packages changed (updated or introduced) in a PR and it will ONLY include those during scan. Using vet-action, we can build CI native security guardrails against "new" risks from being introduced. See example of vet-action integrated with vet

Additionally, I would like to know if it's possible to configure the tool to consider only High and Critical vulnerabilities initially, paranoia levels can be created from any severity (Critical, High, Medium or Low), allowing other modules (malware, license, popularity, maintenance, security posture and threats) to be enabled progressively as the team gains maturity.

This is exactly the reason why we adopted policy as code in vet. You can define what vet considers as risk using your opinionated policies. See example here

To get started with vet in GitHub Actions for policy driven guardrails, see:

• https://github.com/safedep/vet-action

If you are integrating vet-action, do consider enabling Malicious Package Scanning. More info: https://docs.safedep.io/cloud/malware-analysis

[z4l1nux]

During my tests, vet continues to find vulnerable dependencies that were already main and not just the new vulnerabilities included in the PR in another branch.

Another question is, if I remove the other filters from policy.yml and leave only the name: critical-or-high-vulns, will it only fail when this occurs?

[abhisek]

During my tests, vet continues to find vulnerable dependencies that were already main and not just the new vulnerabilities included in the PR in another branch.

Are you use https://github.com/safedep/vet-action? Can you share your vet-ci.yml?

Another question is, if I remove the other filters from policy.yml and leave only the name: critical-or-high-vulns, will it only fail when this occurs?

Yes. It will fail only on policy violation.

[z4l1nux]

name: vet OSS Components

on:
  pull_request:
  push:
    branches:
      - main

permissions:
  contents: read
  issues: write
  pull-requests: write
  security-events: write

jobs:
  vet:
    name: vet
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        id: checkout
        uses: actions/checkout@v4

      - name: Run vet
        id: vet
        uses: safedep/vet-action@v1
        with: 
          policy: .github/workflows/policy.yml
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[abhisek]

This looks good. It should trigger on PR and only vet the changed packages in the PR.

Is it able to add comments in PR? Possible to share a screenshot?

Example:

safedep/vetpkg.dev#9 (comment)

[z4l1nux]

vet Summary Report
This report is generated by vet

Policy Checks
❌ Vulnerability
✅ Malware
✅ License
✅ Popularity
✅ Maintenance
✅ Security Posture
❌ Threats

Threats
LockfilePoisoning
⚠️ Found in manifest package-lock.json, Package string-width-cjs resolved to an URL https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz that does not follow the package name path convention. Refer to this for more details
⚠️ Found in manifest package-lock.json, Package wrap-ansi-cjs resolved to an URL https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz that does not follow the package name path convention. Refer to this for more details
⚠️ Found in manifest package-lock.json, Package strip-ansi-cjs resolved to an URL https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz that does not follow the package name path convention. Refer to this for more details

That seems to have worked now, I think I was doing something wrong before. What would the policy look like for ignoring certain alerts in the event of a false positive being identified, risk accepted and so on? Example: detected threats or Vulnerability, Malware, License, Popularity, Maintenance, Security Posture

[abhisek]

@z4l1nux The threats that you are seeing with package-lock.json are known inconsistent npm package names. We have a trusted-registries config in vet-action to handle those. But given they are recurring across npm code bases, we are handling them as part of vet itself in this PR. Once the PR is merged they should not be shown as threats.

You can fully customize the policies. For example, if you want ONLY vulnerability related guardrails and not anything else then you can simply remove the policy checks for license, popularity, security posture etc. Here is an example of vulnerability policy with custom handling of accepted risks / false positives

name: SafeDep vet OSS suite
description: |
  Customized filter suite for vet vetting vet.
tags:
  - general
  - safedep-vet
filters:
  - name: critical-or-high-vulns
    check_type: CheckTypeVulnerability
    summary: Critical vuln with exception
    value: |
      # Match any critical vulnerability except for given IDs
      vulns.critical.exists(p, (p.id != "GHSA-xxx") && (p.cve != "CVE-xxx"))

For custom policies to work, you need to have a policy.yml somewhere in your repository and pass the path to vet-action else vet-action will use its default policies.

Example:
https://github.com/safedep/vetpkg.dev/blob/main/.github/workflows/vet-ci.yml#L39