Sonatype Lifecycle Reviews

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. 

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. 

We use Nexus Lifecycle to check our third-party libraries for vulnerabilities. 
There are also different application teams that use Nexus Lifecycle to configure our product. I'm one of those product users, so I can only talk about it from the perspective of my product. 

The team managing Nexus Lifecycle reported that their internal libraries were not being identified, so they have asked Sonatype's technical team to include that in the upcoming version.

We have been using Nexus Lifecycle for about a year and a half.

Nexus Lifecycle is stable. 

Nexus Lifecycle scales to the level we need. It's working fine.

Sonatype support is quite responsive. When we needed something, we could reach out and set up a meeting. They provide the best support possible.

Setting up Nexus Lifecycle is simple.

We evaluated Veracode, and we evaluated Black Duck, as well. The marketing team from Sonatype was more responsive and followed up on the progress during the proof of concept, so that was one reason we chose Lifecycle, but the features are almost exactly the same across products.

I rate Nexus Lifecycle eight out of 10. 

We have a few applications that we're developing that use several different languages. The first ones we did were Python and Yum Repository applications. Recently we've started scanning C and C++ applications that use Conan Package Manager. We will soon start doing node applications with NPM. Our use case is that we primarily rely on the IQ server to ensure we don't have open source dependencies in our applications that have security vulnerabilities, and to ensure that they're not using licenses our general counsel wants us to avoid using.

When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process, in general. The build stages are a good template for us to help establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages that align with the Nexus Lifecycle build stages.

Going to the Nexus product encouraged me to look for a package manager solution for our C and C++ development. My customer success engineer, Derek, recommended that we go to one that Sonatype was considering integrating with the product, which was called Conan Package Manager. I started doing research with Conan and realized how beneficial it would be for our C and C++ development cycle. Transitioning to that has really changed our whole C and C++ development. It was because we needed to have Nexus scanning for our C applications and I needed Conan to do that.

It's because of Conan that we've reduced our build timelines from weeks because we have so many architectures that we build for. After we figured out how to use it, we can build everything with only a couple of commands. Now, it's a really integrated process for our C and C++ applications, from development to the build pipelines to the IQ scanning, and the Nexus Repository manager repositories that we're using for building and packaging. It's been a fun process.

In terms of the data quality, everything has been really good for our Python and our Yum repositories. I know that they are still building their capability for the Conan repositories, the C dependencies. Right now, what Derek has told me, is that Conan application are analyzed with what they call Low Quality Assessment, or LQA. Essentially, any package that has identified vulnerabilities will show up, otherwise, there's not much information on the package. So scanning for Conan is not as good as Python right now, but I know they're working on higher quality data for Conan packages.

Comparing LQA in Conan to something like the higher quality data available in Python repositories does show a difference. For example, Nexus IQ identified a vulnerability in a Python package that we don't use, but it's a transitive dependency in four packages that we do use. We discovered the root vulnerability causing the problem in our four packages with the higher quality data, but we may not have been to do that as easily with a vulnerability identified in multiple C packages without the higher quality data. I'm not sure.

Nexus will block undesirable open source components from entering our development life cycle. We've agreed on the governance of our policies for blocking builds automatically and we've set a date, for example, to start failing builds automatically on July 15.

It integrates very well with our existing DevOps tools. The Azure DevOps Nexus IQ plugin was really easy. All we did was go to our DevOps portal, go to the add-ins, and then search the list for Nexus. We just clicked on it and it installed in DevOps. There are a couple of help pages on Sonatype's webpage, and I send those to the developers, they add the IQ plugin to the build pipeline and it just works. It's really nice also because the IQ plugin for DevOps gets updated before I can even go check on it. They've released two updates since we installed it. Every time I hear from Derek that they've updated the IQ plugin, I go to the IQ plugin page on our DevOps server, and it's already been updated. It's totally seamless for us.

It has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications. We're still integrating it with all of our applications, but it definitely has brought the kind of intelligence that we needed.

Part of our use case is that we use Azure DevOps, so we have continuous integration, continuous deployment pipelines in Azure DevOps. The Nexus plugin for DevOps allows us to just include the IQ scan as part of the pipeline deployment. It's very seamless for our users. They don't even have to think about it until they have a violation. IQ informs them or stops the build, and the developers have to resolve it. 

