As a standard due diligence practice, many companies run security tests against any new software products they adopt. Given StreamSets' unique function as a systems integrator and development platform, it is very common for scanning tools to report various "issues" with the platform. If you see a long list, don't be alarmed! Many of the results may actually be normal and expected. This article describes some common issues detected by these tools along with an explanation of why they might be safe to ignore. 

Of course, you are always welcome to report these issues to StreamSets so we can provide more detailed guidance. We also would not want to miss potential real vulnerabilities that need to be addressed. In that case, we have a few guidelines for making the report as effective as possible -- mainly, please provide the full report (not just a summary) with as much detail as possible.

Note that StreamSets verifies our products against security scans on a regular basis, but since there are many of these tools on the market we can't test against and anticipate the results of everyone.

In general, the security scans fall into three different categories described below. Each one will tend to report different types of issues.

Static Code Analysis:

Static code analysis is a method of analyzing a program without actually executing it (that is, inspecting the source code, which is possible for StreamSets thanks to our open-source nature).  The general trouble with static code analyzers is that they have strong assumptions built-in. So far every tool we have encountered assumes that the Java application is a typical full-stack web application with a backend database. Thus our JDBC stages are frequently tagged as "SUPER-HIGH-CRITICAL" because they enable the user to do "SQL injection". Of course, the whole purpose of our JDBC Origin is to enable users to provide a SQL query. Unfortunately, there is no way we can modify the source code to avoid this type of false positive.

If you would like to report static code analysis results to StreamSets, please provide the full report that contains not only a high-level description but also specific source files and line numbers for where the vulnerability is located. Without specific files and line numbers, our engineering team won't be able to address the vulnerability.

Penetration Tests:

Penetration tests are conducted against a running service in order to find vulnerabilities. They typically use StreamSets' exposed APIs (public and private) to try and make the software do something unexpected. Similar to the static analysis tools, these products tend to have general security assumptions and quite regularly flag various Data Collector origins as dangerous. For example, our RPC origin is in fact intended to open up a listening server port, which most apps would not be expected to do.

When reporting penetration test results, please provide the full report containing the set of steps that lead to unexpected behaviour. Most penetration reports include screenshots or code examples which are helpful. There is also usually a summary report which is not sufficient information for us to work from.

Library vulnerability:

This type of scan is similar to static analysis but checks the software for dependencies (libraries) that are out of date or contain known vulnerabilities. It generally reports a list of libraries (jar files with versions) and possible vulnerabilities that they contain, typically labeled as "CVE-{year}-{sequenceNumber}".

This is where the fact that StreamSets is a system integrator comes into play. We ship and use 3rd-party libraries that other vendors provide. For example, we include the Cloudera Hadoop (CDH) libraries and their dependencies, the AWS Kinesis client, Google Big Query client, etc. However, we do not assume maintenance responsibility for those libraries. These vendors must publish updated versions of their libraries which StreamSets can then incorporate into new versions of our platform.

When you report these types of scan results, please provide the exact location of the affected jar files. Sometimes different stages or 3rd-party libraries use the same dependency jars, so we need to be able to narrow down the affected component. Also note that customers may install their own custom jar files (eg database driver) which can be flagged by these tools, but are not controlled by StreamSets.

With this information in hand, we can help report the vulnerability to the upstream provider or otherwise determine the best course of action. We can also help explain how to delete/disable vulnerable stages so that they are not accessible to end-users if needed.

Conclusion:

Hopefully, this information helps make sense of the results from running a security scan against the StreamSets platform. Many of the results will likely have a benign and reasonable explanation. Feel free to share the full report with us for further guidance.