Skip to content

Conversation

@kawsarahmedbhuiyan
Copy link
Contributor

Problem

Poutine reports false positives when workflows use mutable version tags like @v4 instead of specific versions like @v4.1.7.

When Poutine encounters @v4, it expands it to v4.0.0 and incorrectly flags it as vulnerable.

Example False Positive

- uses: actions/download-artifact@v4  # False positive - reported as vulnerable

The v4 tag actually points to the latest and secure version as mentioned in GHSA-cxww-7g56-2vh6. But Poutine treats it as v4.0.0.

Solution

Added non_vulnerable_exact_versions field as suggested in #245 by @fproulx-boostsecurity.

This field allows excluding specific mutable tags from vulnerability matching, while still catching actual vulnerable versions.

Changes Made

1. Data Structure Enhancement (osv.rego)

Added non_vulnerable_exact_versions field to advisory entries:

"non_vulnerable_exact_versions": ["v4"],

2. Matching Logic Update (known_vulnerability_in_build_component.rego)

Modified step_advisory() to:

  • Preserve the raw version string (e.g., "v4") before trimming
  • Check if the raw version is in the exclusion list
  • Only proceed with semver checks if not excluded

3. Applied to GHSA-cxww-7g56-2vh6

Added "v4" to the exclusion list for actions/download-artifact vulnerability.

Benefits

  • ✅ Eliminates false positives for mutable tags
  • ✅ Still catches actual vulnerable versions (v4.0.0, v4.1.6, etc.)

Fixes #245

References

Add non_vulnerable_exact_versions field to exclude mutable tags
like 'v4' from vulnerability checks.

- Added non_vulnerable_exact_versions to advisory structure
- Updated matching logic to check exclusions before semver matching
- Added 'v4' to GHSA-cxww-7g56-2vh6 exclusion list

Fixes boostsecurityio#245
Copy link
Contributor

@fproulx-boostsecurity fproulx-boostsecurity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, what do you think @SUSTAPLE117

@fproulx-boostsecurity
Copy link
Contributor

@kawsarahmedbhuiyan tests fail, make sure to read the README section about development best practices to contribute to the project

BTW, you must not modify directly the opa/rego/external/osv.rego file since it's generated by a CVE DB update script

The README has this section on how to update

go test -tags build_platform_vuln_database ./...
opa fmt -w opa/rego/external/build_platform.rego

I know that I quickly thought about this solution in #245 (comment) , but it may not be the best solution. Think about it and says what's the best approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

False positive about a vulnerable action version number

2 participants