Sonatype Lifecycle Reviews

We use it to scan applications for open source libraries and to find libraries with a clean version for developers. If one version is vulnerable, they can switch to another version which is clean.

Our situation is that we are running it as a pilot. Hopefully, this year we will be moving the environment into production. Delays happened due to some of our workforce being allocated to different organizations, and then we had the pandemic.

It's deployed on-premise, on a virtual host.

We can automate the pipeline of CI/CD. For example, if a publication uses an open source library and it's vulnerable, then the security team will mark it in the Lifecycle suite and it can go through the pipeline without manual interaction by the developer.

I'm not a security guy but I have sat with the security team. Once you set the policies, you wont need to change them. The policies wouldn't change that frequently. It covers the needs that we have.

Using the solution we have been able to clean our environment, providing more protection for our applications. We have a more hygienic environment than before. Before using Lifecycle we were almost blind to whatever we had and didn't look into the vulnerabilities within open source libraries. Now we do.

It has helped to increase our productivity a lot, especially with Nexus Repository Manager. It is way more agile. There is no comparison between our productivity before and now.

In terms of the accuracy of the data from Sonatype, at first the teams were challenging whatever the solution provided, but they then verified with the vendor of the open source libraries or via the related community, and they realized that the data from Sonatype is something that is done carefully. It's accurate and valid data. We are now introducing a security layer for open source. Before, there was no security on open source and they did whatever they wanted but that is no longer the case. They have to fix things before deploying them. It helps them resolve issues. It works most of the time, but sometimes there are challenges for the developer in solving them.

We also use the solution to automate open source governance and minimize risk with policies. Some of our developers, although not all of them, have their own Jenkins installed and they set rules and policies. They have integrated Jenkins with Lifecycle and, whenever they push into production, it verifies they are not violating any policies. Once everything is smooth, it goes into production. We haven't formalized that process yet.

It's a great tool. We have it connected live to the Sonatype database. Whenever there is a new vulnerability, it's discovered. We have early detection of any vulnerability in our open source library. The scanning capability is its most valuable feature, discovering vulnerable open source libraries.

The reporting capability is good but I wish it was better. I sent the request to support and they raised it as an enhancement within the system. An example is filtering by version. If I have a framework that is used in all applications, but version 1 is used in 50 percent of them and version 2 in 25 percent, they will show as different libraries with different usage. But in reality, they're all using one framework.

This is my second year using Sonatype Nexus Lifecycle.

It's very stable. I don't recall ever seeing problems. The main concern would be data-disk corruption, but I haven't seen it, even though the server, due to patching, has been rebooted multiple times.

When it comes to scalability, there's a limitation in terms of high-availability. Sonatype recommends you go with high-availability. However, you have to have an Active-Passive solution and we don't use a separate installation for each organization. I know there are ways you can install multiple instances for each organization and proxy between them. Because we are a single organization that uses one installation, we have to set it to Active-Passive and manually switch the Passive on and off.

My experience with their technical support has been good, overall.

The problem for us is that we work in a different time zone than they do and the workdays are different. We don't work on Friday and Saturday. If we send them something on Sunday, we don't hear until on Monday. If it is urgent they get back to us.

We used OWASP Dependency-Check, but for only about five months. It needs maintenance. You have to maintain the database library manually, and install it on the developers' workstations. There are a lot of drawbacks with that solution.

If we depend on OWASP Dependency-Check, it is a public vulnerability tool and it is not a good database, to be honest. If you have a library where one version is marked as vulnerable and you go to the community, the owner of the library says all versions are vulnerable. You would not see the vulnerability reflected regarding the versions. You would see it on one version and the others would be marked as clean. The team at Sonatype is doing a good job of maintaining this information very well.

We were working with Repository Manager and the security team switched to a Nexus server to reduce the effort and eliminate duplication. We now also have one, unified solution to cover all the possibilities.

The installation is straightforward in terms of the application itself. However, with our setup, with our environment and the restrictions we have, we had to do a lot of things. But that work was from our side, not from the application's side. 

