Sonatype Lifecycle Reviews

We use it in the pipeline. So, software development is done in a pipeline in automated steps. One of those steps is Quality Assurance for which we use, amongst others, Sonatype, and this is done automatically. Based upon the outcome of this scan, the software product can proceed to the next step, or its blocks need to be rebuilt with updates.

We are using Nexus IQ Server 114, and we're about to upgrade to 122.

It improves the overall hygiene of the source code. We have a lot of scans going on every day. They are in the thousands. If high critical vulnerabilities are detected, of course, that is good. It is already proving its value to us down the line because these vulnerabilities do not reach production.

Data quality helps us solve problems faster. We get the info on what's vulnerable, and most of the time, we get advice for an upgraded version that can be implemented right away. That's very valuable.

It brought open-source intelligence and policy enforcement across our SDLC. It is the tool that we use for open-source scanning and third-party dependency scanning. So, it brings a lot of value to us from that perspective. 50% of the code that we use is open-source. So, it is important to scan it for all kinds of vulnerabilities. It is very powerful, and it brings a lot of security to us. It can block undesirable open-source components from entering our development life-cycle.

It secures the software supply chain because it scans the packages that we get from our vendors, but we don't use it to secure our pipelines or steps in the build process. The build process itself is not secured by Nexus IQ.

It improves the overall health and security of the software supply chain. Anything that is detected can be blocked.

The quality or the profiles that you can set are most valuable. The remediation of issues that you can do and how the information is offered is also valuable.

Its integration with our tool landscape is very valuable. It is the interaction with account management and technical consultants.

The default policies and the policy engine are very good. Most of what we have is the default. It is also possible to create your own policies and custom rules, but we only do that for a handful of exceptions. We are very pleased with the default policies and settings. It provides us the flexibility we need because we can use it in our own customized settings. It is flexible enough for us to work with.

The user interface needs to be improved. It is slow for us. We use Nexus IQ mostly via APIs. We don't use the interface that much, but when we use it, certain areas are just unresponsive or very slow to load. So, performance-wise, the UI is not fast enough for us, but we don't use it that much anyway.

I have been using this solution for about five years. It was being used prior to me engaging with it. So, it was already there.

It is very stable. There are no complaints. It is good in terms of availability.

We don't need to scale it. At this moment, it is right-sized for us. So, I don't see any scalability going on right now. We do self-hosting on our own internal platform. The resources that are available are not scalable, so to say. They are right-sized.

We have between 750 and 1,250 users. The developers are the biggest part. We also have our operations support team that deals with upgrades, patch management, installation, and the Infra stuff. There are about 10 people. They don't only work on Nexus IQ, of course, but that's part of their job. There is also the security team, which is my team. It has about 10 people. We use Nexus IQ for all kinds of security review activities. We also have five metrics people who use these tools to gather metrics. They also use Nexus IQ.

I have contacted them, and I would rate them a seven out of 10. Like every big company that you contact for support, you can get people who are well aware of your situation or less aware. Depending on who you get at the support desk, you might get immediate feedback or the right answer, or you might be going back and forth to get the right information. You don't have a single contact person for all your support, so the quality can change based on who you talk to.

Our company didn't use any other solution.

We have a team of about 10 people for upgrading the tool, patching the tool, migrating XIQ from our own platform to a public cloud platform, and creating system rules and policies.

For Nexus IQ, I have not seen any research that has been done for ROI. I am aware of other tools but not Nexus IQ.

There are additional costs in commercial offerings for add-ons such as Nexus Container or IDE Advanced Toolkit. They come with additional fees or licenses. 

We always explore other tools. For every tool that we have, we constantly look at what's available. Every couple of years, we do an evaluation to see if there are replacements that are better suited to our needs. Our requirements might change over time. Our entire circumstance might also change from being on-premise to a fully-cloud company, where we might need to fulfill different types of needs. So, of course, we explore what are the best options for us. We stayed with Nexus IQ because they're a pleasant company to work with, and they offer a good product. 

I would advise making sure that your developers are aware of why you are going to scan the source codes for vulnerabilities. An awareness training or awareness program on open-source vulnerabilities goes hand in hand with implementing such a tool because the tool is there to enforce policies, etc. If your community developer knows how to build secure software and how to look at open-source, it will drastically reduce the findings in the tool and create a healthy software landscape. So, awareness of secure coding principles should accompany the installation of such a tool.

Although we are very familiar with the concepts and the topics, we don't make use of integration with IDEs. We do not support automated pull requests yet. It would take time for us to implement, and there are other things that we are busy with. It would depend on how things proceed. We also don't use Nexus Container. 

It has not improved the time to release secure apps to market. It has also not increased developer productivity. In the short term, it decreases developer productivity because they have to fix stuff that otherwise would go undetected. So, productivity is hampered if you are confronted with vulnerabilities that you need to fix. Therefore, being more secure in the short term doesn't make you more productive. If you are aware of why you need to look at certain things, it can bring productivity in the long term.

The biggest lesson that we have learned from using Nexus IQ is that with open-source, so many things can go wrong. Most of the vulnerabilities that you have in your software are due to the bad usage of open-source components.

I would rate this solution an eight out of 10.

We use Nexus as a local repository of both JavaScript and Java components, and we're starting to look at Python. We also connected up to the Nexus Firewall, so that new components that are proxied are looked at to see if they have malicious components or if they are components without vulnerabilities. We're able to establish policies about whether we want to allow those or quarantine them. 

Our main use case for IQ Server is to scan software builds for components with existing vulnerabilities and malicious components. We're working to drive down our technical debt due to components with known issues, and it's been helpful. We're still expanding the program to different software languages. We started with Java and then extended the JavaScript. We want to extend to Python, but we're not quite there yet. We don't have too many Python users, so that's less of a priority.

It's been pretty good. I'm the one who has to un-quarantine things, but the false-positive rate is not too bad, or else I'd be doing that all day. From that point of view it's been good.

The solution enables us to manage and secure the component part of our software supply chain. That is done between the policies, their data, and configuring. You have to make sure everybody's actually pointing to the repo. We started talking about blocking public repos from within the networks, so that would force people to go through the solution, but we haven't quite gotten there yet. However, we have definitely have a lot of people going through the repo. We can see how many components are cached and how many are quarantined. We have definitely had 1,000 or more components quarantined during our use of the product. That's all technical debt we would have accrued if we hadn't been using it.

We really like the Nexus Firewall. There are increasing threats from npm, rogue components, and we've been able to leverage protection there. We also really like being able to know which of our apps has known vulnerabilities. 

Specifically features that have been good include

• the email notifications
• the API, which has been good to work with for reporting, because we have some downstream reporting requirements
• that it's been really user-friendly to work with.

Generally speaking, the configuration of all the tools is pretty good; the admin screens are good.

We have been able to use the API for some Excel-based reports to compare how many of our application deployments were covered by scans, and to do charts on that. That has been good and worked really well.

The default policies are also good. We deviated a little bit from those, but we have mostly used them, and they have been good. They provide us with the flexibility that we need and probably more flexibility than we need.

It has brought open source intelligence and policy enforcement across our SDLC. We have policies and SLAs that say, for example, critical findings have to be fixed within 90 days, and "high" findings have to be fixed within 120 days. That's tracked and reported on. We use the API to do some downstream reporting into some executive dashboards and when executives see red and orange they don't like it, and things get done. We've also made it part of our standards to say no components with existing vulnerabilities. Enforcing those standards is integrated into our software development life cycle.

Sonatype also blocks undesirable open source components. That is also done through policies that you can set, and configuration of the repo.

The integration is one sore spot, because when we first bought the tool they said JavaScript wasn't really part of the IDE integration, but it was on the roadmap. I followed up on that, and they said, "Oh, you can submit an idea on our idea site to have that added." The sales team said it was already in the pipeline, but it was actually not in the pipeline. 

Overall it's good, but it would be good for our JavaScript front-end developers to have that IDE integration for their libraries. Right now, they don't, and I'm told by my Sonatype support rep that I need to submit an idea, from which they will submit a feature request. I was told it was already in the pipeline, so that was one strike against sales. Everything else has been pretty good.

Also, when Nexus Firewall blocks a component, it doesn't really give us a message that tells us where to go; at least it doesn't in our setup. I have to tell all the users, "Here's the URL where you can go to look up why Firewall is blocking your stuff. And that is odd because when it finishes a scan, the scan results give you the URL. But when you get blocked by Firewall, it doesn't give you the URL where you can go look that up. You can definitely work around that, but it's a bit strange. It's almost like something they forgot to include.

I've been using Sonatype Nexus Lifecycle since October of 2019.

We've only had the server go down one time in about two years, so that's good.

The scalability is fine, as far as I can tell. We only have so many developers, and haven't really grown our development teams at all in the past few years. We have about 200 users of Sonatype who are either developers or application security or myself as senior architect. We haven't had problems with capacity, but we haven't had to scale it.

It does seem to scale okay for adding new software artifacts, because we continue to add more stuff to it.

Overall, tech support is good.

When submitting a support ticket, I've seen other vendors basically regurgitate what the tool is saying, instead of actually looking at what I'm trying to say. Sonatype has done a good job of at least saying, "Yeah, we looked at this pull request on this open source component, and this is where we're seeing something. I have even had to coordinate a discussion between an open source maintainer, Spring Pivotal, and Sonatype, to let them hash out who's right.

We used OWASP Dependency-Check. It's a good resource for security standards and, occasionally, free tools, and it was a good command-line checker. It matched heuristically, so it would find a lot of false positives. It got us started and gave us an idea of how much debt we had, so it was useful. It just required a lot of tuning to weed out false positives.

They have good documentation about how to configure things and get it set up, and it's easy to find what you're looking for, generally speaking. I found the setup to be pretty straightforward. I had to spearhead that effort, solo, and get it socialized out to all the teams. Most people seemed to be able to configure it pretty well without a lot of hand-holding. The rollout went really well.

We run it on our own Windows box. It's a little tricky to get it to run as a Windows service, but they have instructions for it and we finally figured out how to get that working. I think they intend for it to be run on Linux, but it's Java, so it runs on either. It's running fine on Windows.

I just used the online documentation and did it all myself. It took about three months to roll it out.

How do you prove that you've not gotten hacked because of the tool? We've definitely gotten better visibility into how we're using older components and when we need to migrate away from them. We're much better positioned now to keep things patched and if there's another Struts 2, armageddon-type vulnerability in a library we use, we'll be much quicker to get on it.

It's like any security tool. How do you know that the door lock paid for itself? You really don't know who would have knocked your door down. But once our developers get more used to the tool over time and we get the technical debt driven down, they will be more productive in terms of making sure the libraries are up to date.

In the meantime, when they're onboarding and trying to figure it out, it's going to slow them down a little bit, to get oriented. If they're dealing with a legacy of technical debt and there are a lot of things that have to be fixed, because nobody has updated an internet app in 10 years, it's not going to make them more productive. But if you're willing to pay down that technical debt, it's totally worth it, but it's hard to quantify. But if you consider keeping your apps up to date as productivity then it helps with productivity.

It's expensive, but you get what you pay for. There were no problems with the base license and how they do it. It was transparent. You don't have to worry. You can scan to your heart's delight. They're pretty much based on co-contributing developers, so if you have auditors or AppSec, that doesn't count against your total.

We're not using their Advanced Development Pack because it costs more money. That is a sore spot. We're not using the Infrastructure as Code Pack or the Advanced Legal Pack because there hasn't really been a lot of appetite to use the DLC mode. That's a criticism I have of Sonatype. I understand they want to get paid, everybody does, but they're adding new features to the product as add-on purchases, as opposed to just improving the product. You pay for a subscription to the product. If we had bought a permanent license and we weren't paying a subscription, I could see it working that way. But I don't like the fact that we pay a subscription but we're not getting these features because they want to charge more for these packs.

I have told them that. I have said, "I don't like this model. We're paying you guys a lot of money already. Why are we having to be quoted to pay even more?" Maybe our subscription only pays for the data and the support, and if so, that's fine, but they weren't very transparent. They're saying, "Hey, we're going to be developing new features and capabilities, but they're going to cost more." As far as vendors go they're a good vendor, but this is one thing that they started doing that I don't like.

I don't like the whole "pack" mentality they've got going now. "We're going to come up with cool new features, dangle them in front of you, and then say, 'Hey, we know you're already paying a bunch of money per year for a sub, but you're going to have to pay more if you want this.'" It rubs me the wrong way.

They only started coming out with these packs in the past year or so. I'll say, "I wish the product did this," and they'll say, "Oh, we're working on a pack to do that, but it'll cost money." I had to move mountains to get the money to pay for the base product. It's not cheap. I don't know if they think we've got a money printing machine hiding in the back, but we don't.

The solution's data quality is good. It's a lot better than what we had before, which was OWASP Dependency-Check. That was okay, but just okay. Sonatype seems to have higher fidelity, but there have been times when I've had to reach out and say, "Hey, is this a false positive? It seems a little off." Sonatype's data research team seems pretty good. It's good data, for sure, but they're also willing to accept feedback on it, and that's good too.

If we can't afford Sonatype in 2025, we might go back to OWASP.

We briefly used SourceClear. We didn't use it very long. It wasn't very good. It seemed that the quality of data wasn't as good. There were no IDE integrations and more false positives. It was totally cloud-based. I'm not sure if the guys who set it up configured it correctly, and that might not be their fault. But we had a lot of issues with it breaking builds and just not working correctly. The reliability and uptime wasn't good. But the biggest problem was probably that they charged per scan, as opposed to per app or per developer. You couldn't really scale to let your developers scan locally without worrying about blowing your budget. The whole licensing model for SourceClear was bad.

Make sure you know what packs you're getting with your buy. They also tried to sell some sort of training about how to customize policies, training that they didn't include in the original estimate. So make sure whether your quote includes packs or not and whether you need training for an administrator or whether they'll be able to self-serve from the documentation. It was like we were in the checkout line and then they asked, "Would you also like this training?" instead of including it in the original estimate. It's annoying. If that is part of the package, let us know how much it costs up front, in our estimate, and we'll decide. Don't try to bolt it on midway through the purchase process, which is what they did.

Depending on how old your code set is, brace yourself. You're going to have to figure out a way to report on the stuff. You're going to have to figure out a way to socialize the value, and you're going to have to constantly answer questions about, "How should I fix this?" My advice would be to make sure you have a champion who not only knows how to administer the tool, but who knows enough about software development to help provide guidance about how to remediate issues. I feel that if I didn't have both of those skill sets, this would have been a complete flop, just another tool rotting on the shelf.

When it comes to data quality, occasionally it helps us solve problems faster, but sometimes it creates confusion because their data team tries to monitor above and beyond the National Vulnerability Database. Occasionally you get conflicting messages between that and what Sonatype is saying. They're trying to go above and beyond and say things like, "Hey, the bulletin says it's version four or five, but we see it's in version three." But it can get a little confusing when the maintainers don't agree with Sonatype. It's not Sonatype's fault. They're trying to cover for the maintainers not being really thorough with their notifications. 

But when they come into conflict, it is confusing for the end-user because you're trying to figure out, "Well, what do I really need to do here?" But overall, most of it is really straightforward. The technology can be confusing, but that's software libraries and their features. All that stuff can be confusing, period. But that's not because of how it's communicated, rather it's because it's complicated technology. For example, the vulnerability might be talking about the second-tier cache and that's something I've never even heard of, so I have to go research it. But generally, their communication is effective.

We are in the education industry, but we are a developer-based company. We heavily use lots of public libraries. We use Sonatype Nexus Lifecycle mainly for protecting us from vulnerabilities and license copyright issues. We heavily depend on its database.

It's a hybrid. We have our on-premises instance for our internal security. With Sonatype itself, we use the cloud service, but we have a few modules on-premises, such as IQ Server and the report server. We have deployed those modules on AWS. As a company, we use cloud services 100 percent.

We have started rolling out to each of our feature teams and so far we have rolled it out to about 30 percent, but we can already see the benefit. It gives our teams easy visibility into the risk inside our code. "Risk" in this case can be copyright, more along the lines of compliance, and security itself, such as vulnerabilities.

From the legal and security perspectives, we have a huge concern about what we use in our product and our platform. Before using Sonatype we had a huge business risk. Since bringing in Sonatype, we have visibility for both the legal and security teams. It enables us to maintain the quality from the third-party libraries.

We follow the CI/CD methodology and Sonatype's impact is really huge because we are able to meet our continuous integration in the DevOps pipeline. The speed of that flow is noticeable. The impact is on both development and operations, together. The integration with the CI/CD pipeline is easy.

From the integration perspective, it is easy to use, out-of-the-box. The GUI is not complex.

I mainly use two modules, the report server and IQ Server. The value I get from IQ Server is that I get information on real business risks. Is something compliant, are we using the proper license?

With IQ Server we are currently running the default policy. We started deploying six months back and our main objectives were identifying any bad licenses in our library or product, and whether we are using any critically vulnerable assets. We have stuck with the default policies and they are giving us huge visibility and, as a result, we are putting a lot of effort into remediation.

