Skip to content

Conversation

agatakrajewska
Copy link
Contributor

@agatakrajewska agatakrajewska commented Sep 12, 2025

Pull Request Submission Checklist

  • Follows CONTRIBUTING guidelines
  • Commit messages
    are release-note ready, emphasizing
    what was changed, not how.
  • Includes detailed description of changes
  • Contains risk assessment (Low | Medium | High)
  • Highlights breaking API changes (if applicable)
  • Links to automated tests covering new functionality
  • Includes manual testing instructions (if necessary)
  • Updates relevant GitBook documentation (PR link: ___)
  • Includes product update to be announced in the next stable release notes

What does this PR do?

We're fixing an issue where where:

You have ignores with different casing e.g. NPM:HAWK:20160119 vs npm:hawk:20160119
The first ignore is expired
The other ignores that are active do not have the same casing
Then no ignores are applied to the vuln
What was happening in the logic is that we were setting the value of the vulnId to the value of whatever matches first when checking the ignore keys. That vulnId is then used to check the ignores, so if you have other ignores that do not have the same casing exactly they are never checked.

This PR introduces logic to have a variable for all matching vuln IDs with all types of casing to then check the ignores against, so every ignore stored against the vuln ID no matter what the casing is will be checked.

What's the product update that needs to be communicated to CLI users?

We're fixing an issue where where:

You have ignores with different casing e.g. NPM:HAWK:20160119 vs npm:hawk:20160119
The first ignore is expired
The other ignores that are active do not have the same casing
Then no ignores are applied to the vuln
What was happening in the logic is that we were setting the value of the vulnId to the value of whatever matches first when checking the ignore keys. That vulnId is then used to check the ignores, so if you have other ignores that do not have the same casing exactly they are never checked.

This PR introduces logic to have a variable for all matching vuln IDs with all types of casing to then check the ignores against, so every ignore stored against the vuln ID no matter what the casing is will be checked.

Risk assessment (Low | Medium | High)?

Low

What are the relevant tickets?

https://snyksec.atlassian.net/browse/IGNR-1530

@agatakrajewska agatakrajewska requested review from a team as code owners September 12, 2025 11:53
Copy link

snyk-io bot commented Sep 12, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

license/snyk check is complete. No issues have been found. (View Details)

code/snyk check is complete. No issues have been found. (View Details)

We're fixing an issue where where:

You have ignores with different casing e.g. NPM:HAWK:20160119 vs npm:hawk:20160119
The first ignore is expired
The other ignores that are active do not have the same casing
Then no ignores are applied to the vuln
What was happening in the logic is that we were setting the value of the vulnId to the value of whatever matches first when checking the ignore keys. That vulnId is then used to check the ignores, so if you have other ignores that do not have the same casing exactly they are never checked.

This PR introduces logic to have a variable for all matching vuln IDs with all types of casing to then check the ignores against, so every ignore stored against the vuln ID no matter what the casing is will be checked.

IGNR-1568
@agatakrajewska agatakrajewska force-pushed the fix/IGNR-1530-fix-ignores-casing-issue branch from 2a84677 to b432406 Compare September 16, 2025 07:57
@agatakrajewska agatakrajewska merged commit 3323aa6 into main Sep 16, 2025
8 checks passed
@agatakrajewska agatakrajewska deleted the fix/IGNR-1530-fix-ignores-casing-issue branch September 16, 2025 11:06
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.

2 participants