You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the recent v6 refactoring, investigation of the matching processes led me to believe that matchers should not be directly tied to specific package types. An example of something that causes issues is golang, where go modules should be matched one way, but go stdlib should fall though to standard matching. The stock matcher, for example, could be configured to skip CPE matching for certain types, rather than requiring effectively duplicating the stock matcher to specific package type matchers only to configure them separately.
The text was updated successfully, but these errors were encountered:
During the recent v6 refactoring, investigation of the matching processes led me to believe that matchers should not be directly tied to specific package types. An example of something that causes issues is
golang
, where go modules should be matched one way, but go stdlib should fall though to standard matching. The stock matcher, for example, could be configured to skip CPE matching for certain types, rather than requiring effectively duplicating the stock matcher to specific package type matchers only to configure them separately.The text was updated successfully, but these errors were encountered: