What is our primary use case?
At the moment, we are primarily targeting security vulnerabilities, and only those with high severity.
We have it configured not to block anything at this stage. We only aim for visibility at the moment. We might eventually start blocking or failing builds, but right now, we only want to have visibility.
We are still pretty early in our adoption phase. We are onboarding new applications much quicker than we are remediating issues in the existing ones.
How has it helped my organization?
For the application onboarding, we are focusing on automating that as much as possible. Considering the amount of applications that we scan, it's probably not feasible to do all that within the GUI, but the APIs provided by the solution are really good. We have some positive impressions for that. The automatic onboarding seems to work quite well.
One thing we recently did is we automatically onboarded every application that we deployed to production. We scanned each one of them and now have a complete picture of our estates. Every single vulnerability introduced from an open source component is now visible, and we have a clear number. That number was big. Really, we have a lot of issues which we were unaware of. We suspected that we had them, but we now have a clear number that makes selling the solution internally a lot easier.
The solution brought open source intelligence and policy enforcement to a small extent across our SDLC (software development lifecycle) because we have only fully rolled it out in a small number of teams. However, where we did do this, we have started scanning right at the built face, seeing issues really early in the lifecycle.
The solution automates open source governance and minimizes risk. We are trying to reduce the amount of vulnerabilities that we introduce using open source codes. The entire goal of why we're doing this solution is to have it in the lifecycle of our software development and reduce risk.
What is most valuable?
The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it.
The solution integrates well with our existing DevOps tools. We have a few different ways of integrating it. The primary point is the Jenkins plugin to integrate it into the pipeline, but we also use the API to feed applications from our self-developed systems. So, the Sonatype API is very valuable to us as well. We've also experimented with IDE plugins and some other features that all look very promising.
What needs improvement?
The GUI is simple, so it's easy to use. It started as great to use, but for larger scale companies, it also comes with some limitations. This is why we tried to move to more of an API approach. So, the GUI could use some improvements potentially.
Something else that's a bit lacking is most of our components are not explicitly included but are transitive dependencies. We have 50 applications that all report security issues, but they all come from one central library that we built ourselves, which is also scanned by Lifecycle. So, we have 51 components, and we are not seeing that only one of them is really the one we should be targeting. What would be really great in the solution would be some dependency graphing, or at least collecting the transitive dependencies. That would help for larger scale implementations.
The Success Metrics report is really focused on very specific numbers that are not interesting to us. They are for when you are much further along in the onboarding process. There is an API which allows you to retrieve the data on which the Success Metrics are based. We use this API to create our own charts, reflecting what we're looking for.
For how long have I used the solution?
My company started its POC about two years ago.
I only started at the company in September last year, so my experience only accounts for the last four months.
What do I think about the stability of the solution?
I think we have had zero downtime since I have been here. I didn't hear that there ever was an issue before, so it's been absolutely great.
Part of the deployment and maintenance is done by me. Upgrading the solution to a new level has only been done by one single person in the past, who spent three to four hours per upgrade on it. It's really low maintenance for us.
What do I think about the scalability of the solution?
We have had absolutely no issues with scalability. We built it for a small PoC. We have now scaled it to scan our entire application landscape on the exact same hardware that it was sized on at the beginning and we have had zero issues. So, it's absolutely great.
The solution is only very limited in its current usage. Our current adoption rate is 10 percent. We plan to hopefully introduce it into every application that we build in a language that is supported by Nexus.
At the moment, we have 20 licensed users. These are primarily IT security managers (such as myself), developers, and product owners.
How are customer service and technical support?
This technical support is very good and extremely quick. I have had two or three support cases and none of them took longer than a day to get a response. Sometimes, they respond, "No, the solution cannot do that. We have built it in that way and you need to raise a product improvement requests." So, it's not always what you hope to receive, but at least the answer is always clear and quick.
Most of the time, the data quality is very good. We have had some cases where there were some weird results or errors in it. But, when I contacted support, most of the time they managed to fix it or explain why it wasn't displayed in the way I was expecting.
How was the initial setup?
The central IT service organization in our firm manages all our Linux setups and stuff like that. He primarily repackages the installer into an RPM for our Linux service. Usually, the upgrade is just totally painless and right off the books.
What was our ROI?
ROI on a security product is always hard to argue because you never know how expensive a security issue could become.
What's my experience with pricing, setup cost, and licensing?
The price is good. We certainly get a lot more in return. However, it's also hard to get the funds to roll out such a product for the entire firm. Therefore, pricing has been a limiting factor for us. However, it's a fair price, and I'm confident that we can sell this story appropriately.
Which other solutions did I evaluate?
I think OWASP Dependency-Check was evaluated before Nexus Lifecycle.
Nexus Lifecycle was chosen primarily for the quality of its scan results.
What other advice do I have?
Look into the API early. Try to scan as much as possible to get an impression of your landscape before you start rolling it out, then you can easily target the teams and applications mostly needed.
The solution makes it easier for us to deploy secure applications. On the other hand, it also introduces a new something that developers didn't really care about before. In some cases, it increases time to market, but for very good reasons. We produce more quality products.
If you consider that developers would test their own research in the past, then their productivity should increase. Unfortunately, most of the time, the hygiene of open source components is a new topic. This is basically new work that we are introducing, so it's hard to compare it to something that wasn't properly done before.
I would rate the solution as an eight (out of 10).
We haven't used the grandfathering feature.
Which deployment model are you using for this solution?