Setup elasticsearch dependency monitoring with Snyk #87620
Comments
|
Pinging @elastic/es-delivery (Team:Delivery) |
|
We discussed initially that all dependencies that are shipped as part of our distribution should be scanned. Ideally I think it would make sense to scan all dependencies to some degree. Even test dependencies can be a concern of security even though its less likely compared to production dependencies. |
That's an interesting point! My thoughts:
I'm inclined to prefer to try and capture all dependencies and try to figure out if there is a way to differentiate on presentation/impact analysis/prioritisation based on what configuration this comes from. We could have different SCA projects/organisations for test/production code, for instance. |
Agree our higher priority should be to the dependencies included in the shipped products. That said, there is risk with the test-code, build-code, etc. we should be concerned with vis-a-vis 'supply-chain attacks' that target build environments specifically.
My assumption (possibly mistaken) has been that published SBOMs would include only what is included in the released product and would not include test code. |
This would be my understanding as well. I think publishing test dependencies would only cause confusion for folks. From my perspective test dependencies are completely internal and have nothing to do with the delivered software. I'd argue we should explicitly omit them for that reason, completely independent of the level of effort of including this information. |
|
Understood. So for now we will only monitor dependencies for now that are shipped with our distro and can be a potential security thread for our customers. |
…de (#88036) This adds the generation and upload logic of Gradle dependency graphs to snyk We directly implemented a rest api based snyk plugin as: the existing snyk gradle plugin delegates to the snyk command line tool the command line tool uses custom gradle logic by injecting a init file that is a) using deprecated build logic which we definitely want to avoid b) uses gradle api we avoid like eager task creation. Shipping this as a internal gradle plugin gives us the most flexibility as we only want to monitor production code for now we apply this plugin as part of the elasticsearch.build plugin, that usage has been for now the de-facto indicator if a project is considered a "production" project that ends up in our distribution or public maven repositories. This isnt yet ideal and we will revisit the distinction between production and non production code / projects in a separate effort. As part of this effort we added the elasticsearch.build plugin to more projects that actually end up in the distribution. To unblock us on this we for now disabled a few check tasks that started failing by applying elasticsearch.build. Addresses #87620
We will use target reference to distinguish between different versions or branches of our elasticsearch project to be able to trace vulnerable dependencies down to the version. snyk lifecycle property allows filtering the project overview by `production` or `development`. When version is ending with SNAPSHOT we configure the lifecycle as development. Otherwise its production. Related to elastic#87620
) We will use target reference to distinguish between different versions or branches of our elasticsearch project to be able to trace vulnerable dependencies down to the version. snyk lifecycle property allows filtering the project overview by `production` or `development`. When version is ending with SNAPSHOT we configure the lifecycle as development. Otherwise its production. Related to #87620
…de (elastic#88036) This adds the generation and upload logic of Gradle dependency graphs to snyk We directly implemented a rest api based snyk plugin as: the existing snyk gradle plugin delegates to the snyk command line tool the command line tool uses custom gradle logic by injecting a init file that is a) using deprecated build logic which we definitely want to avoid b) uses gradle api we avoid like eager task creation. Shipping this as a internal gradle plugin gives us the most flexibility as we only want to monitor production code for now we apply this plugin as part of the elasticsearch.build plugin, that usage has been for now the de-facto indicator if a project is considered a "production" project that ends up in our distribution or public maven repositories. This isnt yet ideal and we will revisit the distinction between production and non production code / projects in a separate effort. As part of this effort we added the elasticsearch.build plugin to more projects that actually end up in the distribution. To unblock us on this we for now disabled a few check tasks that started failing by applying elasticsearch.build. Addresses elastic#87620 # Conflicts: # build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/BuildPlugin.java # client/benchmark/build.gradle # client/test/build.gradle # distribution/tools/cli-launcher/build.gradle # distribution/tools/java-version-checker/build.gradle # distribution/tools/windows-service-cli/build.gradle # rest-api-spec/build.gradle # test/framework/build.gradle
…stic#88220) We will use target reference to distinguish between different versions or branches of our elasticsearch project to be able to trace vulnerable dependencies down to the version. snyk lifecycle property allows filtering the project overview by `production` or `development`. When version is ending with SNAPSHOT we configure the lifecycle as development. Otherwise its production. Related to elastic#87620
Adds a new ci Jenkins job configuration for running snyk dependency monitoring on a daily basis. We setup a service account in snyk and resolve the api token for publishing in vault. Related to #87620
Adds a new ci Jenkins job configuration for running snyk dependency monitoring on a daily basis. We setup a service account in snyk and resolve the api token for publishing in vault. Related to elastic#87620
…de (elastic#88036) This adds the generation and upload logic of Gradle dependency graphs to snyk We directly implemented a rest api based snyk plugin as: the existing snyk gradle plugin delegates to the snyk command line tool the command line tool uses custom gradle logic by injecting a init file that is a) using deprecated build logic which we definitely want to avoid b) uses gradle api we avoid like eager task creation. Shipping this as a internal gradle plugin gives us the most flexibility as we only want to monitor production code for now we apply this plugin as part of the elasticsearch.build plugin, that usage has been for now the de-facto indicator if a project is considered a "production" project that ends up in our distribution or public maven repositories. This isnt yet ideal and we will revisit the distinction between production and non production code / projects in a separate effort. As part of this effort we added the elasticsearch.build plugin to more projects that actually end up in the distribution. To unblock us on this we for now disabled a few check tasks that started failing by applying elasticsearch.build. Addresses elastic#87620 # Conflicts: # test/framework/build.gradle
…ion code (#88036) (#88566) * Setup elasticsearch dependency monitoring with Snyk for production code (#88036) This adds the generation and upload logic of Gradle dependency graphs to snyk We directly implemented a rest api based snyk plugin as: the existing snyk gradle plugin delegates to the snyk command line tool the command line tool uses custom gradle logic by injecting a init file that is a) using deprecated build logic which we definitely want to avoid b) uses gradle api we avoid like eager task creation. Shipping this as a internal gradle plugin gives us the most flexibility as we only want to monitor production code for now we apply this plugin as part of the elasticsearch.build plugin, that usage has been for now the de-facto indicator if a project is considered a "production" project that ends up in our distribution or public maven repositories. This isnt yet ideal and we will revisit the distinction between production and non production code / projects in a separate effort. As part of this effort we added the elasticsearch.build plugin to more projects that actually end up in the distribution. To unblock us on this we for now disabled a few check tasks that started failing by applying elasticsearch.build. Addresses #87620 # Conflicts: # test/framework/build.gradle * Fix license report when backporting
Adds a new ci Jenkins job configuration for running snyk dependency monitoring on a daily basis. We setup a service account in snyk and resolve the api token for publishing in vault. Related to elastic#87620
|
We've integrated the snyk monitoring data publishing of released versions as part of the elasticsearch finalize release step |
We want to monitor the elasticsearch dependencies on a regular basis using Snyk to be able to recognise vulnerabilities faster and being able to proactively react on security issues within the production dependencies.
The text was updated successfully, but these errors were encountered: