opendevstack / ods-core

The core of OpenDevStack - infrastructure setup based on Atlassian tools, Jenkins, Nexus, SonarQube and shared images
Apache License 2.0
46 stars 34 forks source link

Add security scan for commits in BitBucket #66

Open michaelsauter opened 5 years ago

michaelsauter commented 5 years ago

It would be helpful to scan commits in BitBucket for strings such as URLs and passwords to give users peace of mind before they push this code to GitHub to contribute to OpenDevStack.

Possible solutions:

FYI @ManuelFeller @maksymmaksym @clemensutschig @gerardcl

tbugfinder commented 5 years ago

detect private-keys, credentials, ff like in pre-commit

as long as execution of pre-commit hook isn't overridden...

clemensutschig commented 5 years ago

@michaelsauter - so even prior to SQ (that would do this ... ) right? ..

michaelsauter commented 5 years ago

@tbugfinder Unfortunately there is no way to force people to use pre-commit hooks and no way to detect if it works. So I see pre-commit hooks like frontend validation: nice to have but not reliable :)

@clemensutschig Yes SonarQube might detect this - but I think SonarQube only checks certain files (e.g. Java files) but the offending strings could be in readme files or similar. But maybe SonarQube has a "scan all files for strings" thing, then this would be another option (but again would require us to run all of OpenDevStack repos through Jenkins).

tbugfinder commented 5 years ago

@michaelsauter Definitely it depends on who should benefit of it. A contributor's objective is commiting and/or pushing code without any sensitive data. This could be verified by a pre-commit hook. While maintaining a repo the objective is almost the same but the contributor might already have revealed sensitive information although it does get merged into the repo. In that sense a pre-receive hook is valid, too.

michaelsauter commented 5 years ago

@tbugfinder I think the problem with a pre-commithook is that it cannot be enabled for everyone. So a company might recommend or even mandate that employees use a hook, but to be "safe" as a company, the company will have to be able to enforce the rules in the BitBucket server ... and not rely on the compliance of its employees. I've never seen a pre-commit hook alone work all the time in practice, I always paired it with something on the server side.

michaelsauter commented 4 years ago

For GitHub, see also https://developer.github.com/partnerships/secret-scanning/.

metmajer commented 4 years ago

@michaelsauter @clemensutschig note that we will most likely not make any additional investments into Snyk. An Aqua integration is around the corner, we're currently working out the details. Security scanning for commits is one "opportunity" we're looking into together with the security teams.

michaelsauter commented 4 years ago

@metmajer This is not about "application code scan", but about "ODS code scan" :) ... a very old issue, but I found the GH offering above, which is interesting IMHO. The idea is to help organisations prevent leakage of credentials or similar when contributing to open source.

metmajer commented 4 years ago

@michaelsauter ah, you had actually mentioned that above. Thanks for clarifying! 👍

m-apsolon commented 4 years ago

NB: unrelated to password/URL scanning topic

in regards to Snyk, as a PoC, I've picked up a topic to look into using a plugin provided by them, that can scan the libraries stored/pulled to Nexus... if developers follow the good practise to use the dedicated nexus registries, we would get an additional security benefit to be able to detect flagged libraries, while developing locally. it would also result in getting failed builds, when left unnoticed. if that PoC works, it is a really clean un-opinionated step, that a company could either decide to do, or not, without having a dependency in ODS . :-)

that's something AFAIK we couldn't achieve with Aqua, since it's for scanning images only, unless @metmajer you know something more about it?

stitakis commented 4 years ago

@m-apsolon as far as I know, Snyk collect the list and the version of a 3rd party libs used in a project and reports which 3rd party libs has known vulnerabilities. Are you referring to this Snyk feature?

m-apsolon commented 4 years ago

@stitakis i was looking specifically at https://support.snyk.io/hc/en-us/articles/360004127697-Nexus-Repository-Manager-plugin

stitakis commented 4 years ago

@m-apsolon ah, yes... the Snyk integration with Nexus is a new feature (as least for me :-) I can confirm and as far as I know Aqua do not provide such integration. Thanks for the feedback!

m-apsolon commented 4 years ago

@stitakis Aqua provides image scanning on nexus, but not quite what I'm after :)

gerardcl commented 4 years ago

hi! right! Aqua Security is indeed covering both OS packages and language-specific dependencies and can also be integrated into organizations' software development pipelines. I think the value of @m-apsolon 's approach is to have less third-party vendor dependencies into ODS at the end, and in this case let organizations decide what to integrate to when requiring scanning for security vulnerabilities.

maksymmaksym commented 4 years ago

https://www.aquasec.com/integrations/ In addition I asked the vendor to comment on the feature, will come back to you asap

renedupont commented 4 years ago

I don't see that going very far yet tbh. It happens quite often that you have vulnerabilities in your code that are either not exploitable in your application or are unrelevant due to other precautions you took. If I can't build my app because nexus does not allow me to get the required dependencies because it flags it as e.g. severe but I know it would be ok I can't do much about it. Image you have such a case when you have to deploy a hotfix to a production system where in the meantime since the last deploy a required dependency got flagged by nexus and you can't proceed...

m-apsolon commented 4 years ago

@renedupont while I agree with what you say, checking things out never hurts :) ... and we pretty much came to the same conclusion (also after having a meeting with Snyk guys):

Nexus plugin is just meant to be an additional protection, which won't be reasonable in our case:

  • scans too slow (library installation goes over Snyk API calls)
  • no support for not failing the download, when threshold set to "null"
  • we detected some bugs, that should definitely be resolved in the plugin