The default policies were very good for us. We're using all of the default ones except for setting the warning and the stop features at different build stages. It definitely provides the flexibility we need.

We're not at the point in our deployment of the software to where we're doing automated git pulls and where it will automatically resolve vulnerabilities by downloading new packages. We haven't done that, but the integration with our Azure DevOps pipeline has been very seamless. I don't know of any developers that are using the integration with visual studio IDE.

The thing that they're already addressing is high-quality data for the Conan dependencies. They're very responsive to user needs. We're one of the first organizations to use Conan, so I identified a discrepancy in how they were scanning the dependencies, and they added the functionality within four weeks or so. The team is incredible. I can't think of any other ways that it could improve it.

When Conan support was first added to Nexus IQ, it would only scan one file type for dependencies. We don't use that specific method in Conan, but rather, another acceptable method for declaring dependencies that IQ wasn't scanning. I think the Sonatype developers  didn't even know about it because they learning Conan as much as we were. I informed them of the other file type for declaring dependencies and they quickly added the functionality.

I started installing it at the beginning of this year.

I've never had any problems with it, so it's been very stable.

I don't know about the scalability yet because we are small and we don't have that many applications or packages yet. I haven't had to scale it. I designed, from the beginning, the storage architecture of my Repository Manager to be scalable because I knew a lot of the large data will sit there. I designed that upfront to be scalable to other storage volumes or even other servers. I know there are features for having multiple IQ servers or Repository manager servers and load balancing or having automatic failover and things, but I haven't done those things yet.

Technical support has been great. I've never had any problems. When I do have an issue, sometimes I'll email Derek or I talk to him about it during our weekly meetings. He'll send off an email or a chat right away and get an answer back quickly about a resolution or resolution timeline.

We weren't doing automated vulnerability scans or license scanning. We were pulling straight from the public repositories so everybody had local caches of varying packages, which was different from the repositories of packages on our build servers. It was like the Wild West, but the Nexus products have helped us consolidate our repositories.

The primary reason why our senior director of product management decided he wanted to do this was that we develop sensitive software and need to ensure we don't have vulnerabilities from third party open source packages. We needed an automated way to do scanning instead of having the developers look at a list of their packages and compare them to a list of new vulnerabilities themselves. That would've been a nightmare. That central repository management was a secondary reason, but it was also important.

As important as vulnerability scanning, the licensing was essential to us too because around the time we were evaluating the Nexus product, there was a large company that was getting sued for violating open source GPL-2 license requirements. We wanted to avoid problems like that. Those are the two primary reasons.

The initial setup was easy. We're hosting on-prem and I put Nexus IQ on a VM I created according to Sonatype's recommended specs. It was really easy to install and it's really easy to update. The only thing that took a little longer to do was settings up HTTPS. It was my own fault because I had typos in configuration files that I'd overlooked. Following their instructions makes installation and upgrading really straightforward.

I did the IQ server and the repository manager server at the same time, and it took around less than a day for both of them.

When I first installed the two servers, I followed their recommended system requirements guidelines. In hindsight, because we are so small and we don't yet have that many applications, I probably could have started with IQ and Repository manager as containers. That would be okay for smaller companies that might be restricted on what resources they have available for hosting the servers. They could probably do containers in the beginning and then expand if they needed to later.

The deployment was given to me as a project. I didn't have an implementation strategy when I started building the servers, but Derek and I created implementation strategies as we went, after I installed the servers.

Initially after installing IQ and I putting some Python applications into, we had all of our policies set to warn and not fail builds automatically because we hadn't decided our governance process. That was part of the implementation strategy that we had to figure out. We had to decide a time to roll out our test applications and test groups. Derek was really instrumental in helping me see it in stages. We would test with the Python applications and then move on to other types of repositories and other types of applications for a broader adoption strategy.

Since the developers weren't doing really thorough vulnerability assessments in the past, I can only estimate how many hours it's saved and allowed them to continue developing the applications.

For example, if one of our pipeline applications has 15 dependencies and a developer had to look for vulnerabilities in that list of 15 dependencies, it could take a half-hour every day for one application. If they're developing six applications at once, then it could be a couple of hours a day per developer. It would quickly get out of hand.

I don't know anything about the pricing. I know that our license is the most encompassing one you can get. It includes the IQ server (Lifecyle, Firewall) and the Repository Manager Pro. Firewall is really useful for us to keep an eye on our proxy repositories for vulnerabilities. That's another layer of helping us make sure that we don't have vulnerable products. The expense is justifiable because of the potential to save a company a lot of money in lawsuits and risks from having vulnerable packages in their applications.

I don't have any reason to rate it less than 10 out of ten. It's been really solid, really helpful, and it will pay off hugely as we continue to expand.

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.

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.

The Lifecycle product is for protection, and licensing vulnerabilities issues, in our build lifecycle.

Without it we didn't have any way to detect vulnerabilities except through reactive measures. It's allowed us to be proactive in our approach to vulnerability detection.

Sonatype has also brought open-source intelligence and policy enforcement across our SDLC. It enforces the SDLC contributors to only use the proper and allowed libraries at the proper and allowed time in the lifecycle of development. The solution blocks undesirable open-source components from entering our development lifecycle. That's its whole point and it does it very well.

We use the solution to automate open-source governance and minimize risk. With our leaders across our different organizations, we set policies that govern what types of libraries can be used and what types of licenses can be used. We set those as settings in the tool and the tool manages that throughout the lifecycle, automatically.

It's making things more secure, and it's making them higher in quality, and it's helping us to find things earlier. In those situations where we do find an issue, or there is an industry issue later, we have the ability to know its impact rapidly and remediate more rapidly.

Its core features are the most valuable:

• protection
• scanning
• detection
• notification of vulnerabilities.

It's important for us as an enterprise to continually and dynamically protect our software development from threats and vulnerabilities, and to do that as early in the cycle as possible.

Also, the onboarding process is pretty smooth and easy. We didn't feel like it was a huge problem at all. We were able to get in there and have it start scanning pretty rapidly.

The data quality is really good. They've got some of the best in the industry as far as that is concerned. As a result, it helps us to resolve problems faster. The visibility of the data, as well as their features that allow us to query and search - and even use it in the development IDE - allow us to remediate and find things faster.

The solution also integrated well with our existing DevOps tool. That was of critical importance to us. We built it directly into our continuous integration cycles and that's allowed us to catch things at build time, as well as stop vulnerabilities from moving downstream.

Overall, it's pretty good. The drill-through and search capabilities are pretty good, they're not horrible. 

As far as the relationship of, and ease of finding the relationships between, libraries and applications across the whole enterprise goes, it still does that. They could make that a little smoother, although right now it's still pretty good. It's taking an eight out of ten and asking it to be a ten.

We've been using Nexus Lifecycle for over a year.
We use the Nexus repository for a long time.

It's very stable. We have not had any issues with it.

They're really good with scalability. We have an implementation that spans production use plus a disaster recovery area. The synchronization between those two and the high-availability are awesome.

We're at 100 or 150 licenses, maybe more. Developers are the main role as well as DevOps. The plan is to use it across every single application where we do development. We have a lot of applications, on the order of 500.

We have plans to expand usage, as far as the user base and the number of teams utilizing it go. 

Tech support is really available and very helpful.

We did not have a solution with this type of capabilities. We had some type of Nexus product but we layered this on top. We didn't have that capability.

The initial setup was straightforward. There weren't a lot of manual steps involved. There wasn't a ton of configuration. It has very smart defaults. There's not a high level of subject matter expertise required in the setup of the software. 

As for the decisions that you need to make about your policies, there are smart people out there to give you a lot of industry standards. But there is still a lot of work you need to do to make decisions for your enterprise. It can't do that no matter what it is. What you are going to do with those settings and the findings from those settings, that's the hard part. You have to make decisions about what to do with the data that it provides for you. That's not the setup, per se. That's just getting it to be very meaningful in your enterprise.

Our deployment was an interrupt-driven process because we had other work to do also. It took a few days.

The strategy for deployment was to involve legal, development, info security, and DevOps together - the leadership - to understand the tool's capabilities; to understand the defaults and also to come up with a strategy to manage the outcomes, the findings. That group of leadership had to set those settings and automatically be part of SDLC. Along with that, we had to implement a process that ensured that the findings - the breaks and the vulnerabilities that are found - would be visible. Notifications had to be made so that someone can triage and deal with them.