We did the installation within about two to three days. I was part of our support team at that time. Later on, I added enhancements on-the-go, such as certification. If I were to do the installation now, I would do it within an hour. It is the configuration that you have to get to know. Once you know it, that's it. When it's new to you, you have to take the time to read the documentation to understand what's going on and do things right.

I only worked with the support from Sonatype and I was the only person in our organization involved in the installation. I am also the only one who runs this part of our environment, in terms of maintenance.

We expect to see ROI once we're using it fully in production.

Lifecycle, to the best of my recollection, had the best pricing compared with other solutions.

We ran into too many debates and there was this culture of "security is not mine" and someone else should have to deal with it. After using the solution, they realized this is not the case. Security vulnerabilities had to be addressed. I was a developer and I understood their complaints, but security is important and you have to go with it. The tool is there to automate and simplify your work and you should utilize it. It has been a very good experience.

We are introducing Lifecycle and developers will be aware, with the IDE plugin, from the beginning, whether whatever libraries they are using are vulnerable or not. There should be no delays if they work with it from the beginning.

It is used, or should be used, by all of our 120 developers. But in a group developing a given application, not everyone would commit to it and scan the application. One would do the scanning. But, overall, all of them should be directly or indirectly using it or depending on it.

When we move it to production we will need to do a recertification of the users and find out who is not using it, who would use it, and who is shifting to other organizations. Then we will decide on the number.

We use it as a repository or manager. We store all our software application artifacts. We also use it for the vulnerabilities.

Before, we had open-source Nexus Repository, but with Lifecycle we have Nexus RM and IQ Server as well and we can scan .jars. In addition, we have the plugins for individual developers, which benefits us and the developers when they introduce a new artifact into their applications. It helps them identify what are potential risks and defects. They can resolve them right there and proceed there with their development.

It also brings intelligence to the open-source artifacts, because intelligent servers scan all the vulnerabilities, identify the problems, and then we can ask the individual teams to fix them. That is a plus.

The solution blocks undesirable open-source components from entering our development lifecycle. There are certain .jars which we can block.

In terms of open-source governance, the tool tells us all the threats that are out there in the public sector repositories, threats which, potentially, no one knows. We get to know them and we can use the tool to let other people know which direction to go in.

The solution has improved the time it takes us to release secure apps to market by at least 50 percent. It has also increased developer productivity to some extent because of the plugin which is included for the IDE. It gives a report of the vulnerabilities. It does save time in figuring out the right open-source versions that we need to use. It has helped improve the productivity of the developers by about ten percent.

The way we can define policies and apply those policies selectively across the different applications is valuable. We can define a separate policy for public-facing applications and a separate policy for the internal applications. That is cool.

Since we have public-facing applications, they are more vulnerable, because anyone from anywhere can access them: for example, Excel and Java scripting. We can detect if we potentially have any .jar open-source product that can become vulnerable. We can define stricter policies for the public-facing applications, versus internal where we are protected by the firewall. We already have a more secure way of accessing those internal applications, so we can limit the strictness of the internal policies a little bit. We can relax some of the rules there defining the different levels, from a security perspective. That is useful.

In addition, we like the way, when the product has found a vulnerability, that it also recommends the version in which that particular vulnerability was fixed. It generates a report with all the different types of vulnerabilities that were found. We can then go to individual vulnerabilities and look into the historical information: When, and in what version of the .jar, it was introduced, when it was fixed, and what the usage in the market is for that particular open-source component. That is very useful information to us.

The solution's data quality shows in the way that it recommends the correct artifact that we should use and the different versions that are available. Based on that data we can make better decisions.

It also integrates well with the IDEs. Instead of discovering a problem during deployment, we can identify the problem right at the development phase. That is a cool feature of Lifecycle. We use Bamboo for our builds and the Nexus IQ plugin is compatible with Bamboo. We can scan the vulnerabilities at build time.

It doesn't provide real-time notifications from the scans. We have to re-scan every time, whenever a build happens.

Also, since Nexus Repository just keeps on adding the .jar artifacts whenever there is a build, whenever an application is going up, there is always a space issue on the server. That is one of the things that we are looking for Nexus to notify us about: if it is running out of space.

It is stable as of now, the version we are using. We hope that it continues to work as we expect.

We haven't actually explored scalability. But in terms of scalability, if there is anything that we need to add, like CPU, memory, or any extra RAM, that can be added dynamically. But we are not sure if Nexus would need downtime for things like that.

Technical support has been really prompt.

We used the open-source version before moving to the licensed version of Sonatype.

The initial setup was okay. It was pretty straightforward. We had some hiccups in the migration itself when we migrated from open-source to licensed Nexus. At that time we faced some issues with the configuration and we had that resolved. But the deployment took only an hour.

Because we had an existing, open-source Nexus RM, we had to migrate it to the new, licensed Nexus Pro version. So we had to coordinate with other teams, come up with a plan, and then execute accordingly.

We have only been using the licensed version for six months. But long-term, we definitely see it saving time and that will be our long-term return on investment.

Pricing is comparable with some of the other products. We are happy with the pricing.

We didn't look at any other options. We have been using Nexus for years. We had some initial sessions with them, we did a PoC and we liked the product. We went ahead with it.

Their support is good. They help with understanding the environment. They helped us with the initial PoC work. Their product is configurable. We can customize the policies. We had some hiccups, but it was pretty self-explanatory once we understood all the different parts. It was easy to set up and get going. From an implementation perspective, it's not a complex setup, which is a good thing.

We have ten people using the solution, which includes developers, some of our managers, and architects. For deployment and maintenance of Nexus, we need just one person, a developer.

We have pretty much scanned all of our applications. We have around 30-plus Java applications. Based on the current set of applications and the number of users who are using this product, there are no plans to increase usage at this time. 

We use this product for scanning containers and binary artifacts, and to scan for vulnerabilities. It's provides a software composition analysis mainly for application security. I'm the lead member of technical staff and we are customers of Sonatype. 

The most valuable feature for me is vulnerability detection accuracy.

The main drawback of this product is that it's not an SaaS solution and they really need to build a complete SaaS product. Although the vulnerability detection accuracy is good, the solution is quite weak when it comes to remediation accuracy which is not good. They are currently sorting by component versions and the sorting algorithm is not correct, it requires a proper tool. 

I've been using this solution for four years. 

We are unable to scale sufficiently because everything needs to be installed on our local premises. This is really a solution for small to medium-sized organizations. Every new server requires the installation of a new database. We currently have around 400 users doing a variety of jobs and scalability is the biggest issue we have.

The customer support could be improved. Their response time is quite slow and it can take a long time to deploy new features. 

Neutral

The initial setup is too complex because it's not a cloud service.

Compared to other solutions I've seen, the main issue with Lifecycle is that it doesn't have an on-cloud option.

I can recommend this solution but they need to do some work at their end, particularly with regard to cluster maintenance, scalability, and the fact that it's only available on-prem.

I rate this solution five out of 10. 

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.

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.

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.

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.

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.

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.

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.

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.

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.

ROI on a security product is always hard to argue because you never know how expensive a security issue could become.

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.

I think OWASP Dependency-Check was evaluated before Nexus Lifecycle.

Nexus Lifecycle was chosen primarily for the quality of its scan results.

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.

Sonatype Nexus Lifecycle is mainly used for checking vulnerabilities. For example, the unit test coverage and code quality, including vulnerability code smells.

The most valuable features of the Sonatype Nexus Lifecycle are the evaluation of the unit test coverage, vulnerability scanning, duplicate code lines, code smells, and unnecessary loops. 

Sonatype Nexus Lifecycle can improve by having a feature to automatically detect vulnerabilities. Additionally, if it could automatically push the dependencies or create notifications it would be beneficial.

I have been using Sonatype Nexus Lifecycle for approximately three years.

Sonatype Nexus Lifecycle is a stable solution.

The scalability of the Sonatype Nexus Lifecycle is good. We have not had any issues.

We have 2,000 engineering people using this solution, such as developers, SRE, and QE.

The amount of maintenance Sonatype Nexus Lifecycle needs depends on the competency of the people doing it. It is not very complex to do but it is difficult to find competent work in the area. If the person is competent then the maintenance is not a problem and is straightforward.

I rate Sonatype Nexus Lifecycle an eight out of ten.

Our use case is to check and evaluate third-party libraries for vulnerabilities and licensing problems. We are integrating it into our build pipeline as well.

We're still using it in a PoC and it's not as integrated as it could be so it hasn't changed too much for us right now. But of course, what we want to do is to keep safe, look at the vulnerabilities that come from third-party libraries. It will change our development process and help us improve the security part, the development process.

In the way we are using it now, we have checked several applications manually and gotten some information about vulnerabilities. And we have been able to fix these vulnerabilities with help of the product.

The solution helps automate open-source governance and minimize risk. For example, a developer decides to use an open-source component, so he is going to add Wire Maven into the application. In this phase, he can already get information about possible vulnerabilities. If he ignores this, we can still absolutely detect such a problem later on and prevent it from being sent to production. This is a process which has several steps, of course. We also want to use the firewall to prevent such libraries from downloading, but this is something we haven't done yet.

It has also improved on the time it takes us to release secure apps to market. It was not possible for us, before, to ensure really secure development. But we are still on our way in that regard. Without a tool like this, you can't really find out which vulnerabilities are present. It's only possible if you use such a tool. Because we didn't have this kind of tool before, I cannot say how much time it has saved. I can only say that now it's possible to develop secure applications.

The most valuable feature is that I get a quick overview of the libraries that are included in the application, and the issues that are connected with them. I can quickly understand which problems there are from a security point of view or from a licensing point of view. It's quick and very exact.

The onboarding and policy grandfathering are quite useful, to keep in mind what we have already discussed around parts of the application, and to identify our own parts of the application which are not discovered by Nexus Lifecycle.

The data quality is really very good. We have also checked other products and they do not provide such good quality data. Still, we must look very closely at a single vulnerability from a single issue. We have to understand what problem it's indicating. However, without this tool there would be no way to do this. The data quality is really very good.

It was very easy to integrate into our build pipeline, with Jenkins and Nexus Repository as the central product. It was very easy to integrate the evaluation of the application to be built into the Jenkins process so that we had the ability to check how good the application is thus far. It also helps when you look at the stage we are at in building this application, whether test or production.

If there is something which is not in Maven Central, sometimes it is difficult to get the right information because it's not found.

And if you look at NPM-based applications, JavaScript, for example, these are only checkable via the build pipeline. You cannot upload the application itself and scan it, as is possible with Java, because a file could change significantly, so the applications are not found anymore. This is something that could be improved in future.

Also, I have seen in Black Duck, for example, that there is also information about exploits there are known for a given vulnerability. This is something I haven't seen or haven't found yet in Nexus Lifecycle. If there is a known exploit to a vulnerability, this could be something that is useful to know as well.

Nexus Lifecycle has had no problems until now. There is just a small circle of people using it directly, so this is not a critical mass of users. I cannot say what the stability will be like when there are more people using it. But right now, there is absolutely no problem. It just works.

The users in our company are developers and software architects.

We are using just one instance right now, I don't know how it scales.

We have always had quick responses to questions we had, and they have always been very helpful. The people involved are very smart. They know what to do.

The initial process is straightforward. It took half an hour. We had everything working and then the integration into Jenkins took another half an hour. This was very straightforward. Of course, you must look at the rules and the metrics that are important to you. You must do something regarding the applications you are using and your organizations that are involved. But this is true for every tool.

We are still on our PoC, so there has been no investment up until now. We have just decided to invest in Nexus Lifecycle. I am sure that there will be a return on investment very soon.

Its pricing is competitive within the market. It's not very cheap, it's not very expensive.

We also evaluated Black Duck. We selected Nexus because of the data quality and the ability to integrate it into our build process.

Look very closely look at Nexus Lifecycle to check whether the system is a possibility in your environment. It has good data quality and good integration in our build environment. Everyone must check for themselves whether it is the right solution for them. But I would always advise to have a close look at Nexus Lifecycle, if there are similar requirements to ours.