In terms of the data quality and the database they have for open source, I'm impressed. For our requirements, the data we get seems to be updated well when it comes to license-type and vulnerabilities.

The solution also blocks undesirable open source components from entering our development lifecycle. We use it for controlling third-party libraries.

Nexus Lifecycle is multiple products. One drawback I've noticed is that there are some differences in the features between the products within Lifecycle. They need to maintain the same structure, but there are some slight differences.

Other than that, the tool is very user-friendly and gives the right reports to the right teams.

We have been using Sonatype Nexus Lifecycle for about the last six months.

Until now, we haven't faced any challenges on the stability front. If there's a challenge, if something is down, we definitely get a direct alert. We are happy with the stability part. Both the software and the infrastructure are good.

There are two aspects to the solution's scalability. The infrastructure scalability is the first part, and that is good. The second part is the developer and the licensing front. When we started the program, we had 60 developers but we now have double that number. There's flexibility on both the infra and the licensing. That is good, as of now.

When it comes to cultural adoption, when we put something new in the DevOps pipeline, the positive side is that we have a dedicated professional support team and there is a dedicated person. I'm on the security side, I'm not a developer. So the challenge for me is that when I go to the developers, they have a different language. That support person is always there to support me and I'm very happy with that support and the way they handle us as a customer. I can go to the development team or the department and say that, "If we need any support, let me know." I know that dedicated support person will be there for us. That's very much appreciated. That model is actually helping me to push our development teams to get into this new integration. The support model, with a dedicated person, is very useful.

We have frequent meetings with the person who manages the team, and our dedicated support person from Sonatype. If there's a new update it's like we have permanent support. They help us to update.

I would rate their support at nine out of 10.

We were using Sonatype open source, the repository server, for a long time, as a free edition and as a PoC. That's why we picked Sonatype Nexus Lifecycle. 

Before that, we were using a different solution for a period of time. We jumped to Sonatype from our previous solution because it had a limitation on the modules. If I go for a multiple module integration, there is additional cost, whereas with Sonatype, they bundle licenses. There's no limitation. I can go for any number of integrations. That's the reason we switched to Sonatype.

The initial setup was triggered from a template in the cloud, so it was easily set up.

With this implementation, the challenge is awareness. We have 14 development teams, but when we started the program there were 10. The number of development teams continues to increase and they use different tools and techniques in the CI/CD. From my side, in security, the idea is to make them aware. This would be the same whether the product was Sonatype or something else. Making them aware has been a very big challenge for me, to onboard them and make the product effective.

So the initial, technical deployment is easy, but to make it effective, we have had to bring that awareness into focus and do repeated training.

The initial deployment took one or two days, taking into account the infrastructure requirements in AWS. But that's not the issue. We deployed the server, but if nobody's using it there's no value from it. The value comes from being able to integrate all the developers. The dedicated support person was very useful in helping me create that awareness and value from it.

We use a lot of tools in our CI/CD, so the initial month was more of a feasibility test and proof of concept which was validated with multiple scenarios. Then we started onboarding teams, one per month. We work with the Agile methodology in two-week sprints. Each team picked the integration per its own Agile sprint timeline, based on the product owner's priorities. Within the two-week sprint for a given team, we are able to do a full integration for that team. But within those two weeks, if you look at the real effort, it would be a maximum of about two days, including troubleshooting. We have covered 30 to 40 percent of our teams so far. Within the next three to four months we may be able to complete the process and cover 100 percent.

When I started with Sonatype six months back, I knew that I wanted to do 10 integrations. When I started integrating with a development team, and getting them more usability, I understood the reality was not 10, it was actually 100. When I ran with another vendor, even though I started with a small price, when I looked at the total cost of ownership or the return on investment, it was totally different. With Sonatype there is definitely a return on investment in the number of integrations and the personal support. In that sense, there has been a lot of value. 

In addition, the bundled licensing is a huge difference and provides flexibility. We are not limited by the number of integrations, like in other products. We have flexibility and scalability. For us, the return of investment or value is huge, when it comes to the licensing model.

Cost is a drawback. It's somewhat costly.

As part of the procurement process in Alef, we have to do a minimum three-product evaluation. We evaluated Sonatype, a different solution, and there were two more in the pipeline. Based on that evaluation, technical and other, Sonatype came into the picture. 