Deployment and maintenance require half a person. It's a side role because there's nothing to do most of the time. It's something you do occasionally, so we don't have a role dedicated to it.

We deployed it ourselves. We worked with Sonatype a little bit but we didn't need much from them. They were available when we needed them, but it was pretty straightforward.

The solution has improved the time it takes us to release secure apps to market. I can't approximate how much, there are too many factors there to consider.

If you find a problem reactively without the tool, there's the remediation cost, versus the savings of finding it in the first place. It would be really hard for me to go back right now and say how many things we found and how often because it's happening very dynamically. Those findings are not anything I can measure right now.

Then there are the things that we found that we might not have remediated. Maybe they were just okay, they weren't high-ranking and they weren't low-ranking errors. Now, we can decide that because we found them really early that we're not going to take that risk. Whereas before, we might've taken the risk - or not even have seen the risk. So it's hard to measure that. 

It's not literally speeding up our release to market. It's helping us avoid reactive costs and maintenance to the cycles after the fact. If an industry vulnerability is found, we get that notification really early.

We have seen a return on our investment. In some cases, where we've needed to find out the footprint of a certain library across our enterprise, we've been able to do that research in seconds or minutes, rather than long, drawn-out processes with people and teams involved to hunt it down through source code and the like.

As far as spinning up councils and people saying, "What's our vulnerability footprint look like?" we've been able to answer those questions much quicker and remediate quicker with other tools. Those things alone will probably pay for it. The safety stuff pays for it on its own too.

We've more recently also been able to leverage it as a solid containers repository solution.

Pricing is decent. It's not horrible. It's middle-of-the-road, as far as our ranking goes. They're a little bit more but that's also because they provide more. They put more manpower and time into their research - the details on their findings and the way they bring those to the surface. They offer some more features that others don't have, so I understand why it's a little bit more.

They were pretty good with us on pricing, working through it.

We looked at Artifactory as well. We went with Sonatype because it is more comprehensive, it's a market leader, has a great feature set, and support is really good. It's a good team and company. They provide much more granular details, as well as assistance in the remediation and understanding of vulnerabilities, than their competition.

In the early stages of planning and design for rolling this out, ensure that you get all of your stakeholders involved; those who will have an input on the policy settings. Also, ensure you have a process and people involved to deal with the findings. Have that baked into your standard enterprise processes. Don't just turn it on and not know what to do with it.

We have many use cases. Our main use case is focused on Nexus Repository and a little bit on Nexus IQ, including Lifecycle. The basic use case is storing Maven, Java, JavaScript, and other kinds of artifacts. For some years now we have implemented more complex solutions to manage releases and staging. Since Nexus Repository introduced that feature for free and natively, we moved to the feature provided for managing release staging.

It has only improved things very little because, for now, we use the reports from IQ to improve the libraries, but it doesn't yet have enough coverage.

It has helped to enforce open-source intelligence and policies across our software development lifecycle, mainly by automating controls that we had put in place before. It has helped to enforce things. It has blocked some open-source components or, more accurately, raised warnings about them. It's not a blocker in our system because, for now, it's only implemented as an informative system.

The solution has also improved the time it takes to release secure apps to market. We have been able to replace homemade scripts, which took a few hours to create, by very much simpler workflows provided natively by Nexus, which are working in a few minutes, or tens of minutes. It has saved us about 40 percent, in terms of time. But more than the duration, it's helpful that we don't have to maintain or make scripts. That's the most important thing.

It has improved developer productivity and accuracy. That happened a long time ago because we have been using it for so long, but as soon as we deployed the Nexus solution in the company, people didn't need to locally build a lot of stuff. So we were much more easily able to work together, to collaborate, and consume other teams' products. That was a long time ago, but it was definitely an important step.

The REST API is the most useful for us because it allows us to drive it remotely and, ideally, to automate it.

We have worked a lot on the configuration of its capabilities. This is something very new in Nexus and not fully supported. But that's one of the aspects we are the most interested in.

And we like the ability to analyze the libraries. There are a lot of filters to output the available libraries for our development people and our continuous integration.

The solution integrates well with our existing DevOps tools. It's mainly a Maven plugin, and the REST API provides the compliance where we have everything in a giant tool.