The Success Metrics feature is something we have not used too much up until now. It's unused because when we started was it was very basic. However, it is a very good means for seeing how successful we have been in reducing the issues that are connected with applications.

We could improve the quality of the third-party libs we are using, and the SDLC is something we are going to improve as well. In this area, we hope Nexus Lifecycle will help us to do so. It's just a part of what there is to do, but Nexus Lifecycle will be very helpful in this kind of process. We can get the information about vulnerabilities and licensing problems very early, when integrating a library into Eclipse, for example. Further on we can scan applications manually and integrate the evaluation into the build pipeline. These things are important as early as possible, but it's also good to have the last look if there is something we do not want in production.

In terms of blocking undesirable open-source components from entering our development lifecycle, we could configure the solution to do so but we haven't done so yet. This is, of course, something we want to do.

As for the tool increasing developer productivity, I would say yes and no. Now we can better deliver secure applications but, on the other hand, there's more to do. Of course, it was just not done before so it would be comparing apples and oranges.

It is possible that we will extend the tool to other development departments, or even to those who are looking at the licenses. We are using it on-premise, right now, and this is something we would continue. We are integrating it with our Jenkins and Nexus-based build pipeline, which is also here on-premise. This is what we are going to do in the next weeks.

During the development, if there are new libraries that need to be used, then we scan them first to see if they are secure or valid. If there is a threat, can we avoid it or use alternatives. Also, before each release, it is mandatory for us to scan the code before we go to release it.   

It was installed at the beginning of the year, so I think we are using the latest version.

We rely on the default policies because we are new to the system. We haven't adjusted any policies and are sticking with whatever policies were shipped to us. We are mostly focused on policies 9 and 10 for the highest threat levels. These are the ones which we are focusing right now. We don't want to make any modifications or adjustments in terms of 9 or 10. Mostly, it will be the security officer's decision if we need to update the policies. I'm the manager of the development team and my developers usually will not make any changes in terms of policies.

It provides a very detailed analysis of our library. Then, when some of the scans identify a licensing issue, we look at them and know if we have the license. It sort of scans everything. Without this tool, I don't think that there's even a capability to go through all these libraries, because some of the libraries were introduced by contractors and a developer who no longer works here anymore. When Nexus comes in with its scans, it reports on licensing or other vulnerabilities. This is easier to do instead of asking around.

The most valuable feature is the scanning part, then the report part, as it is quite easy to read. The report part is very important to us because that is how we communicate to our security officer and the security committee. Therefore, we need to have a complete report that we can generate and pass onto them for review.

The solution’s data quality has been pretty accurate. The ones that we are focusing on now are 9 and 10. Once we adjust and scan them again, they are no longer deemed to be the same threat level, which is good. If I replaced the library with a safer one, they still complain that that's not good. So far, we're pretty happy with the quality.

One thing that I would like to give feedback on is to scan the binary code. It's very difficult to find. It's under organization and policies where there are action buttons that are not very obvious. I think for people who are using it and are not integrated into it, it is not easy to find the button to load the binary and do the scan. This is if there is no existing, continuous integration process, which I believe most people have, but some users don't have this at the moment. This is the most important function of the Nexus IQ, so I expect it should be right on the dashboard where you can apply your binary and do a quick scan. Right now, it's hidden inside organization and policies. If you select the organization, then you can see in the top corner that there is a manual action which you can approve. There are multiple steps to reach that important function that we need. When we were initially looking at the dashboard, we looked for it and couldn't find it. So, we called our coworker who set up the server and they told us it's not on the dashboard. This comes down to usability. 

There is another usability thing in the reports section. When the PDF gets generated, it is different from the web version. There are some components from some areas which only reside inside the PDF version. When I generate the PDF for my boss to review, she comes back with a question that I didn't even see. I see on the reporting page whatever the PDF will be generating. The PDF is actually generating more information than the web version. That caught me off guard because she forwarded this to the security officer, who is asking, "Why is this? Or, why is that?" But, she has no idea. I didn't have anything handy because I saw the PDF version, which should be same as what I see on the web. This is a bit misrepresented. I would like these versions to speak together and be consistent. Printing a PDF report should generally reflect whatever you have on the page.

