@laurentsimon FYI...

is there value in alerting repo owners that some code in their repo downloads software unpinned, even if it's in vendor/ directory? Wdut?

Instead of disabling the check for vendor directories, an alternative would be to provide an option to configure which directories to be discarded. The main issue with this is that the default run we make (and made public via BQ table) would not have have the option turned on based on each repo's preference.

An alternative solution could be to add this in the policy files. This way, a result would contain a universal/canonical/ground truth result, and anyone could apply a policy/view to the result (e.g., discard certain directories based on the policy they apply).

Maybe worth further discussion in the meeting?

Yes, I like the policy idea. It is up to the repository owner to decide what is critical for them. Let's discuss this in our meeting.

Completely agree with the benefits of splitting the analysis between the current repository and its (vendored) dependencies, as at the moment this results in "false positives" - considering the target repository as scope of the pinned dependencies scoring.

To some extent, anything related to a project's dependencies could be better handled on a category of its own around supply chain scoring.

@laurentsimon @naveensrinivasan did this discussion happen? Was there any agreement on the way forwards?

Completely agree with the benefits of splitting the analysis between the current repository and its (vendored) dependencies, as at the moment this results in "false positives" - considering the target repository as scope of the pinned dependencies scoring.

To some extent, anything related to a project's dependencies could be better handled on a category of its own around supply chain scoring.

@laurentsimon @naveensrinivasan did this discussion happen? Was there any agreement on the way forwards?

We didn't get a chance to discuss about this.

Do you have any suggestions?

@naveensrinivasan thank you for the quick reply.

My suggestion would be:

1. The vendor folder to be removed from the Pinned-Dependencies checks for golang projects.
2. Create a new check that would aggregate Dependency Violations from dependencies that are found at the BQ table.

This way the information is still available, and in both cases actionable. The latter requiring upstream contribution or the replacement of a given dependency.

Thanks for the suggestion. If we can easily map vendored dependencies to their original GitHub project - which I think is doable for golang projects - I think that would work. For which other languages would it work or not work?

• C/C++ won't work, unless the vendored dependences use GitHub link?
• ?

I am not aware of any major language that supports vendoring quite the same way as golang.

• .Net (C#/VB/etc): won't work as source code vendoring is not a practice generally followed/supported.
• Java: same reason as above.

This may work for NodeJS, but I am not sure there is a specific structure (or folder name) that is used across the community.

thanks. So essentially we need a list of folder names to exclude (vendor, vendors, vendored, third_party, thirdparty, thirdparties, third_parties, external, externals, etc).

Is this the best heuristics we can use? Or are there other ways to do this?

cc @peterhsshin

Yes, that's a good heuristics. Set up an environmental variable with the list of folder names or paths to exclude. The folder names vary too much to come up with an absolute list. It's best to leave it up to the users to edit/modify.

On the other hand, make sure these pinned vendor lists are not seen or checked into the public repository. It can potentially lead to security or data breaches.

On the other hand, make sure these pinned vendor lists are not seen or checked into the public repository. It can potentially lead to security or data breaches.

what do you mean?

Dockerfiles fixed by #3675 (comment)

I'm not sure this is entirely fixed. Dockerfiles are just one aspect of the Pinned-Dependencies check

The other alternative is just letting this be part of maintainer annotation feature.

cc @gabibguti (Maybe vendored is another qualifier that can be added later, similar to test data but different name)