We do not use it for more because it is still too immature, not quite "finished." It is missing important features for making it a daily tool. It's not complete, from my point of view. All the Lifecycle tools are not yet finished and usable in production. We are using it in production, but it's not fulfilling all our needs. It's not yet finalized.

It's the right kind of tool and going in the right direction, but it really needs to be more code-driven and oriented to be scaled at the developer level. Nowadays, developers need to be autonomous, so we need to be able to supply them tooling and then everything should be orchestrated around the principle of GitHubs. That is really important in IQ because developers will want to make changes and they need things very quickly. Everything should be driven by that but that is not yet the case. The features are interesting but the way those features are configured and tuned is not quite there yet.

There is room for improvement in the way it is managed, having code-driven configuration, and automation. It needs not to be an old-style tool. Today, a computer tool must be usable in many ways: as a client for developers, as a webpage and reporting tool for managers, and as an automated blocker for continuous integration. It must have a REST API and it must have many features that make it usable in many ways. Currently, that's not the case. 

One thing I can say that is very positive is that it is much better than the other tools. But regarding usage, it's not perfect. It's missing everything around the tuning and usage.

We have been using Nexus Repository, version 2, for about 10 years or so. We switched to the Nexus 3 a little bit more than one year ago, along with Nexus Lifecycle.

Nexus 3 is not yet stable enough. IQ is perfectly stable. We have not had any stability issues with it.

It is currently not scalable. While we haven't encountered a scalability issue regarding Nexus IQ directly, but for maintenance and configuring there is a scalability issue because developers need to make modifications and reports. And those modifications must follow our workflow model, things like a code review and evaluation by a manager. Currently, this is not possible. They cannot make a request for changes in the software. There is no solution to contribute changes and that is a scalability issue. That is with respect to Nexus Lifecycle.

With Nexus Repository, we had a lot of scalability issues with version 2. With the new version 3, we tried to set up a certain type of architecture but it is not available. So scalability is an issue regarding the load, not the amount of data. We have been using Nexus software for 10 years now with very big storage and that is not an issue. But when the number of users increases, that's an issue. We are an open-source company, so we have many consumers of our artifacts, and that means there can be a heavy load on the projects.

Twelve years ago we tried other solutions, like Artifactory. But we quickly moved to Nexus. We may change the solution in the next month or year. It's a possibility. It depends on the pricing and whether the solution provides HA.

The main purpose of using the IQ solution was to have an efficient solution to spot and block security risks. We tested and compared a lot of solutions and found that IQ was the best and the most evolved. But a lot of it is not completed, it's still a prototype, from my point of view. That means it cannot yet be used exactly the way it is marketed. There are some features that are missing. But compared to other products on the market, it appeared to be the most accurate one.

My team was responsible for setting up the whole system. It was complex in the end because the way we wanted to set it up was not yet defined. It was not designed to be used the way we want to use it.

For IQ, the deployment only took a few days, but it's not usable yet. We set it but we are not really using it as we wanted to. For Nexus Repository, it took many months and many issues are not resolved yet. The fact is that IQ is not very useful without the repository.

Internally, we had a deployment plan, but a lot of those requirements were not met by Sonatype and we have had to work with support to make it work. But there are still remaining issues.

Sonatype assisted us with the initial setup and their help was average. It was pretty good most of the time, but sometimes it was not because we were outside of their defined environment. I feel that they are a little bit behind in this field, that they are missing modern requirements. So their support was pretty good, but not enough.

We evaluated Artifactory by JFrog. It also seemed very good, very similar. The other solutions we tried were not as good. Nexus and Artifactory were the finalists.

At the time, the UI was a difference between them, but that is not true anymore. The two are very similar now. The integration with development tools was very important; the ability to implement GitHubs, and so on. The fact of being open-source is very important to us; being able to contribute to and look at the code for reliability and quality.

My advice would be to look at your needs and the features the solution provides. In the last version they released, we were a little bit disappointed by the difference between the marketing and the reality. The product was not yet finished compared to how it was described. Aside from this bad aspect, it's mainly about good practices and looking at common, standard practices. Start with the basics and common stuff and try to evolve it eventually and change some things. Don't try doing something too much complex at the beginning.

