Configure WhiteSource for GitHub.com - autoclosed

[mend-for-github-com]

Welcome to WhiteSource for GitHub.com! This is an onboarding PR to help you understand and configure settings before WhiteSource starts scanning your repository for security vulnerabilities.

🚦 WhiteSource for GitHub.com will start scanning your repository only once you merge this Pull Request. To disable WhiteSource for GitHub.com, simply close this Pull Request.

---

What to Expect

This PR contains a '.whitesource' configuration file which can be customized to your needs. If no changes were applied to this file, WhiteSource for GitHub.com will use the default configuration.

Before merging this PR, Make sure the Issues tab is enabled. Once you merge this PR, WhiteSource for GitHub.com will scan your repository and create a GitHub Issue for every vulnerability detected in your repository.

If you do not want a GitHub Issue to be created for each detected vulnerability, you can edit the '.whitesource' file and set the 'minSeverityLevel' parameter to 'NONE'.

If WhiteSource Remediate Workflow Rules are set on your repository (from the WhiteSource 'Integrate' tab), WhiteSource will also generate a fix Pull Request for relevant vulnerabilities.

---

❓ Got questions? Check out WhiteSource for GitHub.com docs.
If you need any further assistance then you can also request help here.

[pmonks]

@maoo this PR is going to need to be submitted against the dev branch if it's to be merged. Right now master isn't building because of platform changes in the Travis CI environment (that have already been addressed in the dev branch), and because of the broken permissions in this repository I'm unable to override the CI failures to merge this PR.

[edit] alternatively I'll prepare a v1.0.1 release, merging in all the changes from dev, then attempt to merge this PR. I'm still not sure I'll be able to do that, again due to the messed up permissions in this repository (despite being project lead, I'm unable to configure / manage this repository).

[pmonks]

@maoo can you confirm whether this repository is setup for Whitespace scanning? Based on the automated actions of the bot above, I can't tell whether it's enabled or not.

[maoo]

Scanning is happening, yes, and no vulnerabilities are found; however, I see that transitive deps are not scanned, and I believe the reason is that WhiteSource Agent doesn't support Leiningen.

We have 2 options:

1. Keep things are they where, use the WhiteSource Agent integrated with Travis CI to submit dependencies to the WS server
2. Generate and push a pom.xml file in the root folder of the repository, which will be scanned by the WhiteSource Agent

Which one do you prefer?

[pmonks]

@maoo back when the project used the (deprecated) Whitesource plugin, that's exactly how it was done. The Travis build script would generate a (transient) pom.xml file (via lein pom), then feed that to Whitesource. Provided we can do something like that (i.e. NOT have a checked-in pom.xml file that needs to be maintained / kept in sync with the leiningen managed dependencies - doing so violates the DRY principle) I'd be fine with this approach.

In parallel, Whitesource should be encouraged to support leiningen and deps.edn, given that these are the de-facto build tools in the Clojure ecosystem. It's also worth mentioning that the implementation of this could be as simple as detecting a Clojure project that uses these tools, running either lein pom (leiningen) or clojure -Spom (deps.edn), then feeding the generated pom.xml file into the existing Maven processing logic.

Alternatively, FINOS may wish to consider certifying other vulnerability scanning solutions for use in the Foundation's projects. clj-symphony has been using OWASP dependency check for some time, and that tool appears to be detecting CVEs that are coming through from the underlying symphony-java-client project [1][2][3].

[maoo]

Provided we can do something like that (i.e. NOT have a checked-in pom.xml file that needs to be maintained / kept in sync with the leiningen managed dependencies - doing so violates the DRY principle) I'd be fine with this approach.

Nothing - that doesn't violate DRY - comes to my mind. Let's try other options...

In parallel, Whitesource should be encouraged to support leiningen and deps.edn, given that these are the de-facto build tools in the Clojure ecosystem.

Agreed. I pinged WhiteSource and I'll follow up on this. Let me get back to you next week, if timing to implement it is short, it may be worth waiting and use this option, agreed?

Alternatively, FINOS may wish to consider certifying other vulnerability scanning solutions for use in the Foundation's projects. clj-symphony has been using OWASP dependency check for some time

That's a perfect alternative to WhiteSource, and I agree we should test and document it on our ODP docs page. I created finos/open-developer-platform#119 and I'll push for prioritization next week, I'll keep you posted. Sorry for any inconvenience!

[pmonks]

No inconvenience! Just trying to make sure my projects all meet the latest set of FINOS requirements that were emailed out earlier this week.