We have been using it for two or three months now.

It is stable.

Users of the solution include our security officer, our application architect, and me. I manage all of the development and the developers who work on upgrading libraries.

Not many people are needed to maintain this solution. We need two or three people. One person is from our service support where the Sonatype Server is deployed and managed. Another person is the application architect who reviews the libraries.

Scalability is not applicable to us at the moment.

The solution is pretty much involved in every release that we have. So, it's quite frequently being used. We don't have current plans to increase usage. We are working on our continuous integration process. Once that's done, then there will be a need to increase usage.

I haven't opened a support ticket yet.

We did not have another solution that we previously used before Sonatype.

We had one job file we used a long time ago (it was over 10 years ago). At that time, we had purchased a license, but nobody has really used it for a really long time.

I wasn't involved in the initial setup.

This was all done by our service support.

This solution has increased developer productivity by 20 percent. They know the version that they need to use. It is a lot easier.

We are still in the process of automating our deployment.

In terms of the developing the IDE, I don't see a big need because we are mostly focusing on enhancing existing projects. We mostly will be focusing on addressing existing issues and vulnerabilities. For a developer to use a new library all the time, this is not a high priority. Right now, we are working on continuous integration continuous deployment solutions. Then, we will integrate the Sonatype Scanner as part of the build, testing, and release.

I would give it an eight (out of 10). Right now, it is sufficient for us to identify our vulnerabilities. It is quite easy to use and not too much trouble.

Our use case for Nexus is to monitor all of our dependencies and the main thing we're using it for is tracking vulnerabilities listed against those.

It gives alerts for new vulnerabilities before our clients do, so we have time to review them, audit them, and determine how we need to proceed with resolving the issues before we get any client communication.

Before we had this in place, we had a much more reactive approach to CVE listings.   Since integrating this, and as we've refined our process over the past eight months or a year, we have moved to a proactive approach allowing auditing and decisions on mitigation before any incoming client submissions.

In addition, it has brought open-source intelligence and policy enforcement across our software development lifecycle. As a component of the lifecycle, it gives us more controls in place. As far as bringing in dependencies goes, we're able to see what a dependency is introducing, from a security and licensing perspective, before we publish a release to the public. So within the build stage, if we pull in a new dependency, Nexus will very quickly tell us whether it has issues or not. And we catch it. It scans in the build stages; we have it checking our staging where we're doing our regression; and it's also monitoring our released branches and letting us know if issues are found in our releases. It really does hit all stages of that lifecycle.

I like the JIRA integration, as well as the email notifications. They allow me to see things more in real-time without having to monitor the application directly. So as new items come in, it will generate a JIRA task and it will send me an email, so I know to go in and have a look at what is being alerted.

The policy engine is really cool. It allows you to set different types of policy violations, things such as the age of the component and the quality: Is it something that's being maintained? Those are all really great in helping get ahead of problems before they arise. You might otherwise end up with a library that's end-of-life and is not going to get any more fixes. This can really help you to try to get ahead of things, before you end up in a situation where you're refactoring code to remove a library. The policy engine absolutely provides the flexibility we need. We are rolling with the default policy, for the most part. We use the default policy and added on and adjusted it a little bit. But, out-of-the-box, the default policy is pretty good.

The data quality is good. The vulnerabilities are very detailed and include links to get in and review the actual postings from the reporters. There have been relatively few that I would consider false positives, which is cool. I haven't played with the licensing aspect that much, so I don't have any comment on the licensing data. One of the cool things about the data that's available within the application is that you can choose your vulnerable library and you can pull up the component information and see which versions of that library are available, that don't have any listed vulnerabilities. I've found myself using that a lot this week as we are preparing for a new library upgrade push.

