A robust credential scanner would be a huge bonus as it would remove the need for yet another niche product with additional cost, also gives the benefit of a single pane of glass view, although we still need white source bolt for 3rd part library scanning. The integration into docker builds could be better as pulling the latest version of the scanner, setting the path and then invoking the scan is an extra overhead to manage between versions of the scanner. An apt-get and scan start with the key passed as a variable would be a nicer implementation. Have not looked into SSL for the management page yet but hoping that goes smoothly.
Application Security Docker Reviews
Showing reviews of the top ranking products in Application Security, containing the term Docker
I haven't really done a comparative analysis yet.
We're in the process of figuring out how to automate the workflow for QA audit controls on it. I think that's perhaps an area that we could use some buffing. We're a Kubernetes shop, so there are some things that aren't direct fits, which we're struggling with on the component Docker side, nothing major.
Kubernetes is a container-based run-time that works with Docker in terms of container-based applications, so we're a microservice based solution. Microservices are contained inside these containers which are managed by a run-time called Kubernetes. Kubernetes comes out of a Google enterprise. It's used by organizations like Netflix and apps to do continuous development deployment and use integration and development. It means that your container has this application lodging, around which all of the user authentication, run-time controls, and communications integration are handled by Kubernetes.
For instance, an application doesn't really see its DNS at all. It's completely abstract in a way. It is layers away from a virtual hardware. What it does is abstract that patient component into a nice package of business logic that is managed in a dynamic container, which takes care of all the run-time and communication issues that normally become a lot of the configuration overhead of an application.
Once you get your Kubernetes environment behind and organized, that forms a very efficient way to introduce these microservices in a dynamic way and to easily integrate and upgrade components rather than applications. You're much more granular in terms of your release capabilities and much more efficient in terms of how it's released and managed.
I would rate this around seven out of ten, because it has what we need, and it's easy to use.
At first, WhiteSource was great in regards to have a clear picture of what we use in our products.
For us, the most valuable tool was open-source licensing analysis. Although we don't use it on a weekly basis, when we needed to produce a reliable analysis of our open-source licensing exposure, we found it very very effective. Considering the alternatives, which were to analyse manually, WhiteSource saved us a ton of work that we really needed to complete in a short time. It would have involved finding all the different packages, be them in package.json files or analyse the docker images, and then find their effective license, which in itself is not a simple task.
Sonatype Nexus Lifecycle: Docker
They have recently released some online training documentation, because we had to a lot of our own learning. If they had a more comprehensive online tutorial base, both for admin and developers, that would help. It would be good if they actually ran through some scenarios, regarding what happens if I do pick up a vulnerability. How do I fork out into the various decisions? If the vulnerability is not of a severe nature, can I just go ahead with it until it becomes severe? This is important because, obviously, business demands certain deliverables to be ready at a certain time. So, some online tutorials around the administration, around developers, on how to use the tool effectively, would be a good idea.
Where we have extended is that we're using third-party Docker containers. So, we're not just using third-party libraries, but we also have third-party-type Docker containers, or containers from Docker Hub, for example. Somebody else has built the Docker image and we're using the Docker image. Scanning of security and vulnerabilities on that image, specifically, would be useful. It would be good, as we're building an image, or as we're running an image, if we could decompile that image and scan it, to look for any vulnerabilities or any areas where there's been a violation of licensing. For example, we could download a WebLogic container, which could be an infringement of licensing. It's things like that which our developers need to be mindful of. They could simply download any container from Docker Hub, without being aware of the licensing violations or the security vulnerabilities.
We are using the Nexus Repository Manager Pro as exactly that, as an artifact repository. We tend to store any artifact that our application teams build in the repository solution. We also use it for artifacts that we pull down from open-source libraries that we use and dependencies that come from Maven Central. We use it to proxy a few places, including JCenter. We also use it as a private Docker registry, so we have our Docker images there as well.
We're on version 3.19. We also have Nexus IQ server, which wraps up within it Nexus Firewall.
Snyk integrations and notifications with Slack are the most valuable feature because they are really handy. By monitoring dependencies, if there is a vulnerability reported, Snyk will fire off a Slack message to us. With that Slack message, we can create a request just from the notifications which we receive on Slack. It's like having visibility in a general channel and also flexibility to fix that issue with a few clicks.
The solution’s vulnerability database is always accurate since the chances of getting a false positive is very rare. It only reports the vulnerabilities which have already been reported publicly.
The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. Without using Snyk, developers might be not aware if they are creating a vulnerability in their Docker images. While using Snyk, they have at least a layer of protection where they can be notified by a Snyk if there is a vulnerability in the Docker images or communities.
Our whole process of deploying code uses Snyk either as a gateway or just to report on different build entities.
The solution's ability to help developers find and fix vulnerabilities quickly is a great help, depending on how you implement it at your company. The more you empower your developers to fix their stuff, the less policies you will have to implement. It's a really nice feeling and just a paradigm shift. In our company, we had to create the habit of being proactive and fixing your own stuff. Once the solution starts going, it eases a lot of management on the security team side.
Snyk's actionable advice about container vulnerabilities is good. For the Container tool, they'll provide a recommendation about what you can do to fix your Docker, such as change to a slimmer version of the base image. A lot of stuff is coming out for this tool. It's good and getting better.
The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. That is its aim. Since we are letting the developers do all these things, they are owning the security more. As long as the habit is there to keep your stuff up-to-date, Snyk won't have any effect on productivity. However, it will have a lot of effect on security team management. We put some guardrails on what cannot be deployed. After that, we don't have to check as much as we used to because the team will just update their stuff and try to aim for lower severities.
Our overall security has improved. We are running fewer severities and vulnerabilities in our packages. We fixed a lot of the vulnerabilities that we didn't know were there. Some of them were however hard to exploit, mitigating the risks for us, e.g., being on a firewalled server or unreachable application code. Though I don't recall finding something where we said, "This is really bad. We need to fix it ASAP."
We enable Snyk on all of our repos to do continuous scanning for open-source dependency, vulnerabilities, and for license compliance. We also do some infrastructure and code scanning for Kubernetes and our Docker containers.
Snyk integrates with GitHub which lets us monitor all private and public repositories in our organization and it enables developers to easily find and fix up source dependency vulnerabilities, container-image vulnerabilities, and ensures licenses are compliant with our company policies.
There are two use cases that we have for our third-party libraries:
- We use the Snyk CLI to scan our pipeline. Every time our developer is building an application and goes to the building process, we scan all the third-party libraries there. Also, we have a hard gate in our pipeline. E.g., if we see a specific vulnerability with a specific threshold (CDSS score), we can then decide whether we want to allow it or block the deal.
- We have an integration with GitHub. Every day, Snyk scans our repository. This is a daily scan where we get the results every day from the Snyk scan.
We are scanning Docker images and using those in our pipeline too. It is the same idea as the third-party libraries, but now we have a sub-gate that we are not blocking yet. We scan all the Docker images after the build process to create the images. In the future, we will also create a hard gate for Docker images.
We are using it to identify security weaknesses and vulnerabilities by performing dependency checks of the source code and Docker images used in our code. We also use it for open-source licensing compliance review. We need to keep an eye on what licenses are attached to the libraries or components that we have in use to ensure we don't have surprises in there.
We are using the standard plan, but we have the container scanning module as well in a hybrid deployment. The cloud solution is used for integration with the source code repository which, in our case, is GitHub. You can add whatever repository you want to be inspected by Snyk and it will identify and recommend solutions for your the identified issues. We are also using it as part of our CI/CD pipelines, in our case it is integrated with Jenkins.
The initial setup wasn't too complex. They have good documentation, and it's pretty easy. Because our code repository and ticketing system are internal, we had to set up some Dockers to help us with that, but that also wasn't too hard.
The first deployment, until we started scanning the first project, took less than a week. To get it fully working as we expected, exactly how we wanted it, took some more time. That took some months. But the initial setup was really just a few days.
The implementation strategy was that we first wanted to scan the integration with our internal Bitbucket, the code repository, and get Snyk to scan all of the repositories on a daily basis. We had some struggles at first. We wanted to add the developers as users, so they could use the dashboard, but that didn't work so well. So we used a JIRA integration for ticketing and wrote some scripts that use the API to get some information and create tables with action items. Also, we wanted to add it to our CI so that every time a project was being built, a scan would start and the developer would get the information at that moment.
Right now, we're writing an automation to automatically open JIRA tickets with information from Snyk, for the teams. Hopefully, that will make my job more efficient, and even decrease the amount of work I need to do.
If maintenance is required it's on me, but I really only update our Dockers from time to time. There isn't too much maintenance.
Talking about the current situation in our security posture, we decided to choose a platform which could help us to improve our Security Development Lifecycle process. We needed a product that could help us mitigate some risks related to the security side of open source frameworks, libraries, licenses, and IT configuration. We were interested in a solution that could also utilize Docker images that we are using for the deployment. In general, we were interested in a vulnerability scanner platform for performance scans to deliver and calculate our risks related to code development.
Our use case is basically what Snyk sells itself as, which is for becoming aware of and then managing any vulnerabilities in third-party, open-source software that we pull into our product. We have a lot of dependencies across both the tools and the product services that we build, and Snyk allows us to be alerted to any vulnerabilities in those open-source libraries, to prioritize them, and then manage things.
We also use it to manage and get visibility into any vulnerabilities in our Docker containers and Kubernetes deployments. We have very good visibility of things that aren't ours that might be at risk and put our services at risk.
Snyk's service is cloud-based and we talk to that from our infrastructure in the cloud as well.
We have been considering Snyk in order to improve the security of our platform, in terms of Docker image security as well as software dependency security. Ultimately, we decided to roll out only the part related to software dependency security plus the licensing mechanism, allowing us to automate the management of licenses.
We have integrated Snyk in the testing phase, like in the testing environment. We are in the process of rolling the solution out across our entire platform, which we will be doing soon. The APIs have enabled us to do whatever we have needed, and the amount of effort for the integration on our end has been reasonable. The solution works well and should continue to work well after the full-scale roll-out.