Problem with Proprietary Components and npm packages

Sonatype Lifecycle & Repository Firewall
, ,
1

I have a frontend application that is pulling a couple of proprietary dependencies from our nexus repository.
Sonatype Lifecycle will flag these dependencies for critical policy violations against “License-None” because these packages do not contain a licenses.

My solution was to set a constraint on the policy so a component is only in violation if "Proprietary is false".
I then tried to add a Proprietary Component on the Root Organization level that would match all my proprietary frontend packages.
The package names are all of the form ${companyName}-${packageName}, so I tried to configure a Matcher Type of “Package” with the value ${companyName}-.
This did not work, as my dependencies were still flagged as violating License-None.

Then I read through the Proprietary Components documentation and decided to try a RegEx Matcher for matching a particular filename which would turn the component proprietary.
I instructed our frontend teams to add an empty file named .${companyName}-proprietary to the root of each proprietary package and configured a matcher of type “Regular Expression” on that filename.
Still this did not work and the components are not correctly recognized as proprietary components.

So now my question: has anyone gotten something similar to work? Is the proprietary components matcher even implemented for npm packages, or is it just for Java?
Or am I completely on the wrong track here and misusing a feature for unintended purposes?

Any help would be appreciated, cause the current solution of issuing waivers per proprietary dependency, reaaally doesn’t scale well :smiley:

2

Hi Daniel,
Thank you for your inquiry. The steps you were taking were indeed correct for Java applications. Currently, the Proprietary Component Matchers feature is specifically designed to function with Java.
Regarding the License-None policy, it’s important to note that it wasn’t considering the source of detection (Sonatype or Manifest (package-lock.json)), resulting in unknown components in the manifest triggering this policy. Suggested change to your License-None policy (see attached screenshot)

image
image718×119 7.26 KB

My recommendation would be to implement a separate policy for these unknown manifest-only components, preferably at a lower policy threat level for informational purposes.
As a side note, there is a method to distinguish components using the “Identification Source” constraint. This feature offers several options, including Sonatype, IaC, Claire, Manual, and Package Manifest.

I hope this information helps clarify the situation. Let me or your customer success representative know if you have any further questions.

3

This is a gap in the product currently for any custom code that is reused / included. I’ve put in an idea as we were directed to exclude them from scanning. We did not want to do that and allow findings to be deployed within the reuse application using them. Please help vote for the idea, or comment and improve it. If you rewrite it, let me know and I’ll happily vote for yours as well. Sign in to sonatype

1 Like