Sonatype Lifecycle Reviews

We use this solution for libraries in our applications that need to be updated.

The solution is very easy to use. 

Improvements are needed as per customer requirements.

I have been using Sonatype Lifecycle for one year. 

The scalability is a ten out of ten. 

Overall, I would rate the solution a ten out of ten. 

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.

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 have it implemented and integrated into our CI/CD pipeline, for when we do builds. Every time we do a build, Jenkins reaches out and kicks off a scan from the IQ Server.

We use it to automate open source governance and minimize risk. All of our third-party libraries, everything, comes through our Nexus, which is what the IQ Server and Jenkins are hooked into. Everything being developed for our big application comes through that tool.

We have Nexus Firewall on, but it's only on for the highest level of vulnerabilities. We have the firewall sitting in front to make sure we don't let anything real bad into the system.

Our environment is your standard, three-tiered environment. We have the developers develop in their Dev and Test environments, and as the code moves through each environment — Test and a QA environment — it goes through a build process. We build each time we deploy.

We're addressing anything that is a nine and above. If it's a 10, we don't let it into our system; the firewall server stops it. If we have nines we'll let it in, but I'll tag the developers and they'll have to do a little triage to figure out if the problem that is being reported is something we utilize in our system — if it's something that affects us — and if it's not, we flag it as such and let it go. We either waive it or I'll acknowledge it depending on how much it's used throughout the system and how many different components are being built with that bad library.

It really hasn't an improved way we function, but it's helped us to get the developers to start thinking about the security posture that we want to have, going forward, with applications that we develop in-house. It's helping to educate the developers who don't think about these things when they're throwing code together.

It has also brought open source intelligence and policy enforcement across our software development life cycle. That's what we're moving to. We're not 100 percent there, but that's the goal. It's getting the developers to actually think about the third-party libraries they're pulling into the system and to think of them in a different light, in terms of the security aspects of them. I was a developer for 20 years before I got into security. As a developer, you don't always think about the security aspect of things. You're looking for a library that does X, Y, and Z. Lifecycle helps keep that security issue front and center, because as you're bringing it into the system, or as you're doing the build, it's breaking a build or it's doing other things.

It's helping to block undesirable open source components from entering our development lifecycle at least once or twice with every round of releases or library upgrades.

It has also improved the time that it takes to release secure apps to market, although we haven't put a number on that. 

And we have seen an increase in developer productivity because the tool allows them to go out and look for the libraries that aren't affected, or that don't have all the negatives in them. The component piece and the IQ Server aspect has saved time. Without this solution in place, the developers wouldn't care. If this tool wasn't in their face, making them care, a lot would slip by. This is our way to make sure we're watching the gate. Without it, we would be in a much worse spot in terms of exposure, risk, and data exfiltration.

The component piece, where you can analyze the component, is the most valuable. You can pull the component up and you can look at what versions are bad, what versions are clean, and what versions haven't been reported on yet. You can make decisions based off of that, in terms of where you want to go. I like that it puts all that information right there in a window for you.

The default policies are a good start. Within our environment, I tweaked each level to have its own policy, just because of the control it gives us. It provides us with the flexibility we need.

The data quality is pretty good. I have not had any major problems. It helps us solve problems faster.

It integrates well with the existing DevOps tools. We plugged it right in. It was an "after-the-fact" thing that we added into our pipeline and it integrated quite easily. We use Jenkins and it was a nice fit with that. We don't have it creating tickets yet, so we don't have it integrated with a ticketing system, but it is integrated with our Jenkins platform.

One thing that it is lacking, one thing I don't like, is that when you label something or add a status to it, you do it as an overall function, but you can't go back and isolate a library that you want to call out individually and remove a status from it. It's still lacking some functionality-type things for controlling labels and statuses. I'd like to be able to apply it across all of my apps, but then turn it off for one, and I can't do that. I have to go to all 100 apps and do it individually in order to get something on each one, and I don't like that. I should be able to add it as a group and remove it as a single.

Everything else has been really good.

I have been using Sonatype Nexus Lifecycle for a year and a half, going on two years.

The stability is good. There have been no problems that I'm aware of.

It's handling a lot of code but if we wanted to roll out more servers and do more build outs, I wouldn't think that it would involve much more than just adding a few servers. So the scalability should be good.

It is being fully utilized in our build process — where our applications are built and deployed. Where we're lacking use is getting the developers to get it plugged into their Eclipse environments and actually using it on a more regular basis. That's where the struggle has been. That's not the tool, that's more an issue with our developer management side. The adoption is just not happening at the pace it should, because of a whole multitude of other things that are going on right now in our company.

The only other thing we might eventually want to do is get it hooked into a ticketing system where it could create tickets if there are libraries that are bad. Outside of that, it's pretty much integrated into our pipeline as far as we're going to integrate it.

Their tech support is pretty good. I only know of one or two instances where the gentleman in our company who does the upgrades had a question, and they were answered and resolved quite quickly.

We did not have a previous solution.

As I was moving into my security role, the pipeline team was already looking at something and it played nice with Nexus. It was an extra add-on piece or something like that. They were the ones who actually introduced it. I liked it and pushed it along.

The initial setup was straightforward and easy. I didn't set it up but I know there weren't any problems. It took less than a day and it took one person to deploy it. We had one person, at that time, setting up the servers. 

Sonatype came in and did a little demo for us and, while they were here, we got the information set up. It was really easy. We didn't have any major issues that I'm aware of.

In terms of maintenance, we just went through a library upgrade and that was done by one person. It took about a day. We have one person who knows the administrative aspect of it at our company. He works on the pipeline team. I'm on the security aspects and the security policies.

Overall, we have over 50 people using it across our organization. They are developers, architects, managers, and in security.

I'm not sure it's saving us anything. I don't have a way to gauge that as far as return on investment goes.

The return on investment for us is that we have the process in place that has our security aspects tied into it. That's more the type of return on investment we were looking for, and it is doing that. We're still in the early stages.

I'm not familiar with the pricing in detail, but I believe it was pretty reasonably priced, compared to the market.

The biggest thing we've learned from using it is that, from a development point of view, we just never realized what types of badness are in those third-party libraries that we pull in and use. It has been an eye-opener as to just how bad they can be.

As far as Lifecycle's integration into developer tooling like IDEs, Git Repos, etc., I don't set that up. But I have not heard of any problems from our guys, from the team that set that stuff up.

I like the tool overall and would rate it at about nine out of 10. There are a few UI-type things that I don't like, that I would like to work a different way. But overall, the tool is good.

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

The most valuable feature for me is vulnerability detection accuracy.

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

I've been using this solution for four years. 

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

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

Neutral

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

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

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

I rate this solution five out of 10. 

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.