The tool's default policies and the policy engine seem pretty good. We have been using it for so long that we are using our own policies. Regarding Lifecycle, we have not gone far enough with it to have a real opinion on it, although it looks consistent.

In terms of its integrations into developer tooling like IDEs, Git repos, and automated pull requests, we have not used it enough. It is a little bit too soon for us. It's a goal, but we want it to be done in a transparent way through the automation. It's not used yet because all of the developers are free to choose the tools they use, the IDEs, and only a few people are looking at this kind of stuff.

Internally, we have about 50 developers for Nexus Repository. We have five to 10 specialists for the Nexus IQ. We don't know many customers there are for Nexus Repository in our public sphere.

It is used across the whole company. It's a central tool and most people in the company cannot work without it. Everybody uses it either directly or indirectly or by proxy. Some people use it without knowing it, but all the technical people in the company are using it, so around 150 depend on it.

For deployment and maintenance of the solution there have been three people on my team doing this, but that was not the only responsibility of the team and they were not enough. We spent a lot of time setting up automation, including maintenance and deployment, and that made it scalable for three people in maintenance. We had to work on this. It was not provided natively, but now three people are enough.

I would rate IQ at six out of ten. That's very good compared to other products on the market.

We have two use cases. We're predominantly a products company and we scan our products, in a controlled way, to make sure they're not using open-source software. We want to make sure that we're licensed correctly for our products and the way they are deployed. There are also security reasons for making sure that our products aren't introducing vulnerabilities and, if they are, that we can address them. 

And part of our business is that we build bespoke software. Some of our customers want to make sure that the open-source software is being used correctly in the software we build for them. And, again, we want to protect that software against security vulnerabilities that might be introduced by open-source software.

We also use the solution to help with open-source governance and minimize risk. When we are acquiring a new company, for example, we will automatically, as part of the due diligence on that purchase, scan their products to make sure they don't have vulnerabilities that we are not prepared to accept. So it helps us to make sure, before we make any purchase, that the target acquisition is of suitable quality, in terms of its open-source use.

The solution has improved the way our company functions in terms of the way that developers think about the components that are being built into their products, making sure they're not being duplicated, for example. The developers now understand that there's a cost associated with including open-source. It may not have a licensing fee, but there is a cost associated with it. That sort of education piece has had a big influence.

It has also brought open-source intelligence and policy enforcement across our SDLC. As the teams are setting up their development environments, we have now gotten them to build Sonatype into their development pipeline. They scan their codebase so they actually catch things at the point that they introduce new, open-source software into the products, to make sure they're not actually introducing vulnerabilities or licensing-policy breaches.

Sonatype has also reduced our risk in releasing secure apps to market. Previously, teams would just release without knowing what risks it was exposed to. Now, we can actually do a better risk assessment.

For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities.

In addition, the default policies, in general, are quite good. We have adjusted slightly but we're fairly happy with the way that's set up. They provide us with the flexibility we're looking for.

The data quality is pretty good. We don't have masses of false positives. There have been some areas around .NET which haven't been quite as good as some of the other areas, but we know work is being done on that. Overall, the data quality does help us solve problems faster.

We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment.

Also, the ability of the solution to recognize more of the .NET components would be helpful for us.

I've been using Sonatype for about six years.

It's a stable product, especially compared to some of its competitors.

The technical support is generally good. A couple of years ago there were some things that had been logged and that had to be chased a few times. They didn't go as quickly as we'd have liked. But recently, things have been better and they have been more timely in their responses.

Our company tried with Black Duck, but that was it.

The initial setup was straightforward. One of my team members was able to execute it quite quickly without too much trouble or additional help.

It's deployed internally at the moment but, moving forward, we want to move it to a cloud-based deployment.

We have seen return on our investment, but it's a difficult one to quantify because, unless you have a problem, it's like any sort of security or testing; it's difficult to quantify unless you have an issue. In terms of protecting our IP it certainly has provided ROI and, in security issues as well, it has helped us to identify them, reducing our risk. There has been a big risk reduction for us.

We pay on a yearly basis.

We do a supplier selection every couple of years. One solution that we've evaluated is Black Duck, for example, but it didn't seem to be as stable as the Sonatype solution, when we last tested it.

WhiteSource is another one we tested. It's a cloud-hosted solution so I can't comment on its stability.