The competing solution was actually cheaper, no doubt, but when we looked at the overall picture, the total cost of ownership after one year of integration, we understood it would be less with Sonatype, even though the initial price was less with the other products.

If you're going to be scaling and growing quickly, in a way you cannot predict, the Sonatype licensing model and feature set are definitely good.

Look at the scenario of the total cost after one year, not the initial stage. When we looked into the initial stage costs, there were vendors that cost less. But when you come to the integrations and real scenarios, that bill goes up. We had to clearly evaluate, not only the initial moment, but one year or two years down the line and consider the total cost of ownership.

Also, be sure to properly utilize the engineer allocated to your site to help support the developers.

We're using Sonatype Nexus Lifecycle to scan for vulnerabilities in our continuous integration and deployment pipelines. We're also using the solution as part of our IDEs for developer support.

Due to the sheer amount of vulnerabilities and the fact that my company is still working on eliminating all vulnerabilities, it's still too early for me to say what I like most about Sonatype Nexus Lifecycle. Still, one of the best functions of the product is the guidance it gives in finding which components or applications have vulnerabilities.

For example, my team had a vulnerability or a CVE connected to Apache last week. My team couldn't find which applications had the vulnerability initially, but using Sonatype Nexus Lifecycle helped. My team deployed new versions on that same day and successfully eliminated the vulnerabilities, so right now, the best feature of Sonatype Nexus Lifecycle is finding which applications have vulnerabilities.

It could be because I need to learn more about Sonatype Nexus Lifecycle, but as a leader, if I want to analyze the vulnerability situation and how it is and the forecast, I'd like to look at the reports and understand what the results mean. It's been challenging for me to understand the reports and dashboards on Sonatype Nexus Lifecycle, so I'll need to take a course or watch some YouTube tutorials about the product. If Sonatype Nexus Lifecycle has documentation that could help me properly analyze the vulnerability situation and what the graphs mean, then that would be helpful.

I need help understanding what each graph is showing, and it seems my company is the worst, based on the chart. Still, I need clarification, so if there were some documentation, a more extensive knowledge base, or a question mark icon you could hover over that would explain what each data on the graph means, that would make Sonatype Nexus Lifecycle better.

I've been using Sonatype Nexus Lifecycle for almost a year.

Sonatype Nexus Lifecycle is a very stable tool; my team hasn't had any issues with it. My company had a significant outage two or three weeks ago, so all storage was lost. Still, in just a short while, Sonatype Nexus Lifecycle was up again, which makes Sonatype Nexus Lifecycle a very good tool.

We haven't scaled Sonatype Nexus Lifecycle yet.

We've just been using Sonatype Nexus Lifecycle, so we can't evaluate its technical support for now.

Sonatype Nexus Lifecycle was the first tool we used with dependency scanning functionality, though we used other vulnerability scanning tools such as Docker and Trivy before Sonatype Nexus Lifecycle. We also scanned for vulnerability in images with Harbor. Sonatype Nexus Lifecycle is the only tool we've used for scanning dependencies.

The initial setup for Sonatype Nexus Lifecycle was straightforward.

We deployed the Sonatype Nexus Lifecycle in-house. We learned how to install and use the product.

We've seen ROI from Sonatype Nexus Lifecycle, mainly connected to the number of attacks. For example, we've calculated the number of hours our employees put into analyzing a vulnerability and looking for that vulnerability in the different components. We saw that the main benefit of using Sonatype Nexus Lifecycle is quickly finding which components have vulnerabilities. As a result, two to three employees save on a week's work because that's how long it takes to look through all the different components with vulnerabilities.

Vulnerabilities could also cause a significant outage or complete data loss, which comes at a high price. Sonatype Nexus Lifecycle could help prevent that or help eliminate the risks. Hence, there's ROI from the tool, but we still need to evaluate the data fully.

In comparison with other tools, Sonatype Nexus Lifecycle could be more expensive. Still, at the same time, my company prioritizes security, so the pricing for Sonatype Nexus Lifecycle hasn't been an issue.

If IT security weren't at the top of the list for my company, somebody would have raised the question about cost and how Sonatype Nexus Lifecycle is in terms of ROI. So far, there's been no question about the price. The cost of Sonatype Nexus Lifecycle hasn't been a problem so far.

My company pays for the license yearly, plus technical support.