The data quality definitely helps us to solve problems faster. I can pull up a library and see, "Okay, these versions are non-vulnerable," and raise my upgrade task. The most valuable part of the data quality is that it really helps me fit this into our risk management or our vulnerability management policy. It helps me determine: 

• Are we affected by this and how bad is it? 
• How quickly do we need to fix this? Or are we not affected?
• Is there any way to leverage it? 

Using that data quality to perform targeted, manual testing in order to verify that something isn't a direct issue and that we can designate for upgrade for the next release means that we don't have to do any interim releases.

As for automating open-source governance and minimizing risk, it does so in the sense of auditing vulnerabilities, thus far. It's still something of a reactive approach within the tool itself, but it comes in early enough in the lifecycle that it does provide those aspects.

The biggest thing that I have run into, which there are ways around, is being able to easily access the auditing data from a third-party tool; being able to pull all of that into one place in a cohesive manner where you can report off of that. We've had a little bit of a challenge with that. There are a number of things available to work with, to help with that in the tool, but we just haven't explored them yet.

We're going on our second year using the solution.

I've never had any stability issues with the application. I haven't performed any of the upgrades, but we've never had any downtime and we've never had any issues with notifications or an inability to access the information we need.

The technical support is fantastic. I reached out with a suspected false negative and had a response within hours, and within the next day they had determined that, yes, it was a false negative and, that same day, the notification came in when they had resolved the issue. So within less than 48 hours of reporting a false negative, I had a full turnaround and the result returned in the tool.

Before IQ server we used an open-source solution called OWASP Dependency-Check. We wanted something a little more plug-and-play, something a little more intuitive to configure and automate.

For the initial deployment, it was in place within a couple of days of starting the trial.

We did have an implementation strategy sketched out as far as requirements for success during the PoC go. The requirements were that it would easily integrate into our pipeline, so that it was very automated and hands-off. Part of the implementation strategy was that we expected to use Jenkins, which is our main build-management tool.

In terms of the integrations of the solution into developer tooling like IDEs, Git repos, etc., I wasn't really part of the team that was doing the integration into the pipeline, but I did work with the team. We didn't have any problems integrating it. And from what I did see, it looks like a very simple integration, just adding it straight into Jenkins. It integrated quite quickly into the environment.

At this point we haven't configured it to do any blocking or build-blocking just yet. But that's something we'll be reviewing, now that we have a good process.

We have absolutely seen ROI with Sonatype. The more proactive approach is definitely a return on investment. It significantly lowers the turnaround for responding to incoming issues. It also empowered our support staff to be able to pass along audit results without having to loop in the security team directly. There is a much lower overhead involved when doing it that way.

Also, the ability to better manage our vulnerability management by getting the detailed information from the scan results or the listings, and being able to audit them thoroughly and test them really helps with development resources in our case. We do not have to cram in a bunch of upgrades just for the sake of upgrading if we're constrained elsewhere. It really helps prioritize dev resources.

I don't know if it has directly saved time in releasing secure apps to market. It has definitely made everything more efficient, but unless things are critical and can definitely be leveraged, we don't necessarily delay a release.

The upgrade processes are definitely a quicker turnaround because it allows us to actually target versions that are not vulnerable. But it is hard to quantify whether, in the grand scheme of things, our developers are more productive as developers.

We looked at things like Black Duck, White Source, and White Hat.

The biggest issue, and this is why we went with Nexus, is that there were more results and there were far fewer false positives than in the other tools.

Take some time configuring your notifications and your JIRA integration properly, along with the policy tweaks. As you integrate and as you first deploy the tool, don't block any builds until you start to catch up on any issues that may be there. Really spend some time with that policy review and make sure it encompasses and aligns with your vulnerability management policy appropriately.

It is incorporated in all of our software branches, and we keep our most recent end-of-life branch active in it just to monitor for critical issues, so we can notify the community to upgrade. We may also add our new mobile application to it.

Nexus Lifecycle is definitely a nine out of 10. I would say 10 if it were a little easier to get the audit information out. Again, there are ways around that so I am not taking off much for that. It's a solid nine. The results are amazing. The quality of the data coming back is great. The audit interface is easy to use.