Comparing these solutions with Sonatype, the information that comes with Sonatype and its recognition are good. The fact that WhiteSource is cloud-hosted is nice and it's an advantage you don't immediately get with Sonatype. But with WhiteSource we got more false positives than we did with other tools. And Black Duck, when we've last reviewed it, wasn't as comprehensive as what we are looking for.

Sonatype met our needs, what we were looking for, particularly around protection of IP. The knowledge of the Sonatype team, and our good working relationship with them, have helped us to continue to use the product. The fact that they take some of our feedback and incorporate it into the product has also helped.

I would definitely recommend understanding what you're trying to achieve. For us it's quite clear that we want, for the moment, to protect our IP and to identify security vulnerabilities. If the understanding is that you want to protect against open-source from coming into your products in the first place, or you're doing greenfield development, look at the right product stack from Sonatype to make sure that you're choosing the right set of products. We've got a mature product base that we're working with. If you're starting from scratch, you would want to assess what you're trying to get out of your policies and processes around this, and make sure that the products match.

We have about 150 users of Sonatype in our company, and their roles range from managers who review the open-source solutions to make sure they're being licensed properly in the product, to developers who are actually cutting the code. It's also service and project managers looking at their exposure, or maybe the audit team that wants to make sure that there's compliance within the different teams. For deployment of the solution and maintenance we have one person, a junior software engineer.

Sonatype is being used for regular scans on our priority projects, numbering about 20. We plan to eventually get that rolled out much more of our estate, to 50 or 60 business units.

I would rate it at seven out of 10. Some of the scanning around the .NET open-source licensing, the recognition; and the integration with some of our development tools, like Azure DevOps, are where, perhaps, it's lacking.

We have it running on the majority of our builds for all of our applications and we use Jenkins for our build system. Eventually, the goal is to incorporate this into Jenkins so that if we don't get a good enough result on both Nexus IQ and SonarQube, we'll actually fail the Jenkins build. That way we force ourselves to maintain good metrics on both of them. So Nexus IQ is making sure that we're using dependencies that don't have known vulnerabilities. And SonarQube is making sure that our code maintains a certain level of quality.

Unfortunately, we haven't been able to take full advantage of Nexus. It's set up and it's working, but we haven't rolled it fully into our development process. Our builds use it, but we're not using the information from it a whole lot. The solutions are running, but we're not enforcing the results from them and, therefore, our developers aren't driven to make absolutely sure that they are going well. Hopefully, we'll get there soon.

So far, the information that we're getting out of both the Nexus Lifecycle and SonarQube tools is really great.

And the integration of Lifecycle is really good with Jenkins and GitHub; those work very well. We've been able to get it to work seamlessly with them so that it runs on every build that we have. That part is easy to use and we're happy with that.

We're able to use Jenkins Pipeline and the integrations that are built into Gradle to incorporate that into our build process where we can have control over exactly when Nexus IQ and SonarQube analyses are run — what kinds of builds — and have them run automatically.

We've had it in place for about six months now.

Overall, the stability is pretty good. I haven't figured this out yet, but occasionally we do see failures in the Jenkins build. I haven't figured out why yet. I don't know if it's an issue with our Jenkins server or if it's with Sonatype. But otherwise, it seems pretty stable.

We haven't looked at its scalability at this point. We do have plans to use it more in the future, enforcing the results of the analysis to fail builds and force the developers to fix the issues in there before moving on.

We've used Sonatype's technical support a few times. We had some issues, and I think we might still have some issues, where the Sonatype Nexus Repository has integrations with IQ and SonarQube. We're getting some errors on the UI, so we've had Sonatype look into that a little bit. 

But they were responsive and had good suggestions, things to try. Overall, they're good.

We didn't have a previous solution.

The initial setup was pretty straightforward. The documentation is done well. It was easy to follow and I was able to set it up and get it working without a lot of effort.

I probably spent a day getting it installed, understanding it, and figuring out how to integrate it with our current solution.

In addition to myself, about 10 developers will eventually be looking at it to give them feedback on code quality and dependency management.

In terms of deployment and maintenance, it's me and a little bit of our CTO. He did the installation initially on our server and then I set up the integration with the rest of our process.

So far, it seems to be a good solution and there is a lot of very valuable information that the analysis provides.