We started evaluating four different tools about this time last year, from November to December, and we chose Sonatype Nexus Lifecycle. We were deciding between Snyk and Sonatype Nexus Lifecycle. Still, Snyk lacked support for all our technologies and didn't have the same IDE support available in Sonatype Nexus Lifecycle, so we went with Sonatype Nexus Lifecycle.

We used Sonatype Nexus Lifecycle during the first quarter, from January to February, to establish the tool in our organization and set it up. We then made a training plan and, from March to April, rolled the Sonatype Nexus Lifecycle out to all the teams, but the different teams also had to build their pipelines, so there have been delays from May to the present. We've been pushing them to adjust their pipelines and still helping them.

My company is currently using the latest version of Sonatype Nexus Lifecycle.

About fifty IT department employees use Sonatype Nexus Lifecycle in my small company.

There's no plan to increase the usage of Sonatype Nexus Lifecycle. Its rollout is complete, and only the development teams use the tool within the company.

My rating for Sonatype Nexus Lifecycle is eight out of ten because it does its job, and my team hasn't had any problems with it.

I'd recommend Sonatype Nexus Lifecycle to others.

My company is a Sonatype Nexus Lifecycle customer or end-user.

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.

Most software innovation happens in an open-source environment, and developers generate only a small amount of code. The customers we encounter generally perform static code analysis immediately before they move code into production. If the security guys detect issues, they will send the code back into development. 

Lifecycle integrates everything from IDE down to production. It's a unique solution that helps customers embrace open-source development because that's where the innovation is happening. At the same time, I know the code coming into my environment is clean. A lot of our customers have adopted Azure DevOps, especially on the banking side. Some parts of the solution are in the cloud, while others are on-prem.

Lifecycle lets developers see any vulnerabilities or AGPL license issues associated with code in the early stages of development. The nice thing is that it's built into the ID so that they can see all versions of a specific code. 

They can see the associated risk and which version has the lowest risk. Developers can effortlessly migrate the entire project by dragging and dropping the version of the code with the lowest risk.

I'm not using the technology directly, and I haven't heard anything from our customer base. As far as I know, Sonatype has a unique customer engagement framework with a regular customer meet-up to go through deployment issues. They take feedback directly from the customer.

We provide consulting, and one of our partners is the Sonatype distributor in Africa. We've been working with them for about three years.

Our customers include some of the biggest banks in Africa. The number of Lifecycle users ranges from about 25 to 250, depending on the size of the environment.

Deploying Nexus Lifecycle is straightforward. It normally takes two weeks to remotely install everything and hand it over to the customer. In the beginning, we sometimes struggle to access the customer environment. The customer must issue the required certificates because many customers use cell phone certificates, and Sonatype needs a valid CA certificate. From the partner's perspective, we only need one person to set it up, but the customers might need a few techs to provision VPN access, a server for the environment, etc.

Nexus Lifecycle manager has a license for each server you deploy. You also pay a charge per user, including developers, release managers, and anybody else involved in the software development lifecycle. The price is fair for the value you get, but customers always want it cheaper.

Based on my experience and feedback from the customers, I rate Sonatype Nexus Lifecycle nine 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 are using Sonatype Nexus Lifecycle within our company for scanning our products with the Jenkins pipeline.

The most important features of the Sonatype Nexus Lifecycle are the vulnerability reports.

Sonatype Nexus Lifecycle can improve the functionality. Some functionalities are missing from the UI that could be accessed using the API but they are not available. For example, seeing more than the 100 first reports or, seeing your comments when you process a waiver for a vulnerability or a violation. 

When you submit a waiver, you enter a comment, and when you need to access this comment, in the reports, you don't see it. This is a drawback.

I have been using Sonatype Nexus Lifecycle for a short time.

I would rate the stability of Sonatype Nexus Lifecycle a seven out of ten.

Sonatype Nexus Lifecycle 

We have approximately 200 users using Sonatype Nexus Lifecycle in my company using this solution. They are mostly developers and security personnel.

I rate the technical support from Sonatype Nexus Lifecycle a six out of ten.

I have not used another similar solution previously.

We have a team in our company that does the implementation of the Sonatype Nexus Lifecycle.

We might increase our usage of the solution in the future, or we might move to another solution because of the issues we have had with it.

I would recommend to others to test the functionalities of the Sonatype Nexus Lifecycle to see if it meets their use case needs.

I rate Sonatype Nexus Lifecycle an eight out of ten.